a

Weak entity

generally in any entity type we are

going to have lots of entities for

example if you take any entity type like

employee you are going to have many

employees right now the question arises

how can we distinguish one employee

among all these employees right just to

answer that just to have a uniqueness

constraint what we are doing is let us

say we have this entity type and entity

type is employing okay and in this

employee entity type we are going to

have many employees right now we have to

identify each one uniquely which means

we are going to have some information

about every employee right

so every information is going to be

attributes so just to identify one of

them uniquely we are going to have some

special attributes which are called as

key attributes for example employee

number if you take it if you look at

employee number employee number is going

to be unique or maybe if you take a

student student ID is going to be unique

this has to be something in the entity

the attribute at least some attribute

which is going to uniquely identify you

know that particular entity so that that

uniqueness this is also called as

uniqueness constraint and along with

other constraints like structural

constraints this uniqueness constraint

is going to be implemented using the key

attributes now how do we decide which

one is going to be the key attribute

again from the requirement analysis

whenever you talk to the users they are

going to say that see we have these many

employees and out of all these employees

we are going to give them some identity

cards and every identity card is going

to uniquely have a number which is going

to identify them so depending on that

will set one of the attribute as the key

attribute now once we fix that attribute

that what happens is whenever you try to

insert any new element we will always

check that the new element which is

going to be inserted which means the new

entity should always have a different

value in that term you know key

attribute right so for example at no egg

for this employee maybe you can have an

attribute employee ID right sometimes

what happens is more than one attribute

might qualify to become a

no key attribute for example if you have

a car it will have one in the

registration number and other is engine

number engine number is given by the

manufacturer to identify that engine

uniquely and every car is going to get a

unique engine number and similarly

registration number registration number

is given by the government and it is

also going to be unique right and

sometimes we might have no more than one

attribute which is going to be qualified

as a key attribute in that case as the

schema designer as it is in the database

designer you have the Liberty to choose

any one of them to go for the you know

key attribute sometimes what happens is

we might not have any key attribute at

all that is where we can repair some

problems some entities might not have

any key attribute for example let us say

there is an employee and his family the

family of day know his dependents so all

these dependents are going to depend on

this employee now in that case when

these many people are depending on him

we cannot you employee ID to all these

dependents also right for example you

have a family of five members and in

your database or in your company

database they are all going to save you

know they are going to save the

information about your dependents also

now they cannot give you the you the

employee IDs to the dependents also

right then that particular employee the

dependent set see this what I mean to

say is let us say there is employee set

employee entity set okay and now there

is dependence okay now the problem is

there will be at least one attribute in

the employee especially that employee ID

which is going to uniquely identify no

one one entity in this employee and

employ type right but then here in this

dependent type we might not have any

such number what we have is generally

name age and relationship let us say

name is a right and it is a 25 and

really

ship is let us say Sun or something like

this some of an employee right and at

some other point there might be some

name yeh which is same as this and there

might be some person who is of exactly

same s and who is also a some of some

employee right now these two entities

cannot be distinguished uniquely that is

the problem so just to just to know come

overcome such problems

so whenever any entity is not having

primaries or in this key attribute then

such an entity is called as weak entity

weak entity okay and if a if a entity is

having Prime in this key attribute then

such an entity is called as strong

entity okay and just to overcome this

problem of uniqueness what what rule we

apply is every every week entity has to

be related to a strong entity through a

relationship okay and what should this

relation should be it is called as

identifying relationship so it is a

special type of relationship which is

used for identifying a weak entity right

so this is not the normal relationship

which we have been talking about other

relationships are not necessary they are

not mandatory they are optional but here

this relationship is you know mandatory

without this relationship I know there

cannot be any any entity existing here

it is called as existence right so for

every dependant here for every dependent

here they has to employ here there has

to be employ here but for an employee

here he might not have any dependents

that is not the no real-world scenario

but then there there might be a case you

know if a person might not be having any

family right so that is not really the

case but then they you know there might

you can even have a lots of employees to

not have any dependents on understanding

this

okay do not think how it is possible let

us assume that it is

Boggan so what I am trying to say is if

there is an employee

sorry independent then definitely there

will be an employee on whom he is

depending on otherwise he will never

enter our database of the company right

and in case you know there might be some

employee for whom there may be no

dependent at all now how do we represent

it see this is called a strong entity

any entity which is having primary

attribute is called a strong entity and

any entity which is not having primary

here this key attribute is called as

weak entity right so what is key

attribute it is used to identify entity

uniquely that is unique uniqueness

constraint now how to represent this you

know in terms of your diagram means we

know that we are going to use a

rectangular blocks in order to represent

an entity type and now generally we use

you know this diamond in order to

represent a relationship and since it is

an identifying relationship we are going

to use double diamond like this so every

identifying relationship we are going to

use this double diamond right and every

Veeck entity we are going to use this

double rectangle okay now this is the

strong entity like employee for example

this is the weak entity like dependent

and this is the identifying relationship

like depends on okay like depends or

depends on which means this particular

is no dependant depends on this

particular employee what about the

participation the participation is

always it should hold true always always

the participation of weak entity in

identifying relationship has to be total

very important point okay what I am

trying to say is whatever you think

about here see what whoever is dependent

he should always be participating in the

relationship which means you should

always depend on someone here right so

remember this always the participation

of weak entity in a high

relationship is total which means if you

if you watch it like this right if this

is the beak entity then every every

entity should have some participation in

