LAKIREDDY BALI REDDY COLLEGE OF ENGINEERING

(AUTONOMOUS)
Accredited by NAAC & NBA (Under Tier - I) ISO 9001:2015 Certified Institution Approved by
AICTE, New Delhi. and Affiliated to JNTUK, Kakinada
L.B. REDDY NAGAR, MYLAVARAM, KRISHNA DIST., A.P.-521 230.
DEPARTMENT OF INFORMATION TECHNOLOGY

20CS03-DBMS
Program & Semester: [Link] & ISEM
AcademicYear:2025 - 26

UNIT II
Module 1: EntityRelationshipModel:
s
The ER model ER model concept defines the conceptual view of a
database. It works around real- world entities and the associations among them.
At view level, the ER model is considered a good option for designing databases.
Entity Sets
⚫ An entity is a “thing” or “object” in the real world that is distinguishable from
all other objects.
⚫ An entity is represented by a set of attributes.
⚫ An entity set is a set of entities of the same type that share the same
properties, or attributes.
⚫ Attributes are descriptive properties possessed by each member of an entity
set.
⚫ Entity sets do not need to be disjoint.
⚫ For each attribute, there is a set of permitted values, called the domain, or
value set, of that attribute.
⚫ An attribute, as used in the E-R model, can be characterized by the following
attribute types
 Simple and composite attributes
 Single-valued and multivalued attributes
 Derived attribute
Simple attribute: Simple attributes are atomic values, which cannot be divided
further. For example, a student's phone number is an
atomic value of 10 digits.
Composite attribute: Composite attributes are made of more than one simple
attribute. For example, a student's complete name
may have first_name and last_name.
Derived attribute: Derived attributes are the attributes that do not exist can be
derived from data_of_bin the physical database, but
their values are derived from other attributes present
in the database. For example, average_salary in a
department should not be saved directly in the
database, instead it can be derived. For another
example, age can be derived from date_of_b irth.
Single-value attribute: Single-value attributes contain single value. For
example − Social_Security_Number.
Multi-value attribute: Multi-value attributes may contain more than one values.
For example, a person can have more than one
phone number, email_address, etc.
⚫ An attribute takes a null value when an entity does not have a value
for it. The null value may indicate “not applicable”—that is, that the
value does not exist for the entity.
⚫ Null can also designate that an attribute value is unknown.
Keys
Key is an attribute or collection of attributes that uniquely identifies an entity
among entity set.
For example, the roll_number of a student makes him/her identifiable
among students.
Super Key: A set of attributes (one or more) that collectively identifies an entity
in an entity set.
Candidate Key: A minimal super key is called a candidate key. An entity set may
have more than one candidate key.
Primary Key: A primary key is one of the candidate keys chosen by the database
designer to uniquely identify the entity set.

Entity Types

There are two types of entities are there.

Strong Entity: A Strong entity is an entity which has a primary key as an
attribute.
Weak Entity: Weak Entity is an entity that depends on another entity. Weak entity
does not have key attribute of their own.
 Relationship Sets
⚫ A relationship is an association among several entities
⚫ A relationship set is a set of relationships of the same type. Formally, it is
a mathematical relation on n ≥ 2 (possibly nondistinct) entity sets. If E1,
E2, . . .,En are entity sets, then a relationship set R is a subset of
{(e1, e2, . . . , en) | e1 ∈ E1, e2 ∈ E2, . . . , en ∈ En}
where (e1, e2, . . . , en) is a relationship.
Degree of Relationship
The number of participating entities in a relationship defines the degree of the
relationship.
⚫ Binary = degree 2
⚫ Ternary = degree 3
⚫ n-ary = degree n
Types of Relationships: -
⚫ Binary Relationship
⚫ Ternary Relationship
⚫ Recursive Relationship
Binary Relationship:
A Binary Relationship is the relationship between two different Entities i.e. it is a
relationship of role group of one entity with the role group of another entity.
There are three types of cardinalities for Binary Relationships:
⚫ 1. One-to-One
⚫ 2. One-to-many
⚫ 3. Many-to-Many
One-to-One
Here one role group of one entity is mapped to one role group of another entity. In
simple terms one instance of one entity is mapped with only one instance of another
entity. In this type the primary key of one entity must be available as foreign key in
other entity.
Example: consider two entities Person and Driver_License.
One Person should have only one Driver License number.
One-to-Many
One role group of one entity is mapped with many role groups of second entity and
one role group of second entity is mapped with one role group of first entity.
Example: consider two entities Project and Employee. One Project can have many
Employee's working on it but one Employee will always be engaged in only one
Project.
Many-to-Many
One role group of one entity is mapped with many role groups of second entity and
one role group of second entity is mapped with many role groups of first entity. In
these kind of relationships a third table is always associated that defines the
relationship between the two entities.
Example: Consider two entities Student and Books.
⚫ Many Students can have a Book and many Books can be issued to a Student so
in this way this is a many-to-many relationship.
Recursive Relationship
A relationship between two entities of similar entity type is called a recursive
relationship.
Here the same entity type participates more than once in a relationship type with
a different role for each instance.

