SlideShare a Scribd company logo
Unit 2
 Overview of Database Design Process
 Example Database Application (COMPANY)
 ER Model Concepts
 Entities and Attributes
 Entity Types, Value Sets, and Key Attributes
 Relationships and Relationship Types
 Weak Entity Types
 Roles and Attributes in Relationship Types
 ER Diagrams - Notation
 ER Diagram for COMPANY Schema
Overview of Database Design Process
 Two main activities:
 Database design
 Applications design
 Focus of this topic is on database design
 To design the conceptual schema for a database
application
 Applications design focuses on the programs and
interfaces that access the database
 Generally considered part of software engineering
Overview of Database Design Process
Entities and Attributes
Entity – A thing in the real world object with an
independent existence.
An entity may be an object with a physical
existence (car,
person ,house) or it may be an object with a
conceptual existence( a company, a university)
Each entity has attributes – the particular
properties that describe it.
 Composite versus simple attributes.
 Composite attributes can be divided in to smaller
subparts
 Simple attributes that are not divided are
called simple or atomic attributes.
 Single valued vs Multivalued attributes
 Most attributes have a single value for a particular
entity.
 Eg. Age is a single valued attribute of a person.
 Some attributes may have more than one value for
a particular entity
 Eg. Differrent people can have different numbers of
values for the College degrees atrributes
 Stored vs Derived Attributes
 Complex attributes
 In general, composite and multi-valued attributes may be
nested arbitrarily to any number of levels although this is
rare. For example, PreviousDegrees of a STUDENT is a
composite multi-valued attribute denoted by
{PreviousDegrees (College, Year, Degree, Field)}.
 {AddressPhone( { Phone(AreaCode,PhoneNumber)},
Address(streetAddress
(number,street,apartmentNumber),city,state,zip) ) }
Entity Types, Entity sets
 A database usually contains groups of entities
that are similar.
 An entity type defines a collection (or set) of
entities that have the same attributes.
 Each entity type in the database is described by
its name and attributes.
 The collection of all entities of a particular entity
type in the database at any point in time is called
an entity set.
Unit 2 new.pptx for the actual dbms chad
Key attributes of an entity type
 An entity type usually has one or more attributes
whose values are distinct for each individual
entity in the entity set. Such an attribute is called
a key attribute
Relationships and Relationship Types
 A relationship relates two or more distinct entities with a specific
meaning.
 For example, EMPLOYEE John Smith works on the ProductX
PROJECT, or EMPLOYEE Franklin Wong manages the Research
DEPARTMENT.
 Relationships of the same type are grouped or typed into a
relationship type.
 For example, the WORKS_ON relationship type in which
EMPLOYEEs and PROJECTs participate, or the MANAGES
relationship type in which EMPLOYEEs and DEPARTMENTs
participate.
 The degree of a relationship type is the number of participating
entity types.
 Both MANAGES and WORKS_ON are binary relationships.
Example relationship instances of the WORKS_FOR relationship
between EMPLOYEE and DEPARTMENT
e1 
e2 
e3 
e4 
e5 
e6 
e7 
EMPLOYEE
r1
r2
r3
r4
r5
r6
r7
WORKS_FOR
 d1
 d2
 d3
DEPARTMENT
Relationship Degree, Role Names
 The degree of a relationship type is the number
of participating entity types.
 Binary
 Ternary
 Quandary
 Role name
 Recursive relationships
Constraints on binary relationship types
 1:1
 1:N
 M:N
 M:N

 Participation constraints
 It specifies whether the existence of an entity
depends on its being related to another entity via
the relationship type.
 Total participation
 Partial participation
 Strong Entity types
 Weak Entity types
 Partial key
A Weak entity
type normally
has a partial key
which is the
attribute that can
uniquely identify
weak entities that
are related to the
same owner
entity.
ER Schema diagram of company DB
ER-DIAGRAM - NOTATION FOR ER SCHEMAS
Meaning
ENTITY TYPE
WEAK ENTITY TYPE
RELATIONSHIP TYPE
IDENTIFYING RELATIONSHIP TYPE
ATTRIBUTE
KEY ATTRIBUTE
MULTIVALUED ATTRIBUTE
COMPOSITE ATTRIBUTE
DERIVED ATTRIBUTE
TOTAL PARTICIPATION OF E2 IN R
CARDINALITY RATIO 1:N FOR E1:E2 IN R
STRUCTURAL CONSTRAINT (min, max) ON
PARTICIPATION OF E IN R
Symbol
E1 R E2
E1 R E2
R
(min,max)
E
N
 ER model has three main concepts:
 Entities (and their entity types and
entity sets)
 Attributes (simple, composite,
multivalued)
 Relationships (and their relationship
types and relationship sets)
ER Diagrams
 A company database needs to store information about employees
