You are on page 1of 3

STUDENT

 
ROLL_NO NAME ADDRESS PHONE AGE BRANCH_CODE
 
1 RAM DELHI 9455123451 18 CS
2 RAMESH GURGAON 9652431543 18 CS
3 SUJIT ROHTAK 9156253131 20 ECE
4 SURESH DELHI 18 IT
BRANCH
 
BRANCH_CODE BRANCH_NAME
CS COMPUTER SCIENCE
IT INFORMATION TECHNOLOGY
ECE ELECTRONICS AND COMMUNICATION ENGINEERING
CV CIVIL ENGINEERING

hese are attribute level constraints. An attribute can only take values which
Domain Constraints: lie inside the domain range. e.g,; If a constrains AGE>0 is applied on
STUDENT relation, inserting negative value of AGE will result in failure.

It should be unique for all tuples.


Every relation in the database should have atleast one set of attributes
key has two properties:
which defines a tuple uniquely. Those set of attributes is called key
Key Integrity: It can’t have NULL values.

IT IS CALLED KEY ATTRIBUTE

When one attribute of a relation can only take values from other attribute of same relation or any other relation, it is called referential integrity. Let
us suppose we have 2 relations
 
STUDENT
 
ROLL_NO NAME ADDRESS PHONE AGE BRANCH_CODE
 
1 RAM DELHI 9455123451 18 CS
2 RAMESH GURGAON 9652431543 18 CS
3 SUJIT ROHTAK 9156253131 20 ECE
4 SURESH DELHI 18 IT
These constraints are checked before performing any operation BRANCH
Constraints (insertion, deletion and updation) in database. If there is a  
violation in any of constrains, operation will fail. BRANCH_CODE BRANCH_NAME
CS COMPUTER SCIENCE
IT INFORMATION TECHNOLOGY
ECE ELECTRONICS AND COMMUNICATION ENGINEERING
Helps you to define terms related
CV CIVIL ENGINEERING
to entity relationship modeling
Referential Integrity  
 
Provide a preview of how all your BRANCH_CODE of STUDENT can only take the values which are present in BRANCH_CODE of BRANCH which is called referential integrity
tables should connect, what fields constraint. The relation which is referencing to other relation is called REFERENCING RELATION (STUDENT in this case) and the relation to which
are going to be on each table other relations refer is called REFERENCED RELATION (BRANCH in this case).

Helps to describe entities, We can’t insert a row in REFERENCING RELATION if referencing attribute’s value is not present in referenced attribute
attributes, relationships InserT value. e.g.; Insertion of a student with BRANCH_CODE ‘ME’ in STUDENT relation will result in error because ‘ME’ is not
present in BRANCH_CODE of BRANCH.

ER diagrams are translatable into


relational tables which allows you An anomaly is an irregularity, or something which deviates It will update the REFERENCING ATTRIBUTE in REFERENCING RELATION if attribute value used by REFERENCING
to build databases quickly from the expected or normal state. When designing ATTRIBUTE is updated in REFERENCED RELATION. e.g;, if we update a row from BRANCH with BRANCH_CODE ‘CS’ to
ANOMALIES ON UPDATE CASCADE
databases, we identify three types of anomalies: Insert, We can’t delete or update a row from REFERENCED RELATION if value of REFERENCED ATTRIBUTE is used in value of ‘CSE’, the rows in STUDENT relation with BRANCH_CODE CS (ROLL_NO 1 and 2 in this case) will be updated with
Why use ER Diagrams Update and Delete. BRANCH_CODE ‘CSE’.
ER diagrams can be used by REFERENCING ATTRIBUTE. e.g; if we try to delete tuple from BRANCH having BRANCH_CODE ‘CS’, it will result in error It can be handled by following
Deletion/ Updation
database designers as a blueprint because ‘CS’ is referenced by BRANCH_CODE of STUDENT, but if we try to delete the row from BRANCH with BRANCH_CODE method:
for implementing data in specific CV, it will be deleted as the value is not been used by referencing relation. will delete the tuples from REFERENCING RELATION if value used by REFERENCING ATTRIBUTE is deleted from REFERENCED
software applications ON DELETE CASCADE RELATION. e.g;, if we delete a row from BRANCH with BRANCH_CODE ‘CS’, the rows in STUDENT relation with
BRANCH_CODE CS (ROLL_NO 1 and 2 in this case) will be deleted.