Ternary Relationship
Association between three entities are called ternary relationship.
Generalization, Specialization and Aggregation in ER model are used
for data abstraction in which abstraction mechanism is
used to hide details of a set of objects.
Generalization
Generalization is the process of extracting common properties from a set of
entities and create a generalized entity from it. It is a bottom-up approach in
which two or more entities can be generalized to a higher level entity if they have
some attributes in common
based on their
characteristics. It is a top-
down approach where higher
level entity is specialized
into two or more lower level
entities.
between an entity and a
relationship which may be
required in some scenarios. In
those cases, a relationship
with its iscorrespoding entities
For Example, Employee working for a project may require some machinery. So,
REQUIRE relationship needed between relationship WORKS_FOR and entity
is aggregated into a higher
MACHINERY. Using aggregation, WORKS_FOR relationship with its entities
EMPLOYEE and PROJECT is aggregated into single entity and relationship
level
REQUIRE entity.
is created between aggregated entity and MACHINERY.
Relationship Constraints
The limitations which are imposed on a relationship is called Relationship
Constraints. There are two types of Relationship constraints are there. Those are
1) Cardinality Ratio
2) Participation Constraint
Cardinality Ratio
Cardinality defines the number of entities in one entity set, which can be
associated with the number of entities of other set via relationship set.
 One-to-one − One entity from entity set A can
be associated with at most one entity of
One-to-many − One entity from entity set A can be associated with more than
one entity set set
entities of entity B Band vice
however versa.
an entity from entity set B, can be associated
with at most one entity.

Many-to-one − More than one entities from entity set A can be associated with at
most one entity of entity set B, however an entity from entity set B can be
associated with more than one entity from entity set A.

Many-to-many − One entity from A can be associated with more than one entity
from B and vice versa.
Participation
Constraints
Participation constraints define the least number of relationship instances in
which an entity must compulsorily participate. There are two types of
participation constraint

Total Participation
 It specifies that each entity in the entity set must compulsorily participate in
at least one relationship instance in that relationship set.
 That is why, it is also called as mandatory participation.
 Total participation is represented using a double line between the entity set
and relationship set.
Example ofTotal participation

Here,
⚫ Double line between the entity set “Student” and relationship set “Enrolled
in” signifies total participation.
⚫ It specifies that each student must be enrolled in at least one course.
Partial Participation
⚫ It specifies that each entity in the entity set may or may not participate in the
relationship instance in that relationship set.
⚫ That is why, it is also called as optional participation.
⚫ Partial participation is represented using a single line between the entity set
and relationship set.
Example of partial participation

Here,
⚫ Single line between the entity set “Course” and relationship set “Enrolled in”
signifies partial participation.
⚫ It specifies that there might exist some courses for which no enrolments are
made.
Relationship between Cardinality and Participation Constraints-
Minimum cardinality tells whether the participation is partial or total.
⚫ If minimum cardinality = 0, then it signifies partial participation.
⚫ If minimum cardinality = 1, then it signifies total participation.

Maximum cardinality tells the maximum number of entities that participates in a

relationship set.
ER- Diagram for College Database
ER-Diagram for Hospital Management System
ER-Diagram for Railway Reservation System
Reduction of ER-Diagram to Tables
Following rules are used for converting an ER diagram into the tables
Rule-01: For Strong Entity Set With Only Simple Attributes
Strong entity set with only simple attributes will require only one table
in relational model.
⚫ Attributes of the table will be the attributes of the entity set.
⚫ The primary key of the table will be the key attribute of the entity set.

Roll_no Name sex

Schema : Student ( Roll_no , Name , Sex )

Rule-02: For Strong Entity Set With Composite Attributes
A strong entity set with any number of composite attributes will require only one
table in relational model. While conversion, simple attributes of the composite
attributes are taken into account and not the composite attribute itself.

Roll_no First_name Last_name City Street House_no