the relationship right okay and what

about the other one the strong entity

need not be I know our total that is

what I am saying

so because they really do not need them

but they really do not need them they

are dependents they have to depend on

this right and there are various names

for this also now this entity is called

as owning entity of this one or this

entity is said to be owned by this one

own own means we understood this right

own the actual meaning of one which

means without this it cannot exist right

so if you want to add anyone into this

they should definitely depend on this

why is this so is the the only way we

could actually identify that means by

taking the key attribute from here and

adding to this see now dependent is

going to have name right just changing

that dependent is going to have name and

maybe he is going to have some age and

maybe he is going to have some relation

right relation with some employee now

along with these if we add the key

attribute of this strong entity let us

say employee is going to have employee

ID now using all this we can identify

you know one entity in this weak entity

uniquely so sometimes what happens is we

may not be able to identify a like this

we will not be able to identify an

entity uniquely by using one attribute

then what we do is we take more than one

attribute to uniquely identify it right

so which means we can combine some of

the attributes to make it a composite

attribute and maybe we can use that to

identify it for example let us say we

have this car right and God is going to

have one is let us say

and other is registration number within

that state okay generally if you look at

your vehicle numbers here in India you

will see something like this ka zero

four right one two three four

something like this what does it mean ka

means this state is K maybe zero four

means maybe Bangalore and one two three

four mills the registration now what

happens is either this state or this

registration number within this state

might not be able to identify a car

uniquely isn't it but then when I

combine these two which means if I write

this entire number I'll be able to

uniquely identify it sometimes what

happens is if simple if an an attribute

individually is not able to act as a key

attribute or if it is not able to

uniquely identify entity then what we

try to do is we try to add many

attributes to make it a composite

attribute and we call that composite

attribute itself as the key attribute

that can happen but then you should see

that whatever composite attribute you

are trying to form should be as minimal

as possible which means you know if this

itself is going to act as a composite

attribute which is going to be the key

attribute then don't add anything to

this right so whenever you try to add

many attributes in order to make a key

attribute in order to uniquely identify

an entity see that it is as minimal as

possible which means you know if one or

let us say if these two attributes are

going to the act as a you know key

attribute then don't try to add one more

attribute to this and again say that it

is also a key attribute okay when you

are trying to combine them to see that

we need only as as minimal as required

okay

similarly what we are what we are

actually doing in this case is in case

of weak entities we are going to take

some of the attributes from the weak

entities and to this weak entity we are

going to add you know some attributes

from the strong entity and and we call

the entire combination as

the key for the vkt but it but but then

one thing is for sure if an entity is

weak entity then its participation is

total but then every total participation

might not mean that it is weak entity

okay I'll tell you what I mean by that

see I am saying that if an entity is

weak entity then it should definitely be

in total participation in the

identifying relationship like this right

which means without a dependency on this

strong entity there will not exist any

weak entity okay but then if there is

total participation it need not mean

that you know the entity is a weak so

example is let us say there is employee

and works for works for relationship

there is employ entity and works for

relationship and employee works for a

department right and we know that every

employee will work definitely for one

department

therefore the participation of employees

total but then it should not you should

not derive that since completely they

are depending on this which means

totally they are participating in

relationship employee must be you know

we know employee will be strong right

see actually without depending on a

department no employee should exist that

is for sure what what is the constraint

we already said that every employee

should work for at least one department

therefore if a employee is not working

for some department he will never exist

that is fine but then it doesn't make

employee a weak entity what it so total

participation does not make a entity

weak but then if an entity is weak it

will definitely participate totally that

is what the meaning is right it is very

important point people will get really

confusing class flows what I mean to say

is see if it is Veeck entity it has to

have total participation right but if

you are having a total participation it

does

it doesn't necessarily mean that the

entity is weak okay I'll give you one

more example it might help you in the

understanding this concept let us say a

person is having a licence card okay

that you have the license cards right

the driving license DL now that driving

license will never exist without a

person isn't it if there is a driving

licence there will definitely be a

person right okay L I wanted that is

secondary if there is a driving licence

there will definitely be a person but it

does not make the driving licence a weak

entity okay what I mean to say is let us

say it is license card entity that you

are a deal right and now it is person

entity right and this is hold right

right holding so license code is being

held by some person right

therefore what about the participation

you can say that it is totally

participating and it is partially

participating which means there might be

some people who does not have driving

licence

but then if there is a licence card if

there is a deal definitely there will be

a person who is going to fold it isn't

it so what does it make the

participation offer you know license

card in this relationship is total right

but then you should not think that this

license called that particular entity is

weak because license code is going to

have a unique number on it let us say

license number that license number

itself is going to you know identify

this uniquely therefore license code is

definitely going to have a key attribute

right and that key attribute is license

number

so since license code is going to have

license number right and it is a it is

going to act as a key attribute for this

it is also a strong entity so by

participation don't derive the you know

either it is because from so either we

cause

strong that depends on whether it is

having a key attribute or not if it has

a key attribute strong not no key

attribute weak then what we do

identifying relationship complete total

participation then we take the you know

primary key that key attribute ok sorry

that primary key we should not call it

here we take the key attribute from the

strong entity and add it to the

attributes of the weak entity and we

call that composite complete composite

attribute as you know this key for that

particular week entity not it

therefore be Kennedy participation in

identifying relationship is total and

every total relationship total

participation does not say that the

entity is a big or it so this is how the

weak entities are going to work obtain