The database designer gains a


better understanding of the
information to be contained in the Any set of attributes that allows us to identify unique rows (tuples) in a given relation are known as super keys. Out of these
database with the help of ERP super keys we can always choose a proper subset among these which can be used as a primary key. Such keys are known as
KEYS SUPER KEYS
diagram Candidate keys. If there is a combination of two or more attributes which is being used as the primary key then we call it as a
Composite key.
ERD
ERD Diagram allows you to
communicate with the logical Tuple Each row in the relation is known as tuple.
structure of the database to users

Column represents the set of values for a particular attribute.


Column
Rectangles: This Entity Relationship The column ROLL_NO is extracted from relation STUDENT.
Diagram symbol represents entity
types a real-world thing or a real-world
object which is distinguishable
entitiy
Ellipses : Symbol represent from other objects in the real
attributes world.

Diamonds: This symbol represents Each table is entity


relationship types
symbols in ER Diagrams: ROOM can only exist in a
does not have a primary key
Lines: It links attributes to entity BUILDING
Entity weak
types and entity types with other
relationship types dependent on a strong entity

Primary key: attributes are strength TIRE might be considered as a


underlined complete by itself and is not
strong entity because it also can
dependent on any other entity
exist without being attached to a
strong type.
Double Ellipses: Represent multi-valued CAR
attributes
has primary key

BASIC COMPONENTS An attribute that cannot be further subdivided


Simple into components is a simple attribute. ‫ملوش‬ SSN
‫تفاصيل‬

complexity The address can be further split


into house number, street number,
An attribute that can be split into components
Composite city, state, country, and pin code,
is a composite attribute.
the name can also be split into first
name middle name, and last name.

The attribute which takes up only a single value for each


Single-valued entity instance is a single-valued attribute. The age of a student.
‫ال يحتمل اال قيمة واحدة‬
Attribute Attributes are the properties that define a relation. Attribute no. of Value
The attribute which takes up more than a single value for
Multi-valued each entity instance is a multi-valued attribute. Phone number
‫يحتمل اكثر من قيمة‬

Stored attribute which are physically stored in the database marks of student
source of data
Derived An attribute that can be derived from other attributes average marks of a student.

Those attributes, which can be formed by the nesting of composite and multi-valued
Contact detail:A person can have
attributes, are called “Complex Attributes“. These attributes are
Complex many phone numbers,many e-mail
rarely used in DBMS(DataBase Management System). That’s why they are not so
addresses,home addresses etc.
popular.

binary between 2 entities

types ternary between 3 entities

relations recursive between entity and itself worker manges other workers

one to many
cardinality
many to many
ERD
1. STUDENT ROLL_NO NAME ADDRESS PHONE AGE BRANCH_CODE 1 RAM DELHI 9455123451 18 CS 2 RAMESH GURGAON 9652431543 18 CS 3 SUJIT ROHTAK 9156253131 20 ECE 4 SURESH DELHI 18 IT BRANCH BRANCH_CODE BRANCH_NAME CS COMPUTER SCIENCE IT INFORMATION TECHNOLOGY ECE ELECTRONICS AND COMMUNICATION ENGINEERING CV CIVIL
ENGINEERING
2. Constraints

Link:
https://www.geeksforgeeks.org/relational-model-in-dbms/

2.1. These constraints are checked before performing any operation (insertion, deletion and updation) in database. If there is a violation in any of constrains, operation will fail.

2.1.1. Domain Constraints:

2.1.1.1. hese are attribute level constraints. An attribute can only take values which lie inside the domain range. e.g,; If a constrains AGE>0 is applied on STUDENT relation, inserting negative value of AGE will result in failure.

2.1.2. Key Integrity:

2.1.2.1. Every relation in the database should have atleast one set of attributes which defines a tuple uniquely. Those set of attributes is called key