Schema : Student ( Roll_no , First_name , Last_name , House_no , Street , City )

Rule-03: For Strong Entity Set With Multi Valued Attributes
A strong entity set with any number of multi valued attributes will require
two tables in relational model.
⚫ One table will contain all the simple attributes with the primary key.
⚫ Other table will contain the primary key and all the multi valued attributes.

Roll_no city Roll_no Mobile_no

Schema : Student ( Roll_no , city) Schema : Student ( Roll_no , Mobile_no)

Rule-04: Translating Relationship Set into a Table
Relationship set will require one table in the relational model.
Attributes of the table are-
⚫ Primary key attributes of the participating entity sets
⚫ Its own descriptive attributes if any.
⚫ Set of non-descriptive attributes will be the primary key

If we consider the overall ER diagram, three tables will be required in

relational model-
 One table for the entity set “Employee”
 One table for the entity set “Department”
 One table for the relationship set “Works in”
Emp_no Emp-name salary

Employee Table

Dept_id Dept_name

Department Table

Emp_no Dept_id since

Works in Table
Rule-05: For Binary Relationships With Cardinality Ratios
The following four cases are possible

Case-01: Binary relationship with cardinality ratio m:n

Here, three tables will be required-

1. A ( a1 , a2 )
2. R ( a1 , b1 )
3. B ( b1 , b2 )
 Case-02: For Binary
Relationship With Cardinality
Ratio 1:n

Here, two tables will be required-

1. A ( a1 , a2 )
2. BR ( a1 , b1 , b2 )

Here, combined table will be drawn for the entity set B and relationship set R.
Case-03: For Binary Relationship
With Cardinality Ratio m:1

Here,two tables will be required-

1. AR ( a1 ,a2 ,b1 )
2. 2.B ( b1 ,b2 )

Here, combined table will be drawn for the entity setA and relationship set R.
Case-04: For Binary Relationship With Cardinality Ratio 1:1

Here, two tables will be required. Either combine ‘R’ with ‘A’ or ‘B’
Way-01:
1. AR ( a1 , a2 , b1 )
2. B ( b1 , b2 )

Way-02:
⚫ 1. A ( a1 , a2 )
⚫ 2. BR ( a1 , b1 , b2 )
While determining the minimum number of tables required for binary
relationships with given cardinality ratios, following thumb rules must be kept in
mind-
⚫ For binary relationship with cardinality ration m : n , separate and individual
tables will be drawn for each entity set and relationship.
⚫ For binary relationship with cardinality ratio either m : 1 or 1 : n , always
remember “many side will consume the relationship” i.e. a combined table
will be drawn for many side entity set and relationship set.
⚫ For binary relationship with cardinality ratio 1 : 1 , two tables will be
required. You can combine the relationship set with any one of the entity sets.

Rule-06: For Binary Relationship with Both Cardinality

Constraints and Participation Constraints
⚫ Cardinality constraints will be implemented as discussed in Rule-05.
⚫ Because of the total participation constraint, foreign key acquires NOT
NULL constraint i.e. now foreign key can not be null.
 Case-01: For Binary Relationship
With Cardinality Constraint
and Total Participation
Constraint From One Side

Because cardinality ratio = 1 : n , so we will combine the entity set B and

relationship set R.
Then, two tables will be required-
1. A ( a1 , a2 )
2. BR ( a1 , b1 , b2 )
Because of total participation, foreign key a1 has acquired NOT NULL
constraint, so it can’t be null now.
 Case-02: For Binary Relationship
With Cardinality Constraint
and Total Participation
Constraint From Both Sides

If there is a key constraint from both the sides of an entity set with total
participation, then that binary relationship is represented using only single table.

Here, Only one table is required.

ARB ( a1 , a2 , b1 , b2 )
 Extended Entity Relationship Model
 It includes all modelling concepts of basic ER model.
 It includes additional concepts like
⚫ Sub Class and Super Class
⚫ Specialization and Generalization
⚫ Union or Category
⚫ Aggregation
⚫ Relationship Inheritance
Sub Class and Super Class
Sub class and Super class relationship leads the concept of Inheritance. The
relationship between sub class and super class is denoted with symbol.
Super Class
Super class is an entity type that has a relationship with one or more subtypes.
An entity cannot exist in database merely by being member of any super class.
For example: Shape super class is having sub groups as Square, Circle,
Triangle.
Sub Class
⚫ Sub class is a group of entities with unique attributes.
⚫ Sub class inherits properties and attributes from its super class.
For example: Square, Circle, Triangle are the sub class of Shape super class.