(identified by ssn, with salary and phone as attributes),
departments (identified by dno, with dname and budget as
attributes), and children of employees (with name and age as
attributes). Employees work in departments; each department is
managed by an employee; a child must be identified uniquely by
name when the parent (who is an employee; assume that only one
parent works for the company) is known. We are not interested in
information about a child once the parent leaves the company.
1
1
1
N
1
N
Notown Records has decided to store information about musicians
who perform on its albums
• Each musician that records at Notown has an SSN, a name, an
address, and a phone number.
 Each instrument used in songs recorded at Notown has a unique
identification number, a name (e.g., guitar, synthesizer, flute) and
a musical key (e.g., C, B-flat, E-flat).
 Each album recorded on the Notown label has a unique
identification number, a title, a copyright date, a format (e.g., CD
or MC), and an album identifier.
 Each song recorded at Notown has a title and an author.
 Each musician may play several instruments, and a given
instrument may be played by several musicians.
 Each album has a number of songs on it, but no song may appear
on more than one album.
 Each song is performed by one or more musicians, and a musician
may perform a number of songs.
 Each album has exactly one musician who acts as its producer. A
musician may produce several albums, of course.
M
N
N
1
N
1
M
N
ER-to-Relational Mapping Algorithm
 ER-to-Relational Mapping Algorithm
 Step 1: Mapping of Regular Entity Types
 Step 2: Mapping of Weak Entity Types
 Step 3: Mapping of Binary 1:1 Relation Types
 Step 4: Mapping of Binary 1:N Relationship Types.
 Step 5: Mapping of Binary M:N Relationship Types.
 Step 6: Mapping of Multivalued attributes.
 Step 7: Mapping of N-ary Relationship Types.
Unit 2 new.pptx for the actual dbms chad
Unit 2 new.pptx for the actual dbms chad
Relational Model
 Relational model represents the
database as a collection of relations.
What is Relation?
 A Relation is thought of as a table of values (rows and
columns)
 each row, or tuple, is a collection of related data values
 the degree of the relation is the number of attributes in the
relation
 each column represents an attribute
 each row is an instance of the relation
So, a relation is a table of facts.
 Each column contains the same attribute data with the same
data type
 Each row describes a real-world instance of the relation
 A Relational database contains one or more relations (or
tables).
In relational model terminology
Informal Terms Formal Terms
Table Relation
Column Attribute
Row Tuple
Values in a column Domain
Table Definition Schema of a Relation
Populated Table Extension
Formal Definition
 A domain has a logical definition:
 E.g., “Indian_phone_numbers” are the set of 10 digit
phone numbers valid in INDIA.
 A domain may have a data-type or a format defined
for it.
 E.g., Dates have various formats such as monthname,
date, year or yyyy-mm-dd, or dd mm,yyyy etc.
 An attribute designates the role played by the domain.
 E.g., the domain Date may be used to define attributes
“Invoice-date” and “Payment-date”.
 A relation schema R denoted by R(A1, A2, …, An ) is made
up of a relation name R and a list of attributes 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 denoted by dom (Ai )
 A relation schema is used to describe a relation
 R is called Relation.
 The degree of a relation is the number of attributes n
of its relation schema
 Relation state r of the relation scheme R(A1, A2, …, An )
also denoted by r(R) is a set of n-tuples r = {t1,t2..tn}
 Formally,
Given R(A1, A2, .........., An)
r(R)  dom (A1) X dom (A2) X ....X dom(An)
 R: schema of the relation
 r of R: a specific "value" or population of R.
 R is also called the intension of a relation
 r is also called the extension of a relation
Example
Characteristics of Relations
 Ordering of tuples in a relation r(R): The tuples in a
relation do not have any particular order. Even though
they appear to be in the tabular form.
 Ordering of values within a tuple. We will consider the
attributes in R(A1, A2, ..., An) and a relation state r(R) is set
of mappings r={t1,t2,….tm} the values in t=<v1, v2, ..., vn>
to be ordered .
 Values in a tuple: All values are considered atomic
