Database Management System

Dr. S. Srinath
Department of Computer Science & Engineering
Indian Institute of Technology, Madras
Lecture No. # 1a

Conceptual Design

Hello in today session we would be looking at an important concept in the design of

databases namely what is called as the conceptual design of databases using model called
the entity relationship or the ER model.

(Refer Slide Time: 00:01:24)

Now you might have heard somewhere that databases today are based around the
relational model where the fundamental aspect of the building block of a database are
tables. So where does this ER model come in to the picture and what is its relevants and
why do we need something like an ER modeling for databases? So in order to answer that
question let us begin with looking at a small description of what a typical database design
process looks like. This is just a simplified representation of what a database design
process looks like.
(Refer Slide Time: 00:01:57)

However this captures the gist of most database design process. Whenever we talk about
databases, we should always remember that databases are always embedded within some
kind of an application context and this is called the information system within which the
database is embedded. So databases could be embedded within for example for a banking
solution, the databases could be embedded within railway reservation solution, there
could be embedded within a university setup, a company whatever.

Now whatever this setup is, this context or the information system context is what is
called as a UoD or the universe of discourse. The universe of discourse basically tells us
what are the building blocks that make up this context within which this database is going
to be run. Now generally when we talk about designing a database system, we first talk
about looking in to the UoD and collecting requirements from the UoD. We have to make
an analysis of the UoD saying for example, suppose you want to build databases for a
bank, we have to first identify or we have to first understand how does the bank conduct
its operations, what kinds of operations do they have and what are their rules, what are
their norms and what identifies a correct operations from an incorrect operation and so on
and that is going to give us two kinds of requirements. The first is what is called as
database requirements or you might also term it as data requirements and the second is
what is called a functional requirement.

Now as you might have imagined that database requirements are handled by DBMS or
the database management system. However a DBMS by itself is not a complete solution.
To give you an analogy DBMS is something like an engine. Now we cant just have an
engine, we have to build a car around it or we have to build a bus or whatever it is around
it. So this layering around the database system is what is called as the application
programming or the information system.
So the functional requirements go to design in the application program or the larger
information system with in which the database is going to be.

(Refer Slide Time: 00:04:24)

Now continuing with this process, we take the database requirements and come out with
a first level or what we called as a high-level conceptual design. We have to first
understand how this database requirements look like, what are the different data elements
and how are they related? We need to first understand in a way or rather represent it in a
way that is understandable by human beings rather than computers. We have to first
understand the problems first before we give it to the computer.

So database requirements go into what is called as the conceptual design and the output
of the conceptual design is what is called as the conceptual schema. Now this conceptual
schema is what we are going to be taking up today in more detail but going on with the
process itself, let us see what happens with the functional requirements. So functional
requirements also go through a similar process where you do functional analysis, you
analyze what are the different functions.

If it is a bank, what are the different functions? Opening an account is a function or

making a bank transfer is a function. Now what are the constraints that holdup these
functions what is a correct function, what is an incorrect function and so on. So once
these functional analyses are made, we get what are called as high-level transaction
specifications. In fact we will be revisiting this topic called transactions as a separate
module where we will see that many times, we need to club different operations of the
database into one logical unit or what we called as a transaction.

Now transactions are what are going are the building blocks of the functional
requirements or the functional analysis of the information system. Now you can also see
down here that all of these, until now all of these are DBMS independent process.
So what is meant by DBMS independent process? It means that doesnt matter whether
you are using an oracle database or an IBM db 2 database or a MYSQL or postgres or
whatever it is. You will have to look at the UoD, you will have to understand your UoD,
you have to come out with a conceptual design which has in no way relevant to the actual
implementation which the DBMS does and you have to do a functional analysis which is
completely independent of the DBMS that we are using.

Next comes the DBMS dependent processes. So we ended up with the conceptual schema
previously in the database stream. You can say that there are two different streams of a
processes happening. One is the database stream and the other is the functional stream or
the application stream.