Category or Union
⚫ Category represents a single super class or sub class relationship with more
than one super class.
⚫ It can be a total or partial participation.
For example: Car booking, Car owner can be a person, a bank (holds a possession
on a Car) or a company. Category (sub class) → Owner is a subset of
the union of the three super classes → Company, Bank, and Person.
A Category member must exist in at least one of its super classes.
Constraints on Specialization & Generalization
There are 2 types of constraints are available on specialization & Generalization.
Those are Disjointness and Completeness.

Disjointness
Disjointness: An entity can be a member of at most one of the subclass
entities.
Non Disjointness: An entity is not a member of anyone of the subclass
entities.

Completeness Constraint:
Total: It specifies that every entity in the super class must be a member
of some sub class. It is indicated by double line.
Partial: It specifies that entity need not belong to any of the subclass. It
is indicated with single line.
 LAKIREDDY BALI REDDY COLLEGE OF ENGINEERING
(AUTONOMOUS)
Accredited by NAAC & NBA (Under Tier - I) ISO 9001:2015 Certified Institution
Approved by AICTE, New Delhi. and Affiliated to JNTUK, Kakinada
L.B. REDDY NAGAR, MYLAVARAM, KRISHNA DIST., A.P.-521 230.
DEPARTMENT OF INFORMATION TECHNOLOGY

20CS03-DBMS
Program & Semester: [Link] & IV SEM
AcademicYear:2025 – 26

U N I T II
Module 2: Relational Data Model and
Language
Relational Data Model Concepts
Codd proposed the Relational data model in 1970. Before 1970 most of the
database systems follows one of the two data models. Those are
 Hierarchical Data Model
 Network Data Model
⚫ The relational model represents the database as a collection of relations.
⚫ A relation is thought of as a table of values, each row in the table represents a
collection of related data values.
⚫ A row represents a fact that typically corresponds to a real-world entity or
relationship.
⚫ The table name and column names are used to help to interpret the meaning
of the values in each row.
Example: Student relationship.

Relational data model is the primary data model, which is used widely around
the world for data storage and processing. This model is simple and it has all the
properties and capabilities required to process data with storage efficiency.

A Relation mainly contains two things

 Relation Schema
 Relation Instance
Relation Schema
Relation schema specifies the name of the relation and name of each field and
domain of each field. Here domain specifies that the set of values that are
associated to the given field.

A relation schema R, denoted by R(A1, A2, ...,An), is made up of a relation name

R and a list of attributes, A1, A2, ..., An. Each attribute Ai is the name of a role
played by some domain D in the relation schema R. D is called the domain of Ai
and is denoted by dom(Ai).

A relation (or relation state) r of the relation schema R(A1, A2, ..., An) can be
denoted by r(R), is a set of n-tuples r = {t1, t2, ..., tm}.
⚫ Each n-tuple t is an ordered list of n values t =<v1, v2, ..., vn>, where each
value vi, 1 ≤ i ≤ n, is an element of dom (Ai)

Definition of a relation can be restated more formally using set theory concepts. A
relation (or relation state) r(R) is a mathematical relation of degree n on the
domains dom(A1), dom(A2), ..., dom(An), which is a subset of the Cartesian
product (denoted by ×) of the domains that define R:
r(R) ⊆ (dom(A1) × dom(A2) × ... × dom(An))
relation schema.
Ex:The
Studentdegree (or
(sid: string, arity) login:string,
name:string, of a relation
age:integer,is
gpa:real)
the number of attributes in its
Relation Instance
An instance of a relation is set of tuples also called as records, in which each
tuple has a same number of fields as the relation schema.

Domains, Attributes, Tuples, and Relations

A domain D is a set of atomic values. A data type or format is also specified
for each domain. It is also useful to specify a name for the domain, to help in
interpreting its values.
⚫ Degree or arity of a Relation is Number of fields in a relation.
⚫ Cardinality of a relation instance is number of tuples in it.
Tables
In relational data model, relations are saved in the format of Tables. This format
stores the relation among entities. A table has rows and columns, where rows
represents records and columns represent the attributes.
Tuple
A single row of a table, which contains a single record for that relation is called a
tuple.
Relation instance
A finite set of tuples in the relational database system represents relation
instance. Relation instances do not have duplicate tuples.
Relation schema
A relation schema describes the relation name table name, attributes, and their
names.
Relation key
Each Relation has one or more attributes, known as relation key, which can
identify the row in the relation table uniquely.
Attribute domain
Every attribute has some pre-defined value scope, known as attribute domain.
Integrity Constraints
Set of rules or conditions specified on a database schema and restricts the data
that can be stored in an instance of the database. They ensures that the data
insertion, updating and other processes have to be performed in such way that
data integrity is not affected.
Types of integrity constraints
 Key constraints
 Domain constraints
 Referential integrity constraints
 Entity Integrity Constraints