2.1.2.1.1. key has two properties:

2.1.2.1.1.1. It should be unique for all tuples.

2.1.2.1.1.2. It can’t have NULL values.

2.1.2.2. IT IS CALLED KEY ATTRIBUTE

2.1.3. Referential Integrity

2.1.3.1. When one attribute of a relation can only take values from other attribute of same relation or any other relation, it is called referential integrity. Let us suppose we have 2 relations STUDENT ROLL_NO NAME ADDRESS PHONE AGE BRANCH_CODE 1 RAM DELHI 9455123451 18 CS 2 RAMESH GURGAON 9652431543 18 CS 3 SUJIT ROHTAK 9156253131 20 ECE 4 SURESH DELHI 18 IT BRANCH BRANCH_CODE BRANCH_NAME CS
COMPUTER SCIENCE IT INFORMATION TECHNOLOGY ECE ELECTRONICS AND COMMUNICATION ENGINEERING CV CIVIL ENGINEERING BRANCH_CODE of STUDENT can only take the values which are present in BRANCH_CODE of BRANCH which is called referential integrity constraint. The relation which is referencing to other relation is called REFERENCING RELATION (STUDENT in this case) and the relation to which other relations refer
is called REFERENCED RELATION (BRANCH in this case).

2.1.3.2. ANOMALIES

2.1.3.2.1. An anomaly is an irregularity, or something which deviates from the expected or normal state. When designing databases, we identify three types of anomalies: Insert, Update and Delete.

2.1.3.2.1.1. InserT

2.1.3.2.1.1.1. We can’t insert a row in REFERENCING RELATION if referencing attribute’s value is not present in referenced attribute value. e.g.; Insertion of a student with BRANCH_CODE ‘ME’ in STUDENT relation will result in error because ‘ME’ is not present in BRANCH_CODE of BRANCH.

2.1.3.2.1.2. Deletion/ Updation

2.1.3.2.1.2.1. We can’t delete or update a row from REFERENCED RELATION if value of REFERENCED ATTRIBUTE is used in value of REFERENCING ATTRIBUTE. e.g; if we try to delete tuple from BRANCH having BRANCH_CODE ‘CS’, it will result in error because ‘CS’ is referenced by BRANCH_CODE of STUDENT, but if we try to delete the row from BRANCH with BRANCH_CODE CV, it will be deleted as the value is not been used by
referencing relation.

2.1.3.2.1.2.1.1. It can be handled by following method:

2.1.3.2.1.2.1.1.1. ON UPDATE CASCADE

2.1.3.2.1.2.1.1.1.1. It will update the REFERENCING ATTRIBUTE in REFERENCING RELATION if attribute value used by REFERENCING ATTRIBUTE is updated in REFERENCED RELATION. e.g;, if we update a row from BRANCH with BRANCH_CODE ‘CS’ to ‘CSE’, the rows in STUDENT relation with BRANCH_CODE CS (ROLL_NO 1 and 2 in this case) will be updated with BRANCH_CODE ‘CSE’.

2.1.3.2.1.2.1.1.2. ON DELETE CASCADE

2.1.3.2.1.2.1.1.2.1. will delete the tuples from REFERENCING RELATION if value used by REFERENCING ATTRIBUTE is deleted from REFERENCED RELATION. e.g;, if we delete a row from BRANCH with BRANCH_CODE ‘CS’, the rows in STUDENT relation with BRANCH_CODE CS (ROLL_NO 1 and 2 in this case) will be deleted.

3. KEYS
3.1. SUPER KEYS

3.1.1. Any set of attributes that allows us to identify unique rows (tuples) in a given relation are known as super keys. Out of these super keys we can always choose a proper subset among these which can be used as a primary key. Such keys are known as Candidate keys. If there is a combination of two or more attributes which is being used as the primary key then we call it as a Composite key.

4. relations
4.1. types

4.1.1. binary

4.1.1.1. between 2 entities

4.1.2. ternary

4.1.2.1. between 3 entities

4.1.3. recursive

4.1.3.1. between entity and itself