(Refer Slide Time: 00:06:50)

So in the database stream, we had ended up with the conceptual schema. Now the
conceptual schema in turn should be transferred in to what is called as a physical design.
Now what is physical design? The physical design actually tells you how the data itself
resides on the database, on the computer. So obviously this is a DBMS dependent
process. So the way, even though there are many standards that exists now the way that
let us say oracle stores its data would be different from the way db 2 stores its data. Even
though there due to some standards there are going to be slight variations. So this
physical design results in what is called as an internal schema or the schema which
actually should goes into the DBMS and similarly the high-level transactions
specifications that we are talked about are also going to impact the physical design of the
database.

I mean suppose certain kinds of operation have to be performed together. It makes sense
to design them near to one another so to say. Let me just use the word in slightly lose
fashion here to one another so that it becomes easier to handle transactions on. So you get
inputs both from the conceptual schema and from the high-level transaction specs in
order to make your physical design of the database.

Similarly the application stream goes off into application program design and transaction
implementation, finally the application software. So under, from all this now we are
going concern ourselves in this session with just one aspect of this entire process that we
looked at namely the conceptual schema. Now what is a conceptual schema and why is it
important for database design?

(Refer Slide Time: 00:09:06)

So let us have some observations about what is a conceptual schema. We just now saw
that the conceptual schema is an outcome of the high-level conceptual design of a
database. So this is one of the first things we are going to do. We are going to understand
our UoD or the universe of discourse. It tells us what kinds of data that the UoD is going
to handle and based on this, we are going to come out with a high-level design.

So its a very concise description of the data requirements, what kinds of requirements do
users need and how are the data related between one another and so on. Again let me take
a brief example. Suppose you are building banking solution. One of the first things that
you are going to note is that in a bank there should be accounts, there should be
customers, there should be customers or account holders or whatever you call them and
there should be of course monitory transactions and there should be some kinds of logs
and ledgers and account books and so on. So all of these represent some kinds of data
elements and a very high-level conceptual design would identify each of these data
elements and say this is how they are related. So it includes the description of what you
called as entity types.

These are the entities that makeup the UoD. In a bank the customer is an entity, an
account is an entity and a ledger is an entity. Similarly in any other UoDs, there would be
several different entities like that whether it is a railway reservation system or a
university or whatever, theyre going to be different kinds of entity types and there are
relationships across the entity types.

So customer holds an account, an account transfers to another account and so on and so

far. So there are relationships between different entity types and there may also be certain
constraints that are imposed either by physics or by the UoD itself. In a bank for example
one might say that in a SBI account, balance may not go below 50 rupees or whatever
thats a constraints that is imposed by the UoD that says you cannot have less than 50
rupees in your account in order to make a term, in order to make a term working.

On the other hand there could be other constraints that are imposed by physics itself, the
physical reality. For example if you are modeling a railway reservation, you cant
obviously have two trains starting at the same time from the same place, from the same
platform. So it is simply because those two cannot exit at the same time. So there are
different kinds of constraints that exist among data elements and this is what we are
going to capture during the conceptual design. And another thing to note here is a
conceptual design has no implementation details.

Here note that it earlier we had noted that a conceptual design is a DBMS independent
process. So that means we are not really worried here about how this conceptual schema
is going to be implemented within a database systems and the main idea of a conceptual
schema is ease of understanding. We should be able to say to your end user this is what
we have understood from your description, this is what we have understood of your needs
and your end user should be able to understand your understanding so to say. So he
should be able to understand your understanding, even though the end user may be a non-
technical user.

So the main idea for behind the conceptual schema is ease of understanding and it is used
mainly for communication with end users who are of non-technical nature.
(Refer Slide Time: 00:13:08)

So here is a small example. An example, company database. So suppose we look at a