(indivisible). A special null value is used to represent
values that are unknown or inapplicable to certain
tuples.
Relational Integrity Constraints
 Constraints are conditions that must hold on all
valid relation instances.
 Constraints on databases can generally be
divided into three categories:
 Constraints that are inherent in the data model – model
based constraints
 Constraints that can be directly expressed in the
schemas of the data model – schema based constraints
 Constraints that cannot be directly expressed in the
schemas of the data model –application based
constraints
Relational Integrity Constraints
 There are three main types of constraints:
1. Key constraints
2. Entity integrity constraints
3. Referential integrity constraints
Domain constraints and constraints on nulls.
Key Constraints
Entity Integrity
 Relational Database Schema: A set S of relation schemas that
belong to the same database. S is the name of the database.
S = {R1, R2, ..., Rn}
 Entity Integrity: The primary key attributes PK of each
relation schema R in S cannot have null values in any tuple of
r(R). This is because primary key values are used to identify
the individual tuples.
t[PK]  null for any tuple t in r(R)
 Note: Other attributes of R may be similarly constrained to
disallow null values, even though they are not members of the
primary key.
Referential Integrity
 A constraint involving two relations (the previous
constraints involve a single relation).
 Used to specify a relationship among tuples in two relations:
the referencing relation and the referenced relation.
 Tuples in the referencing relation R1 have attributes FK
(called foreign key attributes) that reference the primary
key attributes PK of the referenced relation R2. A tuple t1 in
R1 is said to reference a tuple t2 in R2 if t1[FK] = t2[PK].
 A referential integrity constraint can be displayed in a
relational database schema as a directed arc from R1.FK to
R2. PK
Referential Integrity Constraint
Statement of the constraint
The value in the foreign in key column (or
columns) FK of the referencing relation R1 can
be either:
1. a value of an existing primary key value of the
corresponding primary key PK in the referenced
relation R2,, or..
2. a null.
In case (2), the FK in R1 should not be a part of its
own primary key.
Other Types of Constraints
Semantic Integrity Constraints:
- constraints can be specified and enforced on a
relational database.
- E.g the salary of an employee should not exceed the salary
of the employee’s supervisor
Constraint specification language
- Constraints can be specified and enforced within the
application programs that update the database.
- E.g., “the max. no. of hours per employee for all
projects he or she works on is 56 hrs per week”
Update Operations on Relations
 INSERT a tuple.
 DELETE a tuple.
 MODIFY a tuple.
 The Insert operation
 Insert can violate any of the four types of constraints
 Domain constraints
 Key constraints
 Entity integrity constraints
 Referential integrity
 The Delete operation
 Delete operation can violate only referential integrity.
 The update operation
 Key and referential integrity
Unit 2 new.pptx for the actual dbms chad
Unit 2 new.pptx for the actual dbms chad
Super key is a collection of attributes or set of
attributes that uniquely identify the tuples.
Why do we need super key?
Super key is a superset from which we can
derive other keys.
Unit 2 new.pptx for the actual dbms chad
Unit 2 new.pptx for the actual dbms chad
Unit 2 new.pptx for the actual dbms chad
Unit 2 new.pptx for the actual dbms chad
Types of Keys
 Primary Key The attribute or combination of
attributes that uniquely identifies a row or
record in a relation is known as primary key.
 SuperKey: A key that can be uniquely used to
identify a database record, that may contain
extra attributes that are not necessary to
uniquely identify records x
Superkey is a set of columns in a table for which there are no two rows that will share the same
combination of values. So, the superkey is unique for each and every row in the table. A
superkey can also be just a single column.
Example of a superkey
Suppose we have a table that holds all the managers in a company, and that table is called
Managers. The table has columns called ManagerID, Name, Title, and DepartmentID.
Every manager has his/her own ManagerID, so that value is always unique in each and every
row. This means that if we combine the ManagerID column value for any given row with any
other column value, then we will have a unique set of values. So, for the combinations of
(ManagerID, Name), (ManagerID, TItle), (ManagerID, DepartmentID), (ManagerID, Name,
DepartmentID), etc
– there will be no two rows in the table that share the exact same combination of values,
because the ManagerID will always be unique and different for each row. This means that
pairing the Manager ID with any other column(s) will ensure that the combination will also be
unique across all rows in the table.
superkey – it’s any combination of column(s) for which that combination of values will be
unique across all rows in a table. So, all of those combinations of columns in the Manager
table that would be considered to be superkeys. Even the ManagerID column is considered to
be a superkey
Key Constraints
 Superkey of R: A set of attributes SK of R such that no two