Domain constraints

Domain constraints can be defined as the definition of a valid set of values for an
attribute. The data type of domain includes string, character, integer, time, date,
currency, etc.

The value of the attribute must be available in the corresponding domain .

Entity integrity constraints
⚫ The entity integrity constraint states that primary key value can't be
null.
⚫ This is because the primary key value is used to identify individual
rows in relation and if the primary key has a null value, then we can't
identify those rows.
⚫ A table can contain a null value other than the primary key field.
Referential Integrity Constraints
⚫ A referential integrity constraint is specified between two tables.
⚫ In the Referential integrity constraints, if a foreign key in Table 1 refers to the
Primary Key of Table 2, then every value of the Foreign Key in Table 1 must
be available in Table 2 or NULL.
Key constraints
⚫ Keys are the entity set that is used to identify an entity within its entity
set uniquely.
⚫ An entity set can have multiple keys, but out of which one key will be
the primary key.
⚫ A primary key can contain a unique value in the relational table.
RelationalAlgebra
Relational Algebra is procedural query language, which takes Relation as input
and generate relation as output. It uses operators to perform queries. An operator
can be either unary or binary.
Relational algebra mainly provides theoretical foundation for relational databases
and SQL.
Relational algebra is performed recursively on a relation and intermediate results
are also considered relations.
We can divide the operations in two categories:
1. Basic Operations
2. Derived Operations
Basic/Fundamental Operations:
1. Select (σ)
2. Project (∏)
3. Union (𝖴)
4. Set Difference (-)
5. Cartesian product (X)
6. Rename (ρ)
Derived Operations
1. Natural Join (⋈)
2. Left, Right, Full outer join (⟕, ⟖, ⟗)
3. Intersection (∩)

Select Operator (σ)

Select Operator is denoted by sigma (σ) and it is used to find the tuples (or rows)
in a relation (or table) which satisfy the given condition.

If you understand little bit of SQL then you can think of it as a where clause in
SQL, which is used for the same purpose.
Syntax
σ Condition/Predicate (Relation/Table name)
Customer_Id Customer_Name Customer_City
C101 Steve Agra
00 Raghu Agra
C101 Chaitan Noid
11 ya a
C101 Ajeet Delhi
Example
σ Customer_City="Agra" (CUSTOMER)

Customer_Id Customer_Name Customer_City

C10100 Steve Agra
C10111 Raghu Agra

Project Operator (∏)

Project operator is denoted by ∏ symbol and it is used to select desired columns
(or attributes) from a table (or relation).

Project operator in relational algebra is similar to the Select statement in SQL.

Syntax

∏ column_name1, column_name2, ...., column_nameN (table_name)

CUSTOMER with three columns, we
want to fetch only two columns of
the table, which we can do with
the help
∏ Customer_Id, of Project
Customer_Name (CUSTOMER) Operator ∏.

Customer_Id Customer_Name
C101 Steve
00 Raghu
C101 Chaitan
11 ya
C101 Ajeet
15 Carl
C101
17
C101
18
Union Operator (𝖴)
Union operator is denoted by 𝖴 symbol and it is used to select all the rows (tuples)
from two tables (relations).

Lets discuss union operator a bit more. Lets say we have two relations R1 and R2
both have same columns and we want to select all the tuples(rows) from these
relations then we can apply the union operator on these relations.

Note: The rows (tuples) that are present in both the tables will only appear once in
the union set. In short you can say that there are no duplicates present after the
union operation.
r 𝖴 s = { t | t ∈ r or t ∈ s}

For a union operation to be valid, the following conditions must hold

 r, and s must have the same number of attributes.
 Attribute domains must be compatible.
 Duplicate tuples are automatically eliminated.
Synt
ax
table_name1 𝖴 table_name2
Course_Id Student_Name Student_Id
C101 Aditya S901
C104 Aditya S901
C106 Steve S911
C109 Paul S921
C115 Lucy S931

Student_Id Student_Name Student_Age

S901 Aditya 19
S911 Steve 18
S921 Paul 19
S931 Lucy 17
S941 Carl 16
S951 Rick 18
∏ Student_Name (COURSE) 𝖴 ∏ Student_Name (STUDENT)