company, what are some of the first things that we can identify. First some of the first
things we identify are a company of course has employees, we can see them. Then
company has departments, each employee works in different departments and so on.
Then once we start speaking to employees, we find that there are also different projects
and each department has some one or more projects and a project may span different
departments and so on.

And once we start to the HR, talk to the HR department, we note that each employee also
has some dependence and there are also covered in some way or supported in some way
from the company and so on. Now if you look at this slide carefully, here we see that
there are two different kinds of things that we are noting here. All these things before the
colon, we see the things like departments, projects, employee, dependence and so on and
after the colon you have a terms like name, department id, manager or name, project id,
location or name, pan number, address and so on.

So what this says is that all this names before the colon like departments, projects are
entity types. They are different entities say department is an entity, project is an entity,
employee is an entity and so on but once after the colon like name or manager or location
and so on are what are called as attributes of this entity that means they belong to this
entity. For example the name occurring after department here belongs to this department,
the department id belongs to this department.

Similarly the project id belongs to project and address belongs to employee, date of birth
belongs to employee and so on. So it not only belongs to employee, it also tells us or it
describes something about the employee. So if there is an employee, an employee has a
name, an employee has a pan number, if he is paying income taxes regularly that is he
has an address, he has a salary, he has well, he or she has a gender and date of birth and
so on. So all of these attributes define what is an entity type and what are the
characteristics of that entity type.

(Refer Slide Time: 00:15:35)

So let us formulate things a little bit now. In the ER model or the entity relationship
model, we have standards notation of representing entity types and their attributes. As
you can see in the slide here, entity types are represented by rectangles. So department is
an entity and attributes of the department like department name, department identifier,
manager of the department and so on are represented in the form of ovals or something
like balloons hanging over this entity types.

So there are some definition here. So if you review this, an entity represents an object of
the real world that has an independent existence. Note that term independent existence
that is you should be able to identify an entity independent of every other entity in the
system. Address is not an entity because address belongs to some entity called employee
or department or whatever. However the employee itself is an entity because it is an
independently occurring object in the UoD and an entity has attributes or which are
properties that describe the characteristic of this entity.
(Refer Slide Time: 00:16:53)

Now what are the kinds of attributes or what are the different kinds of attributes that
could exist? We saw name and age and date of birth and so on but can we classify this
attributes into different kinds of attributes and it can tell us something about characteristic
of the entities. So there are several different classifications of attributes, we are going to
look at small number of such classification. One of the first classifications of attributes is
simple versus composite.

So what is a simple attribute? A simple attribute is let us say something like age. You are
30 years old, 30 age equal to 30. So thats a simple attribute that is just one value
associated with an attribute. So when you say age, you get back one value called 30. On
the other hand suppose you say name, in some countries we say name is name, you just
talk about one name for an employee but in several different places when you talk about
name, you have to specify a first name and middle name and last name and title and nick
names or whatever so.

So basically a name is composed of several other attributes within it, so that is what is
called as a composite attribute versus a simple attribute which has just one value and
there could be a something like a single-valued attribute or a multi-valued attribute. Now
what is a single-valued attribute? Again age is a single-valued attribute. At any point in
time at least you have just one age that is at this point in time let us say you are 30 years
old or 35 years old or whatever. On the other hand at any given point in time, an attribute
may actually have multiple values.

Now take the color of a peacock for example. No matter when you are going to measure
this, no matter at what time you are going to take a snap shot of a peacock, you are
always going to find many colors. So this is a multi-valued attribute, that is the attribute
itself is defined by multiple values. How is this different from a composite attribute? Let
me pass here for a little while so that you can ask this question to yourself again. How is
a multi-valued attribute different from a composite attribute? Now composite attribute if
you saw, if you notice closely is made up of different sub attributes.