tuples in any valid relation instance r(R) will have the
same value for SK. That is, for any distinct tuples t1 and
t2 in r(R), t1[SK]  t2[SK].
 Minimal superkey of R: A superkey from which we
cannot remove any attributes and still have the
uniqueness constraint in any two distinct tuples in any
state of the relation cannot have identical values for the
attributes in the key.
Example: The CAR relation schema:
CAR(State, Reg#, SerialNo, Make, Model, Year)
has two keys Key1 = {State, Reg#}, Key2 = {SerialNo}, which are also
superkeys. {SerialNo, Make} is a superkey but not a candidate
key.
 If a relation has several candidate keys, one is chosen
arbitrarily to be the primary key. The primary key
attributes are underlined.

More Related Content

Similar to Unit 2 new.pptx for the actual dbms chad (20)

PPTX
Database design
Sylviana Azizah
 
PPTX
E - R Models.pptx SQL and plsql database
ironman82715
 
PPTX
Entity Relationship Model
Slideshare
 
PPTX
Download different material from slide share
fanta teferi
 
PPTX
ER MODEL.pptx
TusharSingh711352
 
PPTX
Relation Model Database Pertemuan k.pptx
titisarwindartii
 
PPTX
Data Models.pptx
CheriviralaNikhil
 
PPT
18306_lec-2 (1).ppt
IshuIswarya3
 
PPTX
Data Models and Relational Database Design.pptx
niqqaanonymous211
 
PPTX
database_design_presentation, data base design presenttion
ahtms257
 
PPTX
Er diagrams presentation
Akanksha Jaiswal
 
PPTX
Er diagrams presentation
Akanksha Jaiswal
 
PDF
erdiagramspresentation-150826044953-lva1-app6891.pdf
vinayakjadhav94
 
PPTX
DBMS_Data Model,Keys,Attributes,Relationship.pptx
DrThenmozhiKarunanit
 
PPT
Data modeling using the entity relationship model
Jafar Nesargi
 
PDF
Db lec 02_new
Ramadan Babers, PhD
 
PDF
Unit 2 DBMS
DhivyaSubramaniyam
 
PPTX
Introduction of Database Design and Development
Er. Nawaraj Bhandari
 
PPT
database1
Monika Sharma
 
PPTX
DBMS Unit-2_Final.pptx
parimala123
 
Database design
Sylviana Azizah
 
E - R Models.pptx SQL and plsql database
ironman82715
 
Entity Relationship Model
Slideshare
 
Download different material from slide share
fanta teferi
 
ER MODEL.pptx
TusharSingh711352
 
Relation Model Database Pertemuan k.pptx
titisarwindartii
 
Data Models.pptx
CheriviralaNikhil
 
18306_lec-2 (1).ppt
IshuIswarya3
 
Data Models and Relational Database Design.pptx
niqqaanonymous211
 
database_design_presentation, data base design presenttion
ahtms257
 
Er diagrams presentation
Akanksha Jaiswal
 
Er diagrams presentation
Akanksha Jaiswal
 
erdiagramspresentation-150826044953-lva1-app6891.pdf
vinayakjadhav94
 
DBMS_Data Model,Keys,Attributes,Relationship.pptx
DrThenmozhiKarunanit
 
Data modeling using the entity relationship model
Jafar Nesargi
 
Db lec 02_new
Ramadan Babers, PhD
 
Unit 2 DBMS
DhivyaSubramaniyam
 
Introduction of Database Design and Development
Er. Nawaraj Bhandari
 
database1
Monika Sharma
 
DBMS Unit-2_Final.pptx
parimala123
 

More from sanketkashyap6 (7)

PPT
3.Analysis of insertion and bubble sort.ppt
sanketkashyap6
 
PPTX
1.Registers.pptx tjrktjgktjghththyjytjytjyy
sanketkashyap6
 
PPTX
ALU.pptx kjvjjfjrshfjshfjrhfjershfherjghre
sanketkashyap6
 
PPTX
Time Management.pptx for the ltra gigfasxcvghdasd
sanketkashyap6
 
PPT
Basic Commands.ppt for the laborartory chad
sanketkashyap6
 
PPT
Unit-1-Introduction.ppt for the gigachad
sanketkashyap6
 
PPTX
UNDERSTANDING DIVERSITY.pptxhvghbhjdhsjdhsudhn
sanketkashyap6
 
3.Analysis of insertion and bubble sort.ppt
sanketkashyap6
 
1.Registers.pptx tjrktjgktjghththyjytjytjyy
sanketkashyap6
 
ALU.pptx kjvjjfjrshfjshfjrhfjershfherjghre
sanketkashyap6
 
Time Management.pptx for the ltra gigfasxcvghdasd
sanketkashyap6
 
Basic Commands.ppt for the laborartory chad
sanketkashyap6
 
Unit-1-Introduction.ppt for the gigachad
sanketkashyap6
 
UNDERSTANDING DIVERSITY.pptxhvghbhjdhsjdhsudhn
sanketkashyap6
 
Ad

Recently uploaded (20)

PDF
apidays Helsinki & North 2025 - API-Powered Journeys: Mobility in an API-Driv...
apidays
 
PPTX
apidays Munich 2025 - Building Telco-Aware Apps with Open Gateway APIs, Subhr...
apidays
 
PDF
Context Engineering for AI Agents, approaches, memories.pdf
Tamanna
 
PPTX
Resmed Rady Landis May 4th - analytics.pptx
Adrian Limanto
 
PDF
What does good look like - CRAP Brighton 8 July 2025
Jan Kierzyk
 
PDF
List of all the AI prompt cheat codes.pdf
Avijit Kumar Roy
 
PPTX
Human-Action-Recognition-Understanding-Behavior.pptx
nreddyjanga
 
PDF
Early_Diabetes_Detection_using_Machine_L.pdf
maria879693
 
PPTX
AI Presentation Tool Pitch Deck Presentation.pptx
ShyamPanthavoor1
 
PPT
Data base management system Transactions.ppt
gandhamcharan2006
 
PDF
Data Chunking Strategies for RAG in 2025.pdf
Tamanna
 
PPTX
Exploring Multilingual Embeddings for Italian Semantic Search: A Pretrained a...
Sease
 
PDF
OPPOTUS - Malaysias on Malaysia 1Q2025.pdf
Oppotus
 
PPTX
Introduction to Artificial Intelligence.pptx
StarToon1
 
PPT
deep dive data management sharepoint apps.ppt
novaprofk
 
PPTX
The _Operations_on_Functions_Addition subtruction Multiplication and Division...
mdregaspi24
 
PDF
Web Scraping with Google Gemini 2.0 .pdf
Tamanna
 
PPTX
Module-5-Measures-of-Central-Tendency-Grouped-Data-1.pptx
lacsonjhoma0407
 
PPTX
recruitment Presentation.pptxhdhshhshshhehh
devraj40467
 
PDF
How to Avoid 7 Costly Mainframe Migration Mistakes
JP Infra Pvt Ltd
 
apidays Helsinki & North 2025 - API-Powered Journeys: Mobility in an API-Driv...
apidays
 
apidays Munich 2025 - Building Telco-Aware Apps with Open Gateway APIs, Subhr...
apidays
 
Context Engineering for AI Agents, approaches, memories.pdf
Tamanna
 
Resmed Rady Landis May 4th - analytics.pptx
Adrian Limanto
 
What does good look like - CRAP Brighton 8 July 2025
Jan Kierzyk
 
List of all the AI prompt cheat codes.pdf
Avijit Kumar Roy
 
Human-Action-Recognition-Understanding-Behavior.pptx
nreddyjanga
 
Early_Diabetes_Detection_using_Machine_L.pdf
maria879693
 
AI Presentation Tool Pitch Deck Presentation.pptx
ShyamPanthavoor1
 
Data base management system Transactions.ppt
gandhamcharan2006
 
Data Chunking Strategies for RAG in 2025.pdf
Tamanna
 
Exploring Multilingual Embeddings for Italian Semantic Search: A Pretrained a...
Sease
 
OPPOTUS - Malaysias on Malaysia 1Q2025.pdf
Oppotus
 
Introduction to Artificial Intelligence.pptx
StarToon1
 
deep dive data management sharepoint apps.ppt
novaprofk
 
The _Operations_on_Functions_Addition subtruction Multiplication and Division...
mdregaspi24
 
Web Scraping with Google Gemini 2.0 .pdf
Tamanna
 
Module-5-Measures-of-Central-Tendency-Grouped-Data-1.pptx
lacsonjhoma0407
 
recruitment Presentation.pptxhdhshhshshhehh
devraj40467
 
How to Avoid 7 Costly Mainframe Migration Mistakes
JP Infra Pvt Ltd
 
Ad

Unit 2 new.pptx for the actual dbms chad

  • 1. Unit 2  Overview of Database Design Process  Example Database Application (COMPANY)  ER Model Concepts  Entities and Attributes  Entity Types, Value Sets, and Key Attributes  Relationships and Relationship Types  Weak Entity Types  Roles and Attributes in Relationship Types  ER Diagrams - Notation  ER Diagram for COMPANY Schema
  • 2. Overview of Database Design Process  Two main activities:  Database design  Applications design  Focus of this topic is on database design  To design the conceptual schema for a database application  Applications design focuses on the programs and interfaces that access the database  Generally considered part of software engineering
  • 3. Overview of Database Design Process
  • 4. Entities and Attributes Entity – A thing in the real world object with an independent existence. An entity may be an object with a physical existence (car, person ,house) or it may be an object with a conceptual existence( a company, a university) Each entity has attributes – the particular properties that describe it.
  • 5.  Composite versus simple attributes.  Composite attributes can be divided in to smaller subparts  Simple attributes that are not divided are called simple or atomic attributes.
  • 6.  Single valued vs Multivalued attributes  Most attributes have a single value for a particular entity.  Eg. Age is a single valued attribute of a person.  Some attributes may have more than one value for a particular entity  Eg. Differrent people can have different numbers of values for the College degrees atrributes
  • 7.  Stored vs Derived Attributes  Complex attributes  In general, composite and multi-valued attributes may be nested arbitrarily to any number of levels although this is rare. For example, PreviousDegrees of a STUDENT is a composite multi-valued attribute denoted by {PreviousDegrees (College, Year, Degree, Field)}.  {AddressPhone( { Phone(AreaCode,PhoneNumber)}, Address(streetAddress (number,street,apartmentNumber),city,state,zip) ) }
  • 8. Entity Types, Entity sets  A database usually contains groups of entities that are similar.  An entity type defines a collection (or set) of entities that have the same attributes.  Each entity type in the database is described by its name and attributes.  The collection of all entities of a particular entity type in the database at any point in time is called an entity set.
  • 10. Key attributes of an entity type  An entity type usually has one or more attributes whose values are distinct for each individual entity in the entity set. Such an attribute is called a key attribute
  • 11. Relationships and Relationship Types  A relationship relates two or more distinct entities with a specific meaning.  For example, EMPLOYEE John Smith works on the ProductX PROJECT, or EMPLOYEE Franklin Wong manages the Research DEPARTMENT.  Relationships of the same type are grouped or typed into a relationship type.  For example, the WORKS_ON relationship type in which EMPLOYEEs and PROJECTs participate, or the MANAGES relationship type in which EMPLOYEEs and DEPARTMENTs participate.  The degree of a relationship type is the number of participating entity types.  Both MANAGES and WORKS_ON are binary relationships.
  • 12. Example relationship instances of the WORKS_FOR relationship between EMPLOYEE and DEPARTMENT e1  e2  e3  e4  e5  e6  e7  EMPLOYEE r1 r2 r3 r4 r5 r6 r7 WORKS_FOR  d1  d2  d3 DEPARTMENT
  • 13. Relationship Degree, Role Names  The degree of a relationship type is the number of participating entity types.  Binary  Ternary  Quandary
  • 14.  Role name  Recursive relationships
  • 15. Constraints on binary relationship types  1:1  1:N  M:N
  • 17.
  • 18.  Participation constraints  It specifies whether the existence of an entity depends on its being related to another entity via the relationship type.  Total participation  Partial participation
  • 19.  Strong Entity types  Weak Entity types  Partial key A Weak entity type normally has a partial key which is the attribute that can uniquely identify weak entities that are related to the same owner entity.
  • 20. ER Schema diagram of company DB
  • 21. ER-DIAGRAM - NOTATION FOR ER SCHEMAS Meaning ENTITY TYPE WEAK ENTITY TYPE RELATIONSHIP TYPE IDENTIFYING RELATIONSHIP TYPE ATTRIBUTE KEY ATTRIBUTE MULTIVALUED ATTRIBUTE COMPOSITE ATTRIBUTE DERIVED ATTRIBUTE TOTAL PARTICIPATION OF E2 IN R CARDINALITY RATIO 1:N FOR E1:E2 IN R STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION OF E IN R Symbol E1 R E2 E1 R E2 R (min,max) E N
  • 22.  ER model has three main concepts:  Entities (and their entity types and entity sets)  Attributes (simple, composite, multivalued)  Relationships (and their relationship types and relationship sets)
  • 23. ER Diagrams  A company database needs to store information about employees (identified by ssn, with salary and phone as attributes), departments (identified by dno, with dname and budget as attributes), and children of employees (with name and age as attributes). Employees work in departments; each department is managed by an employee; a child must be identified uniquely by name when the parent (who is an employee; assume that only one parent works for the company) is known. We are not interested in information about a child once the parent leaves the company. 1 1 1 N 1 N
  • 24. Notown Records has decided to store information about musicians who perform on its albums • Each musician that records at Notown has an SSN, a name, an address, and a phone number.  Each instrument used in songs recorded at Notown has a unique identification number, a name (e.g., guitar, synthesizer, flute) and a musical key (e.g., C, B-flat, E-flat).  Each album recorded on the Notown label has a unique identification number, a title, a copyright date, a format (e.g., CD or MC), and an album identifier.  Each song recorded at Notown has a title and an author.  Each musician may play several instruments, and a given instrument may be played by several musicians.  Each album has a number of songs on it, but no song may appear on more than one album.  Each song is performed by one or more musicians, and a musician may perform a number of songs.  Each album has exactly one musician who acts as its producer. A musician may produce several albums, of course.
  • 26. ER-to-Relational Mapping Algorithm  ER-to-Relational Mapping Algorithm  Step 1: Mapping of Regular Entity Types  Step 2: Mapping of Weak Entity Types  Step 3: Mapping of Binary 1:1 Relation Types  Step 4: Mapping of Binary 1:N Relationship Types.  Step 5: Mapping of Binary M:N Relationship Types.  Step 6: Mapping of Multivalued attributes.  Step 7: Mapping of N-ary Relationship Types.
  • 29. Relational Model  Relational model represents the database as a collection of relations.
  • 30. What is Relation?  A Relation is thought of as a table of values (rows and columns)  each row, or tuple, is a collection of related data values  the degree of the relation is the number of attributes in the relation  each column represents an attribute  each row is an instance of the relation So, a relation is a table of facts.  Each column contains the same attribute data with the same data type  Each row describes a real-world instance of the relation  A Relational database contains one or more relations (or tables).
  • 31. In relational model terminology Informal Terms Formal Terms Table Relation Column Attribute Row Tuple Values in a column Domain Table Definition Schema of a Relation Populated Table Extension
  • 32. Formal Definition  A domain has a logical definition:  E.g., “Indian_phone_numbers” are the set of 10 digit phone numbers valid in INDIA.  A domain may have a data-type or a format defined for it.  E.g., Dates have various formats such as monthname, date, year or yyyy-mm-dd, or dd mm,yyyy etc.  An attribute designates the role played by the domain.  E.g., the domain Date may be used to define attributes “Invoice-date” and “Payment-date”.
  • 33.  A relation schema R denoted by R(A1, A2, …, An ) is made up of a relation name R and a list of attributes 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 denoted by dom (Ai )  A relation schema is used to describe a relation  R is called Relation.  The degree of a relation is the number of attributes n of its relation schema
  • 34.  Relation state r of the relation scheme R(A1, A2, …, An ) also denoted by r(R) is a set of n-tuples r = {t1,t2..tn}  Formally, Given R(A1, A2, .........., An) r(R)  dom (A1) X dom (A2) X ....X dom(An)  R: schema of the relation  r of R: a specific "value" or population of R.  R is also called the intension of a relation  r is also called the extension of a relation
  • 36. Characteristics of Relations  Ordering of tuples in a relation r(R): The tuples in a relation do not have any particular order. Even though they appear to be in the tabular form.  Ordering of values within a tuple. We will consider the attributes in R(A1, A2, ..., An) and a relation state r(R) is set of mappings r={t1,t2,….tm} the values in t=<v1, v2, ..., vn> to be ordered .  Values in a tuple: All values are considered atomic (indivisible). A special null value is used to represent values that are unknown or inapplicable to certain tuples.
  • 37. Relational Integrity Constraints  Constraints are conditions that must hold on all valid relation instances.  Constraints on databases can generally be divided into three categories:  Constraints that are inherent in the data model – model based constraints  Constraints that can be directly expressed in the schemas of the data model – schema based constraints  Constraints that cannot be directly expressed in the schemas of the data model –application based constraints
  • 38. Relational Integrity Constraints  There are three main types of constraints: 1. Key constraints 2. Entity integrity constraints 3. Referential integrity constraints Domain constraints and constraints on nulls.
  • 40. Entity Integrity  Relational Database Schema: A set S of relation schemas that belong to the same database. S is the name of the database. S = {R1, R2, ..., Rn}  Entity Integrity: The primary key attributes PK of each relation schema R in S cannot have null values in any tuple of r(R). This is because primary key values are used to identify the individual tuples. t[PK]  null for any tuple t in r(R)  Note: Other attributes of R may be similarly constrained to disallow null values, even though they are not members of the primary key.
  • 41. Referential Integrity  A constraint involving two relations (the previous constraints involve a single relation).  Used to specify a relationship among tuples in two relations: the referencing relation and the referenced relation.  Tuples in the referencing relation R1 have attributes FK (called foreign key attributes) that reference the primary key attributes PK of the referenced relation R2. A tuple t1 in R1 is said to reference a tuple t2 in R2 if t1[FK] = t2[PK].  A referential integrity constraint can be displayed in a relational database schema as a directed arc from R1.FK to R2. PK
  • 42. Referential Integrity Constraint Statement of the constraint The value in the foreign in key column (or columns) FK of the referencing relation R1 can be either: 1. a value of an existing primary key value of the corresponding primary key PK in the referenced relation R2,, or.. 2. a null. In case (2), the FK in R1 should not be a part of its own primary key.
  • 43. Other Types of Constraints Semantic Integrity Constraints: - constraints can be specified and enforced on a relational database. - E.g the salary of an employee should not exceed the salary of the employee’s supervisor Constraint specification language - Constraints can be specified and enforced within the application programs that update the database. - E.g., “the max. no. of hours per employee for all projects he or she works on is 56 hrs per week”
  • 44. Update Operations on Relations  INSERT a tuple.  DELETE a tuple.  MODIFY a tuple.  The Insert operation  Insert can violate any of the four types of constraints  Domain constraints  Key constraints  Entity integrity constraints  Referential integrity  The Delete operation  Delete operation can violate only referential integrity.  The update operation  Key and referential integrity
  • 47. Super key is a collection of attributes or set of attributes that uniquely identify the tuples. Why do we need super key? Super key is a superset from which we can derive other keys.
  • 52. Types of Keys  Primary Key The attribute or combination of attributes that uniquely identifies a row or record in a relation is known as primary key.  SuperKey: A key that can be uniquely used to identify a database record, that may contain extra attributes that are not necessary to uniquely identify records x
  • 53. Superkey is a set of columns in a table for which there are no two rows that will share the same combination of values. So, the superkey is unique for each and every row in the table. A superkey can also be just a single column. Example of a superkey Suppose we have a table that holds all the managers in a company, and that table is called Managers. The table has columns called ManagerID, Name, Title, and DepartmentID. Every manager has his/her own ManagerID, so that value is always unique in each and every row. This means that if we combine the ManagerID column value for any given row with any other column value, then we will have a unique set of values. So, for the combinations of (ManagerID, Name), (ManagerID, TItle), (ManagerID, DepartmentID), (ManagerID, Name, DepartmentID), etc – there will be no two rows in the table that share the exact same combination of values, because the ManagerID will always be unique and different for each row. This means that pairing the Manager ID with any other column(s) will ensure that the combination will also be unique across all rows in the table. superkey – it’s any combination of column(s) for which that combination of values will be unique across all rows in a table. So, all of those combinations of columns in the Manager table that would be considered to be superkeys. Even the ManagerID column is considered to be a superkey
  • 54. Key Constraints  Superkey of R: A set of attributes SK of R such that no two tuples in any valid relation instance r(R) will have the same value for SK. That is, for any distinct tuples t1 and t2 in r(R), t1[SK]  t2[SK].  Minimal superkey of R: A superkey from which we cannot remove any attributes and still have the uniqueness constraint in any two distinct tuples in any state of the relation cannot have identical values for the attributes in the key. Example: The CAR relation schema: CAR(State, Reg#, SerialNo, Make, Model, Year) has two keys Key1 = {State, Reg#}, Key2 = {SerialNo}, which are also superkeys. {SerialNo, Make} is a superkey but not a candidate key.  If a relation has several candidate keys, one is chosen arbitrarily to be the primary key. The primary key attributes are underlined.