4.1.3.1.1. worker manges other workers

4.2. cardinality

4.2.1. one to many

4.2.2. many to many

5. BASIC COMPONENTS
5.1. Tuple

5.1.1. Each row in the relation is known as tuple.

5.2. Column

5.2.1. Column represents the set of values for a particular attribute. The column ROLL_NO is extracted from relation STUDENT.
5.3. Entity

5.3.1. a real-world thing or a real-world object which is distinguishable from other objects in the real world.

5.3.1.1. entitiy

5.3.2. Each table is entity

5.3.3. strength

5.3.3.1. weak

5.3.3.1.1. does not have a primary key

5.3.3.1.1.1. ROOM can only exist in a BUILDING

5.3.3.1.2. dependent on a strong entity

5.3.3.2. strong

5.3.3.2.1. complete by itself and is not dependent on any other entity type.

5.3.3.2.1.1. TIRE might be considered as a strong entity because it also can exist without being attached to a CAR

5.3.3.2.2. has primary key

5.4. Attribute

5.4.1. Attributes are the properties that define a relation.

5.4.1.1. Attribute

Link:
https://www.geeksforgeeks.org/types-of-attributes-in-er-model/

5.4.1.1.1. complexity

5.4.1.1.1.1. Simple

5.4.1.1.1.1.1. An attribute that cannot be further subdivided into components is a simple attribute. ‫ملوش تفاصيل‬

5.4.1.1.1.1.1.1. SSN

5.4.1.1.1.2. Composite

5.4.1.1.1.2.1. An attribute that can be split into components is a composite attribute.

5.4.1.1.1.2.1.1. The address can be further split into house number, street number, city, state, country, and pin code, the name can also be split into first name middle name, and last name.

5.4.1.1.2. no. of Value

5.4.1.1.2.1. Single-valued

5.4.1.1.2.1.1. The attribute which takes up only a single value for each entity instance is a single-valued attribute. ‫ال يحتمل اال قيمة واحدة‬

5.4.1.1.2.1.1.1. The age of a student.

5.4.1.1.2.2. Multi-valued

5.4.1.1.2.2.1. The attribute which takes up more than a single value for each entity instance is a multi-valued attribute. ‫يحتمل اكثر من قيمة‬

5.4.1.1.2.2.1.1. Phone number

5.4.1.1.3. source of data

5.4.1.1.3.1. Stored

5.4.1.1.3.1.1. attribute which are physically stored in the database

5.4.1.1.3.1.1.1. marks of student

5.4.1.1.3.2. Derived

5.4.1.1.3.2.1. An attribute that can be derived from other attributes

5.4.1.1.3.2.1.1. average marks of a student.

5.4.1.1.4. Complex

5.4.1.1.4.1. Those attributes, which can be formed by the nesting of composite and multi-valued attributes, are called “Complex Attributes“. These attributes are rarely used in DBMS(DataBase Management System). That’s why they are not so popular.

5.4.1.1.4.1.1. Contact detail:A person can have many phone numbers,many e-mail addresses,home addresses etc.

6. symbols in ER Diagrams:

Link:
https://www.guru99.com/er-diagram-tutorial-dbms.html

6.1. Rectangles: This Entity Relationship Diagram symbol represents entity types
6.2. Ellipses : Symbol represent attributes

6.3. Diamonds: This symbol represents relationship types

6.4. Lines: It links attributes to entity types and entity types with other relationship types

6.5. Primary key: attributes are underlined

6.6. Double Ellipses: Represent multi-valued attributes

7. Why use ER Diagrams


7.1. Helps you to define terms related to entity relationship modeling
7.2. Provide a preview of how all your tables should connect, what fields are going to be on each table

7.3. Helps to describe entities, attributes, relationships

7.4. ER diagrams are translatable into relational tables which allows you to build databases quickly

7.5. ER diagrams can be used by database designers as a blueprint for implementing data in specific software applications

7.6. The database designer gains a better understanding of the information to be contained in the database with the help of ERP diagram

7.7. ERD Diagram allows you to communicate with the logical structure of the database to users

You might also like