For example name is made up of first name, middle name, last name and so on and
initials for example or title and so on. All of these need not be of the same type. I can say
title can be either mister, doctor, misses, whatever and so on only these three types. On
the other hand name could be anything, any string and so on. On the other hand when we
look at multi-valued attributes, all the different values that it takes, color of a peacock for
example it might have different attributes, many attributes but all of them denote color
blue, green, red, white, whatever all of them are color, all of them are of the same types.
So multi-valued attribute are different values of the same attribute type but a composite
attribute is a collection of different smaller attributes in itself.

(Refer Slide Time: 00:20:19)

And then there, what are called as stored attributes versus derived attributes. Now stored
attributes is something which you just store in the database, your date of birth for
example. So when you ask what is your date of birth, you just give some date and then
store it in the database. However suppose you were to ask what is the age of an
employee. Now suppose you know today's date and you know the date of birth of the
employee, you can always derive the age of the employee. So age in a sense is a derived
attribute, a good database design would put age as a derived attribute because a database
hopefully is going to be used for a long time. Its not just today, today an employee might
be 30 years old but 5 years later he still wont be 30 years old, he would be 35 years old.
So its always best to have age as a derived attribute because you always know what is
the current date and you always know the stored attribute called the date of the birth.

Similarly there are what are called as null attributes or null values for attributes.
Sometimes an attribute may not have any associated value for a particular case and let me
give an example. Suppose a student can take at most two elective courses in a semester
and at least one elective course and at most two elective courses. Now let us say there is a
student who has taken just one elective course. Now because he can take at most two
elective courses there are four different, there are two different slots, elective one and
elective two. Now let us say after, at the end of the course is give a grade for each of the
courses, that each of the courses he has taken up. Now he gets a grade for the first course
but he doesnt get a grade for the second course because he didnt take the second course
at all, elective two has no grade. But this grade is not we cant say that he has scored zero
in elective two. So a null value is different from zero or unknown or missing value. This
is not a missing value this is not a, this not zero or this is not an unknown value, this is a
null value. That means that something like when you say n a, when you write in
application forms this is a null attribute.

So let us come back to entities and define a few more terms here with respect to entity
types. So we saw that an entity type, I have been using the word entity type but have
never really formally defined this term. So an entity type is a definition or defines a
collection of different entities of the same type.

(Refer Slide Time: 00:22:47)

For example in this slide, we give this example of department. So a company could have
different departments but when you say an entity type department it means that it
represents all departments in the company. So it is a definition of a real world object type.
So its not this department or that department, it is just department. It is a type that the
entity is going to define.

Now any specific collection of entities of a particular type is what is called as an entity
set. For example if you take supplies departments plus accounting department. Now
suppose we take both of them in some collection. We call this as an entity set, these are
two different departments of the same entity type. So we also say that an entity type as
opposed to an entity set. So an entity type is set to describe the schema or the intension of
an entity set.

What is that mean? It basically says that how should the structure of this entity or entities
of this type look like. So suppose we say that department should contain a department id,
it should have an address, it should have a manager, it should have several other
attributes that means that no matter whether it is the supplies department or the
accounting department or the systems programming department or whichever
department it is, they should be defined by these attributes. That is they should have a
department identifier, they should have a clearly defined address, they should have one %
designated as manager and so on.

So an entity type describes what is called as an intension or the schema for an entity set
or different entities of the same type. So here are again a review of the representations
entities types are defined by boxes and attributes are defined by ovals and different kinds
of attributes have different kinds of ovals may be its not completely visible here. The
multi-valued attributes are defined by an oval having a double line.

(Refer Slide Time: 00:25:03)

And similarly derived attributes are those which can be derived from other attributes are
defined by a dotted line instead of a solid line.
(Refer Slide Time: 00:25:38)

And we now come to another key issue when we are talking about entity types and
namely this is about key attributes. Now what is a key attribute? Now if you notice
carefully when you said that each department has to have a department identifier and
manager and address and so on. Now why do we need a department identifier for each
department? This is to be able to identify each department uniquely.