Student_Name
Aditya
Carl
Paul
Lucy
Rick
Steve

As you can see there are no duplicate names present in the output even
though we had few common names in both the tables,also in the
COURSE table we had the duplicate name itself.
Set Difference (-)
Set Difference is denoted by – symbol. Lets say we have two relations R1 and
R2 and we want to select all those tuples(rows) that are present in Relation R1
but not present in Relation R2, this can be done using Set difference R1 – R2.
Syntax
table_name1 - table_name2
Example
∏ Student_Name (STUDENT) - ∏ Student_Name (COURSE)

A query to select those student names that are present in STUDENT table but not
present in COURSE table

Student_Name
Carl
Rick
Cartesian product (X)
Cartesian Product is denoted by X symbol.
Lets say we have two relations R1 and R2 then the cartesian product of these two
relations (R1 X R2) would combine each tuple of first relation R1 with the each
tuple of second relation R2.
Syntax
R1 X R2
R1
A B
AA 100
BB 200
CC 300
R2

X Y
XX 99
YY 11
ZZ 101
R1 X R2

A B X Y
AA 100 XX 11
AA 100 YY 99
AA 100 ZZ 101
BB 200 XX 99
BB 200 YY 11
BB 200 ZZ 101
CC 300 XX 99
CC 300 YY 11
CC 300 ZZ 101
Rename (ρ)
Rename (ρ) operation can be used to rename a relation or an attribute of a
relation.

Syntax
ρ(new_relation_name, old_relation_name)

Example
Customer_Id Customer_Name Customer_City
C10100 Steve Agra
C10111 Raghu Agra
C10115 Chaitanya Noida
C10117 Ajeet Delhi
C10118 Carl Delhi
ρ(CUST_NAMES, ∏Customer_Name (CUSTOMER))
C U S T _ N AM E S
Steve
Raghu
Chaitanya
Ajeet
Carl
Derived Operators
Intersection Operator (∩)
Intersection operator is denoted by ∩ symbol and it is used to select
common rows (tuples) from two tables (relations).
Lets say we have two relations R1 and R2 both have same columns and
we want to select all those tuples(rows) that are present in both the
relations, then in that case we can apply intersection operation on these
two relations R1 ∩ R2.

Syntax
table_name1 ∩ table_name2
Example
∏ Student_Name (COURSE) ∩ ∏ Student_Name (STUDENT)

Student_Name
Aditya
Steve
Paul
Lucy
JOIN
An SQL Join is used to combine data from two or more tables, based on a
common field between them.
Example
Orders table

OrderID CustomerID OrderDate

10308 2 1996-09-18
10309 37 1996-09-19
10310 77 1996-09-20

Customers table

Custom CustomerName ContactName Country

erI D
1 Alfreds Futterkiste Maria Anders Germany
2 Ana Trujillo Ana Trujillo Mexico
Emparedados y
helados
3 Antonio Moreno Antonio Moreno Mexico
Taquería
The "CustomerID" column in the "Orders" table refers to the "CustomerID" in the
"Customers" table. The relationship between the two tables above is the
"CustomerID" column.

SELECT [Link], [Link], [Link]

FROM Orders
INNER JOIN Customers ON [Link]=[Link];

OrderID CustomerName OrderDate

10308 Ana Trujillo Emparedados y helados 9/18/1996
Different Types of SQL JOINs
Here are the different types of the JOINs in SQL:

(INNER) JOIN: Returns records that have matching values in both tables
LEFT (OUTER) JOIN: Returns all records from the left table, and the matched
records from the right table
RIGHT (OUTER) JOIN: Returns all records from the right table, and the
matched records from the left table
FULL (OUTER) JOIN: Returns all records when there is a match in either left or
right table.
Left Outer Join
Returns all records from the left table, and the matched records from the right
table
The result of a left outer join (or simply left join) for
tables Employee and Location always contains all records of the "left" table
(Employee), even if the join-condition does not find any matching record in the
"right" table (Location).

select * from employee left outer join on [Link] =

[Link];
Right outer Join
Returns all records from the right table, and the matched records from the
left table.
A right outer join (or right join) closely resembles a left outer join, except
with the treatment of the tables reversed. Every row from the "right" table
(Location) will appear in the joined table at least once. If no matching
row from the "left" table (Employee) exists, NULL will appear in
columns from Employee for those records that have no match in
Location.
select * from employee right outer join on [Link] =
[Link];