Now if I say department number 10, it means just one department no matter what its
name is. Department name could be ambiguous, it could mean supplies and accounts and
suppose we might have a department called administration, it might mean both supplies
and accounts or whatever so. A name could be ambiguous but when we say an id or an
identifier, its a something like what you have a pin code in post letters. It uniquely
identifies each entity of this entity set. So the department id attribute is unique for each
department that belonging to this entity set. So such attributes which can uniquely
identify entities are what are called as key attributes or keys.

So the key attribute as you can see here is specified by an underlined definition. So the
department id is underlined here to denote that it is a key attribute.
(Refer Slide Time: 00:27:14)

Now in some cases it need not always be just one and that is the key attribute. There
could be more than one attributes which are key attributes in which case all attributes
which form part of the key are all showed underlined. Now what is meant by a key
attribute? So an attribute or a set of attributes that uniquely identify entities in an entity
set. So is what is called as a key attribute? Now like I said it need not be just one attribute
that is a key attribute, there could be more than one attributes which is a key so in which
case the key attribute is called a composite key. So the key is made by combining two or
more attributes together.

A composite key should be minimal what is it mean to say a composite key is minimal.
Let me first give you the definition of what is mean by minimal and then we can see an
example. So no subset of a composite key should be a key itself. For example let me take
the attributes department id and department name. Is it key attribute? Of course its a key
attribute because if I take department id, department number 10 supplies, it uniquely
identifies one particular department.

However the second attribute here, the name called supplies is redundant. We dont need
to have this attribute here in order to uniquely identify a department. Its sufficient
enough if you say department number 10. So thats what is meant by a composite key
that is department id and name is not a composite key because it is not minimal in nature.
No subset of a key attribute should be a key attribute in itself in which case this is not so.
So, key attributes are shown underlined in the ER diagram.
(Refer Slide Time: 00:29:14)

There are also certain other properties of keys which we are going to revisit again when
we are going to look into the enhanced ER model. What is called as the retention of key
attributes in all extensions? So let me not take this property right now and we will come
back to this again that the key attribute should be retained for all extensions of a
particular entity type. Now it may so happen that a key attribute should uniquely identify
an element but an element need not have just one key attribute.

Of course I can have two keys to my house, key from the front door and the key from the
back door. Now it is fine but the only thing is this key should open only my house door
not somebody elses house door. So thats the idea that is a key should uniquely identify
a house but a house could be identified by more than one key, you could either enter
through the front door or the back door.

Similarly I can have a let us say on a computer network, you can uniquely identify a
machine by its ip address or so to say an ethernet address on a lan and so on but a
machine could have more than one ethernet cards in which case both of them uniquely
identify the machine. So there is no restriction on how many keys that you are going to
have but usually we are going to use one key, so what is called as a default key. Usually
we are going to enter through the front door not always through the back door.

So usually we are going to use just one key but you may have more than one keys that
define a particular entity type. And there could be some entity types which have no key
attributes. We are going to take a look at one such example little later on and it may not
be possible to define any kind of a key attribute for such entity types and such entity
types are called weak entity types or entities of such type are called weak entities. So they
have to what we called as totally participate in some relationship in order to define
themselves.
Now we come to the next definition of, definition in the ER model what is called as a
domain, what is meant by domain of attributes. Now a domain to put it in a very informal
fashion is going to show you the space in which an attribute is going to be defined.

(Refer Slide Time: 00:31:25)

For example if I say age of an employee and there are some set of rules that you cannot
have employees lesser than 18 years and greater than 65 years. The domain is basically a
number between 18 and 65. Obviously it can be, there are also some physical limitations
in the sense that the domain of an age can never be negative so thats the nature imposed
restriction but there could be other restrictions and which basically defines the space
within which any value of this attribute can reside.

Now if a composite attribute has different sub attributes or like we saw name has
different sub attributes first name, middle name, last name and so on. And each of them
have the room domains let us say D 1 D 2 D n . So we see that the domain of the composite
attribute is Cartesian product of the domains of individual attributes. So the first attribute
can take a value between 18 and 65 and the second attribute can take a value between 0
and 10 and so on. So the domain of the entire attribute is just a Cartesian product of all of
these terms.
(Refer Slide Time: 00:33:01)

So let us briefly come back to this company example and see likewise whatever we have
seen until now. So we can think of different kinds of entity types like department, project,
employee and so on and there are different kinds of attributes for each kind, each of these
entity types and there are certain key attributes here which are underlined and then there
are certain composite attributes which are shown like this that is name is composed of
first name, middle name, last name and so on and like that and several other entity types
that we can identify during our analysis.

The next concept that important concept that we are going to be looking at in ER
modeling is the notion of relationships like the modeling itself says its about entities and
relationships. So we just until now we looked into what are called as entity types. So we
defined as an entity type, an entity set, attributes, different kinds of attributes and keys
and domains and so on.

Now let us see how can we relate entities of different types. So a relationship are to be
precise relationship type defines a relationship between two or more entity types. So the
slide here shows a relationship type between an entity type department and an entity type
employee and it says managed by.
(Refer Slide Time: 34:35)

So it basically says a relationship type specifies that any department or any entity of type
department should be managed by some employee or some entity of type employee.

(Refer Slide Time: 00:34:54)

So let us go further and make some definitions. First of all, let us first defined what is
meant by relationship type. So relationship type R is an association among different
entity types, it need not be just two entities it can be any number of entities. So there
could be n number of entities and defines, it basically defines a set of associations, what
is called as a relationship type.
So if you look at it a little bit carefully, a relationship type is just a subset of the Cartesian
product of all of the entity types. So that means an entity instance or entity or entity of
this type could be related to some entity of this type and some other entity of the next
type and some other of the next type and so on and all of this define one instance of this
relationship.

(Refer Slide Time: 00:35:49)

So let us dwell deeper into what are meant by relationships and what are some of the
characteristics that define relationships. Firstly, the notion of the degree of a relationship
type. So what is a degree of a relationship type? Its simply the number of entities or that
are involved in this relation, it is how many, between how many relations is this
relationship going to establish an association.

We saw earlier a relationship type of degree two that is a department is managed by an

employee. So there are two entities that participate in this managed by relationship. Such
kinds of relationships are called binary relationship, binary basically because there are
two entity types involved. Similarly there could be unary relationships, there could be
ternary relationships and so on and there could be n array relationships, n different types
of relationships.
(Refer Slide Time: 00:36:49)

Now we come to kind of a tricky problem here. Now have a look at this slide carefully.
The first picture above shows the relationship type, it shows employee works for
department and the second relationship and the second picture below shows employee as
an entity and department in which the employee works in as an attribute of employee. So
which is correct? Is department an attribute of employee that is does the department in
which an employee works in describe the characteristics of an employee or is it that
departments and employees have separate existences or separate entities and there is a
relationship type between them.

So let me confuse this problem even further, take a look at this slide here. So in the
earlier slide, you could have probably said that no department cannot be an attribute
because department has an independent existence. We already saw that each entity type
should have an independent existence. So because departments have an independent
existence they can't be an attribute.
(Refer Slide Time: 00:37:50)

But have a look at this slide here. The first picture shows employee works for department
as a relation and then department has a department id as one of its attributes. Now I am
going to take this department id attribute and put it in to employee and say employee
works in this department, so this employee is associated with this department id. So now
which is correct or which is wrong? So is the first one correct or the second correct? The
answer to this obviously is it depends on the particular situation in which you are looking
into.

Now the first one where we show that employee works for department as a separate
relation depicts the relationship between employee and department and the second one
just depicts what are all the different characteristic that describe or what are the different
attributes that describe the characteristics of employee that means if I am talking about an
employee entity and if I say that an employee is or in some sense an employee is very
closely tighed to his department. So he has no identity without his department id in which
case you have to say department id is a part of the attribute or is one of the attributes of
the employee entity type.
(Refer Slide Time: 00:39:46)

So relationships versus attributes, its a slightly a tricky problem always, so in order to

determine whether a particular thing is actually a relationship or it is an attributes. And in
some kinds of data models like what are called as functional data models or in object
databases, relationships are almost always refer to as in the form of attributes. For
example in object databases, you talk about relationship by storing an object reference.
Let us say you have a relationship between employee and department, so there is a
reference to a department object within the entity object and vise versa and a reference to
an employee object in the department object and so on.

Similarly in relational databases which we are going to study much deeper, we see that
relationships are established by what are called as foreign keys that is there is one table
that describes one kind of an entity and a relationship between this table and the other
table is described by a foreign key attribute which says that this entity of this type is
related to some other entity of the other type. Now we come to another important issue in
the when you are talking about relationship, this is the notion of constraints.
(Refer Slide Time: 00:40:59)

So when we talk about relationships almost always relationships are defined by certain
kinds of constraints. Take the examples of employee managing a department. One of the
most simplest constraints that we can think of is department should be managed by at
most just one employee. We can't have two mangers or two heads of a department, we
should have a just one head of a department and you might also establish a constraint that
one person can manage at most one department at a time.

In some cases there could be allowed to manage more than one department at the same
time. So that means in that case there is no constraints from employee to department but
there is a constraint from department to employee. So when you are talking about
constraints and relationship types, we are mainly concerned with two kinds of constraints
what you call as cardinality ratios and participation constraints. So what are these
cardinality ratios and participation constraints lets have a look at them.
(Refer Slide Time: 00:42:15)

So take a look at this relationship again. Here now I have replaced this managed by with
another relationship called works for. Now works for is slightly more general than
managed by in which ways it more general then managed by. A department can have
many employees working for it.

However sometimes we might have to mandate a requirement that an employees can

work for only one department not for multiple departments. So this is shown in one of
two different ways either like this that is N : 1 which says that N employees to one
department or something like this, so which says it could be N employees working in one
department and so on. So on the other hand what happens if this were to be M:N
something like 4 : 3 or 2:1 or 2:5 or something like that. So that means that let us say 4:3
so that means that a department can have at most 4 employees and an employee can work
in at most 3 departments and so on. So basically you can represent a cardinality constraint
or cardinality ratios in this case that says participations in this constraint is defined or
constrained in this, by this cardinality or number of entity types.

The second kind of constraints thats important is what are called as participation
constraints. What is a participation constraint?
(Refer Slide Time: 00:43:49)

Take a look at this slide here. Now this slide shows another relationship type which says
department handles project. Now a department may handle several different projects.
Suppose there is a restriction that a project has no existence unless it is associated with a
department. Now suppose I have a project for developing some kind of software. Now
this project does not exist if it is not associated with some department, if there is no
department which is in charge of this project.

Basically what this says is that if every project has to be associated with a department
then the very existence of project depends on this relation. So only if an instance of this
relationship exists only then can a project entity type exist or such kinds of constraints are
what are called as participation constraints. They are defined by a double line here may
be its not fully visible but it is a double line here. So that means that the very existence
of this project is dependent upon the existence of a relationship of this kind.

Going on further in to participation constraints, we say that the entity type in this case
project is said to totally participate in to this relationship because if it doesnt participate
it doesnt exist anymore.
(Refer Slide Time: 00: 45:16)

So a participation constraint in which an entity type existence is dependent upon the

existence of this entity type of this relationship type is called as total participation. That is
the entity type or participates completely or totally in this relationship. We can also think
about attributes for relationships and not for entities themselves, just like we saw
attributes could be associated with entities. We could also allocate attributes for
relationships.

Have a look at this figure. Here it shows department as an entity type and says that
department handles certain projects and project totally participated in this relationship
and then an attribute called budget is placed for this relationship. So what is this mean? It
basically means that this budget or the budget that is specified here is allocated for this
project associated with this department or is specifically allocated for this relationship
type.
(Refer Slide Time: 00:45:50)

So in cases where let us, the project is handled by more than one department that means
that this budget is not allocated to the project. This is allocated only for this project for
working on this department and so on. It is not allocated to the department as well that
means the department cannot use this budget for anything else; it has to use it for this
project only. So this budget actually is a constraint on the relationship type, so it belongs
neither to department nor to the project in its entirety.

However there is certain kind of relationships where we can actually move the attributes
from the relationship type to one of the entities. What are those kinds of relationships?
Take a look at this slide here. The first figure shows a 1: N relationship that is a project
can be associated with at most one department and there is an attribute called budget that
is allocated to this relationship.
(Refer Slide Time: 00:47:23)

Now if you see carefully, we do not do correctness if we move this budget attribute from
the relationship to the project site. So if I say that this budget is allocated to this project, it
does not lose any semantics because a project can be associated with just one department.
In the previous slide, a project could be associated with M different departments that is
it could be associated with many departments.

So here since project can be associated with only one department, it does not lose
semantics if the budget is allocated to the project itself. So one of the last things
definitions that we are going to be looking at today are is what is called as a identifying
relationships. Have a look at this slide here, this slide here shows a figure where an
employee is identified by pan number. So assuming that every employee is a tax payer
and has received pan number from the government, an employee is uniquely identified by
his pan number.

Now let us say we prepare, the company prepare some kind of an insurance record for
each employee.
(Refer Slide Time: 50:00)

Now let us say this entity called insurance record which contains certain parameters or
whatever is an entity by itself because it has an independent existence. You can see an
insurance record and note that its an entity by itself. However you see that an insurance
record has no existence, has no meaning unless it is associated with somebody unless it is
associated with some employee or some department you want or whatever. So this is an
example of an entity type which is a weak entity type that means it has no keys. The key
for the insurance record is of course the pan number itself or pan number of the
employee. So the key of the employee which defines an insurance record forms the key
for the insurance record as well and the relationship that defines this, such a kind of
association is what is called as an identifying relationship.

So this relationship here in this slide which is called as insurance details identifies
insurance record with an employee. It basically ties in insurance records with employee
so that an insurance record also gets independent existence by themselves. So as you can
see insurance record totally participates in this relationship. Obviously it has to totally
participate in this relationship but on the other hand not every total participation may
mean an identifying relationship, we actually saw an example earlier where we saw
two different entity types department and project in participation but which is not a weak
entity type.

So, identifying relationships are again defined by double lines on the relationship types
itself. So let us briefly pursue a summary of the different notations we saw. The first
thing that we saw was an entity type and defined by a box and a weak entity type which
is defined by a dotted line which is not clearly visible here.
(Refer Slide Time: 00:51:10)

Then relationships types are defined by rhombus and the identifying relationship types
are defined by double lines.

(Refer Slide Time: 00: 51:38)

Similarly attributes are defined in different ways that is normal attribute is an oval, a key
attribute has an underline there and a multi-valued attribute has double line and a derived
attribute has a dotted line. So with this we come to the end of this session where we had a
brief look at what is meant by conceptual design of a database.
So to briefly summarize that a conceptual design of a database is meant for non-technical
users, its a high-level design and mainly composed of diagrammatic notations like
entities and attributes and so on. And within this diagrammatic notations, we saw that
there are several different characteristic, there could be entities, entity type, entity sets
attributes, multi-valued attributes and key attributes and relationships, an identifying
relationships and weak entity types and so on.

So one of the first step that we do in database design is to be able to identify this entity
types and relationships and to be able to build this ER schema. So that brings to the end
of this first secession on conceptual modeling of database systems.

Thank you.