SlideShare a Scribd company logo
1 of 59
Data Modeling
(Part – 1)
Presented by:
Mr. S. Christalin Nelson
2/20/2024 Christalin Nelson | Systems Cluster | SOCS 2
At a Glance
• Terminologies & Constraints
• Using High-Level Conceptual Data Models for Database Design
• Sample Database Application
• Entity Types, Entity Sets, Attributes, Keys, and Value Sets
• Relationship Types, Relationship Sets, Roles, and Structural Constraints
• Weak Entity Types
• Refining ER Design for COMPANY Database
• ER Diagrams, Naming Conventions, and Design Issues
• Relationship Types of Degrees Higher than Two
3
2/20/2024
Christalin Nelson | Systems Cluster | SOCS
3 of 59
2/20/2024
Few Terminologies (1/2)
• Domain
– Consists of Name, Data type, Format
– Set of atomic values
• Several Attributes can have the same domain
– Example: Domain named "Phone number" can have attributes home_phone,
office_phone, mob_phone
• Relation – Table name
• Relation Schema (or) Relation Intension
– Includes Table Name, List of Attributes
• Relation State (or) Relation Extension
• Relation instance – Single row (or) tuple
Christalin Nelson | Systems Cluster | SOCS
4 of 59
2/20/2024
Few Terminologies (2/2)
• Degree or Arity – No. of Attributes
• Tuples are considered as facts about a relation (or) values satisfying the predicate
• Relations represent
– Facts about entities
– Facts about relationships
• Tuple Ordering
• Attribute Ordering
• Basic Relational model
– Composite and Multivalued attributes are not allowed
– Also called a flat relational model
Christalin Nelson | Systems Cluster | SOCS
5 of 59
2/20/2024
Types of Constraints (1/6)
• Inherent model based constraints or Implicit constraints
– Example:
• A relation cannot have duplicate tuples
• Schema-based constraints or Explicit constraints
– Example:
• Domain constraints
• Constraints on NULLs
• Key constraints
• Entity Integrity constraints
• Referential integrity constraints
Christalin Nelson | Systems Cluster | SOCS
6 of 59
2/20/2024
Types of Constraints (2/6)
• Application-based or semantic constraints or business rules
– Specified and enforced on a relational database or by using general-purpose constraint
specification language
– Example
• The salary of an employee should not exceed salary of employee’s supervisor at DB update
– Mechanisms: Triggers, Assertions
• Data Dependencies
– Example:
• Functional and Multivalued dependencies
– Used with Normalization
Christalin Nelson | Systems Cluster | SOCS
7 of 59
2/20/2024
Types of Constraints (3/6)
• State constraints (or) Static constraints
– Constraints discussed so far
– Define the constraints that a valid state of DB must satisfy
• Transition constraints (or) Dynamic constraints
– Enforced by application programs or specified using active rules and triggers
– Example:
• Salary of an employee can only increase
Christalin Nelson | Systems Cluster | SOCS
8 of 59
2/20/2024
Types of Constraints (4/6)
• Domain Constraint
– The value of each attribute must be an atomic value
• Meanings for NULL values
– (1) Not Applicable
• E.g. Person with no college degree would have “null” for “College_degrees” attribute
– (2) Unknown value – Value exists but is missing or unavailable
• E.g. Height attribute of a person
– (3) Unknown value – Does not know if value exists
• E.g Home_phone attribute of a person
Christalin Nelson | Systems Cluster | SOCS
9 of 59
2/20/2024
Types of Constraints (5/6)
• Key constraints
– Specified on individual relations
– Every table has at least one “Superkey” (subset of attributes)
– “Superkey” can have redundant attributes
– “Key” cannot have redundant attributes
– Any “Superkey” formed from a single attribute is also a “Key”
– Rules
• (1) “Superkey” & “Key” for each tuple should be distinct => “Unique” constraint
• (2) “Key” is a “minimal superkey”
– i.e. Removal of an attribute will compromise “Unique” constraint
– A relation schema may have more than one “key” => termed as “Candidate key”
• One candidate is identified as “Primary key”
Christalin Nelson | Systems Cluster | SOCS
10 of 59
2/20/2024
Types of Constraints (6/6)
• Entity Integrity constraint
– Specified on individual relations
– No “Primary key” value can be NULL
• Referential integrity constraints
– Specified between two relations
– “Foreign key” in a dependent relation
– Rules
• (1) Attributes of FK should have the same domain as of PK
• (2) Value of FK = value of PK (or) null
– FK can refer to another tuple in its own relation
Christalin Nelson | Systems Cluster | SOCS
11 of 59
2/20/2024
Data Modeling using ER Model
• Data Application
– Database, Application program that implements DB Queries and updates
– DB design + Software Engineering (Design, Implementation, Testing of Appln.)
• Entity-Relationship (ER) model
– Popular high-level conceptual data model
– ER diagrams
• Diagrammatic notation associated with the ER model
• Enhanced-ER (EER) model
– Includes concepts such as specialization, generalization, inheritance, and union types
(categories)
• Unified Modeling Language (UML)
– Object modeling
Christalin Nelson | Systems Cluster | SOCS
12 of 59
2/20/2024
Using High-Level Conceptual Data Models (1/4)
• Requirements collection and analysis
– DB designers interview prospective DB users to understand and document data
requirements & functional requirements
• Result-1: Concise set of users’ requirements specified in a detailed and complete form
• Result-2: User-defined operations/transactions applied to the DB
– Note:
• Techniques used to specify functional requirements in Software design include DFD,
Sequence diagrams, scenarios
• Functional Analysis
– Identify high-level user queries and operations
Christalin Nelson | Systems Cluster | SOCS
13 of 59
Main phases of database design
2/20/2024
Christalin Nelson | Systems Cluster | SOCS
14 of 46
14 of 59
2/20/2024
Using High-Level Conceptual Data Models (3/4)
• Conceptual design
– Includes
• Concise description of Data requirements
• Detailed descriptions of entity types, relationships, and constraints
• Use the basic data model operations to specify high-level user queries and operations
• Note: Does not include implementation details
– Result: Conceptual schema of high-level data model
– Used to communicate with non-technical users
– Used as a reference to ensure that all users’ data requirements are met and do not
conflict
Christalin Nelson | Systems Cluster | SOCS
15 of 59
2/20/2024
Using High-Level Conceptual Data Models (4/4)
• Logical design (or) data model mapping
– Transform Conceptual schema from High-level data model into Implementation data
model
• Actual implementation of DB using a commercial DBMS with an implementation data
model (like Relational or Object-relational DB model)
– Result: DB schema (Conceptual/Logical Schema in the data model of a specific DBMS)
– Often automated or semi-automated within the DB design tools
• Physical design phase
– Internal storage structures, file organizations, indexes, access paths, and physical
design parameters for the database files are specified
Result: Internal schema
• Application program development
Christalin Nelson | Systems Cluster | SOCS
16 of 59
2/20/2024
Sample Database Application
• COMPANY Database – Description
– Employee
• Each employee has a name, social security number, address, salary, sex (gender), and birth date
• Each employee works for one department and can work on several projects that other
departments can control – Track the current no. of hours per week that an employee works on
each project
• Track the direct supervisor of each employee (who is another employee)
• A particular employee manages the department – Track the start date when an employee began
managing the department
– Department
• Each department has a unique name, a unique number and may have several locations
• Can control several projects
– Project
• Each project has a unique name, a unique number, and a single location
– Dependents
• Each dependent has a first name, sex (gender), birth date, and relationship to the employee.
• Track the dependents of each employee for insurance purposes
Christalin Nelson | Systems Cluster | SOCS
17 of 59
18
2/20/2024
Christalin Nelson | Systems Cluster | SOCS
18 of 59
2/20/2024
Entities and their Attributes (1/5)
• ER model describes data as Entities, Relationships, and Attributes
• Entities
– Things in the real world with independent existence
• Attributes
– Properties that describe an entity
– Types
• Composite vs. Simple (atomic) attributes
• Single-valued vs. Multi-valued attributes
• Stored vs. Derived attributes
• NULL values (Not Applicable & Unknown)
• Complex attributes
Christalin Nelson | Systems Cluster | SOCS
19 of 59
2/20/2024
Entities and their Attributes (2/5)
• Composite vs. Simple (atomic) attributes
– Attributes that are not divisible are called simple (or) atomic attributes
– Composite attributes are divided into smaller subparts (basic attributes)
• Useful to model situations in which a user sometimes refers to composite attribute as a
unit but at other times refers specifically to its components
• Value of composite attribute = Concatenation of values of its component simple attributes
– Components of a composite attribute are given within parentheses () & separated with commas
» Example: Address (Street_address(Number, Street, Apartment_number), City, State, Zip)
• Can form a hierarchy (Pic)
Christalin Nelson | Systems Cluster | SOCS
20 of 59
2/20/2024
Entities and their Attributes (3/5)
• Single-valued vs. Multi-valued attributes
– Singled-valued attributes have a single value for a particular entity
• Example: “Age” is a single-valued attribute of a person
– Multi-valued attributes have a set of values for the same entity
• May have lower & upper bounds to constrain the number of values allowed for each entity
• Multivalued attributes are mentioned using braces {}
– Example: “color” attribute for a car is {blue, red}
Christalin Nelson | Systems Cluster | SOCS
21 of 59
2/20/2024
Entities and their Attributes (4/5)
• Stored vs. Derived attributes
– Values of Stored attributes are given by the user and stored
– Values of Derived attributes should be derived
• Derived from the related attributes of an entity
– Example: “Age” and “Birth_date” attributes of a person
» Age attribute (Derived attribute), Birth_date attribute (Stored attribute)
• Derived from related entities
– Example: Attribute “Number_of_employees” of a DEPARTMENT entity can be derived by
counting the number of employees working for that department
Christalin Nelson | Systems Cluster | SOCS
22 of 59
2/20/2024
Entities and their Attributes (5/5)
• Complex attributes
– Composite and multivalued attributes can be nested arbitrarily
– Example: Attribute “Address_phone” of a person who can have >1 residence, and each
residence can have a single address and multiple phones
{
Address_phone (
{Phone(Area_code, Phone_number)},
Address(Street_address(Number, Street, Apartment_number), City, State, Zip)
)
}
Note: Here “Address” and “Phone” are composite attributes
Christalin Nelson | Systems Cluster | SOCS
23 of 59
2/20/2024
Entity Types, Entity Sets, Keys, and Value Sets (1/4)
• Entity type
– Collection (or set) of entities that have the same attributes
– Describes Schema (Intension) for the set of entities
Christalin Nelson | Systems Cluster | SOCS
24 of 59
2/20/2024
Entity Types, Entity Sets, Keys, and Value Sets (2/4)
• Key attribute
– Table has one/more attributes whose values are distinct for each entity in entity set
• Some entity types have >1 key attribute
• Composite Key Attribute: Combination of attribute values must be distinct for each entity
– Satisfies the key or uniqueness constraint
– Note:
• There is no concept of a primary key in the ER model
• The primary key will be chosen during mapping to a relational schema (Relational Model)
• Weak Entity Type
– An entity type without even one key attribute
Christalin Nelson | Systems Cluster | SOCS
25 of 59
Entity type
Rectangular box enclosing
the entity type name
Attribute names
Enclosed in ovals & are
attached to their entity
type by straight lines
Composite attributes
Attached to their
component attributes by
straight lines
Multivalued attributes
Displayed in double ovals
Key attribute
Its name underlined inside
the oval
2/20/2024
Christalin Nelson | Systems Cluster | SOCS
26 of 59
2/20/2024
Entity Types, Entity Sets, Keys, and Value Sets (4/4)
• Value sets (or domain of values) of Attributes
– Set of values that may be assigned to that attribute for each entity
– Note:
• Value sets are not displayed in ER diagrams
• Specified using the basic data types available in most programming languages
– An attribute (A) of entity set (E) whose value set is V can be defined as a function from E to the
power set P(V) of V
• A : E → P(V)
– Value of attribute(A) for entity (e) is A(e)
• NULL value is represented by empty set
• For single-valued attributes, A(e) is restricted to a singleton set for each entity(e) in E
• There is no restriction on multivalued attributes
• For a composite attribute (A), the value set V is the power set of the Cartesian product of P(V1),
P(V2), ..., P(Vn), where V1, V2, ..., Vn are the value sets of the simple component attributes that
form A:
– V = P (P(V1) × P(V2) × ... × P(Vn))
Christalin Nelson | Systems Cluster | SOCS
27 of 59
2/20/2024
Sample Database Application
• COMPANY Database – Description
– Employee
• Each employee has a name, social security number, address, salary, sex (gender), and birth date
• Each employee works for one department and can work on several projects that other
departments can control – Track the current no. of hours per week that an employee works on
each project
• Track the direct supervisor of each employee (who is another employee)
• A particular employee manages the department – Track the start date when an employee began
managing the department
– Department
• Each department has a unique name, a unique number and may have several locations
• Can control several projects
– Project
• Each project has a unique name, a unique number, and a single location
– Dependents
• Each dependent has a first name, sex (gender), birth date, and relationship to the employee.
• Track the dependents of each employee for insurance purposes
Christalin Nelson | Systems Cluster | SOCS
28 of 59
2/20/2024
Initial Conceptual Design of COMPANY Database
Christalin Nelson | Systems Cluster | SOCS
29 of 59
2/20/2024
Relationship Types, Relationship Sets (1/3)
• Relationship
– An attribute of one entity type refers to another entity type – represent references as
relationships, and not as attributes
• Relationship Types
– As with Entity types & Entity sets, a Relationship type and its corresponding
Relationship set are referred to by the same name, R
• A relationship type(R) among ‘n’ entity types E1, E2, ..., En defines a set of associations (or) a
relationship set among entities from these entity types
• Each relationship instance (ri) in R is an association of entities, where the association
includes exactly one entity from each participating entity type
– Each of the entity types E1, E 2, ..., En is said to participate in the relationship type R; similarly,
each of the individual entities e1, e2, ..., en is said to participate in the relationship instance ri =
(e1, e2, ..., en).
Christalin Nelson | Systems Cluster | SOCS
30 of 59
2/20/2024
Relationship Types, Relationship Sets (2/3)
• Example:
– Consider a relationship type WORKS_FOR between two entity types EMPLOYEE and
DEPARTMENT, which associates each employee with the department for which the
employee works in the corresponding entity set
• Each relationship instance in the relationship set WORKS_FOR associates one EMPLOYEE
entity and one DEPARTMENT entity
Christalin Nelson | Systems Cluster | SOCS
31 of 59
2/20/2024
Christalin Nelson | Systems Cluster | SOCS
32 of 59
2/20/2024
Relationship Degree
• Degree of a relationship type
– Number of participating
entity types
– Examples
• WORKS_FOR relationship is
of degree two (Binary)
• SUPPLY relationship is of
degree three (Ternary)
Christalin Nelson | Systems Cluster | SOCS
33 of 59
2/20/2024
Relationship as Attributes
• Binary relationship type can be thought of in terms of attributes
– Consider WORKS_FOR relationship type
• The attribute called ‘Department’ of EMPLOYEE entity type, where the value of
‘Department’ for each EMPLOYEE entity is a reference to the DEPARTMENT entity for which
that employee works.
– The concept of representing relationship types as attributes is used in a class of data
models called functional data models
• In object DBs, relationships can be represented by reference attributes, either in one
direction or in both directions as inverses
• In relational DBs, “foreign keys” are a type of reference attribute used to represent
relationships
Christalin Nelson | Systems Cluster | SOCS
34 of 59
2/20/2024
Role Names and Recursive Relationships (1/2)
• Role names
– Role name signifies role that a participating entity plays in each relationship instance
– Example:
• In WORKS_FOR relationship type, EMPLOYEE plays the role of employee/worker and
DEPARTMENT plays the role of department/employer
• Recursive relationships
– The same entity type participates in >1 relationship types in different roles
– The role name should be specified
– Example:
• SUPERVISION relationship type relates an employee to a supervisor, where both employee
and supervisor entities are members of the same EMPLOYEE entity set. Here EMPLOYEE
entity type participates twice in SUPERVISION in the role of supervisor & role of supervisee
Christalin Nelson | Systems Cluster | SOCS
35 of 59
36
2/20/2024
Christalin Nelson | Systems Cluster | SOCS
36 of 59
2/20/2024
Binary Relationship Constraints (1/5)
• The constraints limit the possible combinations of entities that may participate in
the corresponding relationship set
• Types
– Cardinality ratio
– Participation constraint
• Cardinality ratio
– Specifies the maximum no. of relationship instances that the entity can participate in
– Possible cardinality ratios for binary relationship types are 1:1, 1:N, N:1, and M:N
– Example: WORKS_FOR binary relationship type, DEPARTMENT:EMPLOYEE is of
cardinality ratio 1:N
• Each department can be related to (employs) any number of employees, but an employee
can be related to (work for) only one department
Christalin Nelson | Systems Cluster | SOCS
37 of 59
2/20/2024
Christalin Nelson | Systems Cluster | SOCS
38 of 59
2/20/2024
Christalin Nelson | Systems Cluster | SOCS
39 of 59
2/20/2024
Binary Relationship Constraints (4/5)
• Participation constraint
– Specifies whether the existence of an entity depends on it being related to another
entity via relationship type
– Specifies the minimum no. of relationship instances that each entity can participate in
(sometimes called minimum cardinality constraint)
– Types: Total & Partial
• Examples:
– A company policy states that “every employee must work for a department”. An employee entity
can exist only if it participates in at least one WORKS_FOR relationship instance. This is called
Total Participation (or) Existence Dependency.
– Every employee is not expected to manage a department. The participation of EMPLOYEE in the
MANAGES relationship type is Partial Participation.
Christalin Nelson | Systems Cluster | SOCS
40 of 59
2/20/2024
Binary Relationship Constraints (5/5)
• Structural Constraints
– Cardinality ratio and Participation Constraints are together considered as structural
constraints of a relationship type
• ER Notation
– Cardinality ratios: Display 1, M, and N on the diamonds
– Total participation: Double line connecting participating entity type to the relationship
– Partial participation: Single line
• Note:
– Either specify no minimum (partial participation) or a minimum of one (total participation)
– Specify a specific minimum number on participation in the relationship, such as 4 or 5
Christalin Nelson | Systems Cluster | SOCS
41 of 59
2/20/2024
Attributes of Relationship Types (1/2)
• Relationship types can also have attributes, similar to those of entity types.
– Example
• ‘Hours’ attribute for the WORK_ON relationship type to track the number of hours per
week that an employee works on a particular project
• ‘Start_date’ attribute for the MANAGES relationship type to track the date on which a
manager started managing a department via an attribute
Christalin Nelson | Systems Cluster | SOCS
42 of 59
2/20/2024
Attributes of Relationship Types (2/2)
• Migration of Attribute of Relation Type => Attribute of Entity Type
– Attributes of 1:1 relationship types => can be migrated to any one entity type
• Example: ‘Start_date’ attribute for MANAGES relationship can be an attribute of either
EMPLOYEE or DEPARTMENT, although conceptually it belongs to MANAGES
– Attributes of 1:N relationship types => can be migrated only to entity type on the N-
side of the relationship
• Example: If WORKS_FOR relationship has an attribute ‘Start_date’ that indicates when an
employee started working for a department, this attribute can be included as an attribute
of EMPLOYEE
– For M:N relationship types => No Migration
• Example: The value of ‘Hours’ attribute of the M:N relationship WORKS_ON is determined
by an employee-project combination and not separately by either entity
Christalin Nelson | Systems Cluster | SOCS
43 of 59
2/20/2024
Weak Entity Type (1/4)
• Entity Type that do not have key attributes of their own
– vs. Strong Entity Type
• Identifying relationship
– Relates weak entity type (Child or subordinate entity type) to Owner (Parent or
Dominant) entity type
• Entities of a weak entity type are identified by being related to specific entities from owner
– Always has a total participation constraint or existence dependency
• Note: Not every existence dependency results in a weak entity type
– Example: DRIVER_LICENSE entity cannot exist unless it is related to a PERSON entity, even
though it has its own key (License_number). Hence is not a weak entity.
Christalin Nelson | Systems Cluster | SOCS
44 of 59
2/20/2024
Weak Entity Type (2/4)
• Example
– Entity type DEPENDENT is related to EMPLOYEE via a 1:N relationship. Each employee
entity is said to OWN the dependent entities that are related to it.
• Note: Two dependents of two distinct employees may, by chance, have the same values for
Name, Birth_date, Sex, and Relationship, but they are still distinct entities. They are
identified as distinct entities ONLY after determining the employee entity to which each
dependent is related.
• Partial key or Discriminator
– Attribute that uniquely identifies weak entities that are related to same owner entity
– Example: The attribute ‘Name’ of DEPENDENT is the partial key
Christalin Nelson | Systems Cluster | SOCS
45 of 59
2/20/2024
Weak Entity Type (3/4)
• Notation used in ER diagrams
– Weak entity type and it’s identifying relationship: Surround their boxes and diamonds
with double lines
– Partial key attribute: underlined with a dashed or dotted line
• Weak entity types can also be represented as complex (composite, multivalued)
attributes
– Example: Specify a multivalued attribute ‘Dependents’ for EMPLOYEE, which is a
composite attribute with component attributes Name, Birth_date, Sex, and
Relationship
Christalin Nelson | Systems Cluster | SOCS
46 of 59
2/20/2024
Weak Entity Type (4/4)
• Any number of levels of weak entity types can be defined
– i.e. An owner entity type may itself be a weak entity type
• A weak entity type may have >1 identifying entity type
• A weak entity type may have an identifying relationship type of degree >2
Christalin Nelson | Systems Cluster | SOCS
47 of 59
2/20/2024
Refining ER Design for COMPANY Database
• Change attributes that represent relationships into relationship types
• Determine cardinality ratio and participation constraint of each relationship type
Christalin Nelson | Systems Cluster | SOCS
Relation Type Relation between
Cardinality
Ratio
Participation Constraint Attribute
WORKS_FOR DEPARTMENT and EMPLOYEE 1:N
EMPLOYEE total
participation
DEPARTMENT total
participation
Nil
MANAGES EMPLOYEE and DEPARTMENT 1:1
EMPLOYEE partial
participation
DEPARTMENT total
participation
Start_date
CONTROLS DEPARTMENT and PROJECT 1:N
DEPARTMENT partial
partcipation
PROJECT total
participation
Nil
SUPERVISION
EMPLOYEE (supervisor role) and
EMPLOYEE (supervisee role)
1:N
EMPLOYEE (supervisor
role) partial participation
EMPLOYEE (supervisee
role) partial
participation
Nil
WORKS_ON EMPLOYEE and PROJECT M:N
EMPLOYEE total
participation
PROJECT total
participation
Hours
DEPENDENTS_OF EMPLOYEE and DEPENDENT 1:N
EMPLOYEE partial
participation
DEPENDENT total
participation
Nil
48 of 59
2/20/2024
Proper naming of Schema Constructs
• Choose names that convey meanings attached to different constructs in the
schema
• Entity types: Singular names rather than plural ones
• Entity type names: Nouns, uppercase letters
• Attribute names: Nouns, Initial letter is capitalized
• Role names: lowercase letters
• Relationship type names: Verbs, uppercase letters
– Choose binary relationship names to make the ER diagram readable from left to right
and from top to bottom
• This issue arises because each binary relationship can be described starting from either of
the two participating entity types
Christalin Nelson | Systems Cluster | SOCS
49 of 59
2/20/2024
Christalin Nelson | Systems Cluster | SOCS
Identifying
50 of 59
2/20/2024
Alternative Notations for ER Diagrams (1/2)
• Specify structural constraints on relationships
– Replace cardinality ratio and participation constraints. Associate a pair of integer
numbers (min, max) with each participation of an entity type E in a relationship type
R, where 0 ≤ min ≤ max and max ≥ 1
– Note: For Participation constraints
• Partial participation (min = 0)
• Total participation (min > 0)
Christalin Nelson | Systems Cluster | SOCS
51 of 59
52
2/20/2024
Christalin Nelson | Systems Cluster | SOCS
52 of 59
2/20/2024
Choosing between Binary & Higher-Degree Relationships (1/5)
• A relationship type(R) of degree(n) will have n edges in an ER diagram, one
connecting R to each participating entity type
Christalin Nelson | Systems Cluster | SOCS
53 of 59
2/20/2024
Choosing between Binary & Higher-Degree Relationships (2/5)
• Three binary relationships cannot replace a ternary relationship, they may do so
under certain additional constraints
– Example: Existence of three relationship instances (s, p), ( j, p), and (s, j) in
CAN_SUPPLY, USES, and SUPPLIES, respectively, does not necessarily imply that an
instance (s, j, p) exists in ternary relationship SUPPLY
Christalin Nelson | Systems Cluster | SOCS
54 of 59
2/20/2024
Choosing between Binary & Higher-Degree Relationships (3/5)
• Some database design tools permit only binary relationships
– Ternary relationships are represented as weak entity types with no partial key and
with three identifying relationships
• Example: The weak entity type SUPPLY is identified by a combination of its three owner
entities from SUPPLIER, PART, and PROJECT
Christalin Nelson | Systems Cluster | SOCS
55 of 59
2/20/2024
Choosing between Binary & Higher-Degree Relationships (4/5)
• A weak entity type with a ternary (or n-ary) identifying relationship type
– The weak entity type can have a partial key and several owner entity types
Christalin Nelson | Systems Cluster | SOCS
56 of 59
2/20/2024
Choosing between Binary & Higher-Degree Relationships (5/5)
• Represent ternary relationship as a regular entity type by introducing an artificial
or surrogate key
– Example: Ternary relationship SUPPLY is converted to a regular entity type by using
artificial Key attribute Supply_id. Three binary N:1 relationships relate SUPPLY to the
three participating entity types.
Christalin Nelson | Systems Cluster | SOCS
57 of 59
2/20/2024
Constraints on Ternary (or Higher-Degree) Relationships
• Two Notations to be used for fully specifying structural constraints on higher-degree
relationships
– First notation is based on the cardinality ratio notation of binary relationships
• If among the three cardinalities, one participation has cardinality specified as 1, then the key
will be the combination of the other two participants
– Example: Relationship set of SUPPLY is a set of relationship instances (s, j, p), where s - SUPPLIER, j -
PROJECT, and p - PART. Suppose that the constraint exists that for a particular project-part
combination only one supplier will be used, then, any relationship instance (s, j, p) is uniquely
identified in relationship set by its (j, p) combination, which makes (j, p) a key for the relationship set
• If all three cardinalities are M or N, then the key will be the combination of all three participants
– Second notation is based on (min, max) notation for binary relationships
• This constraint have no bearing on determining the key of a higher-degree relationship
• Specifies a constraint that places restrictions on how many relationship instances each entity
can participate in
Christalin Nelson | Systems Cluster | SOCS
58 of 59
2/20/2024 Christalin Nelson | Systems Cluster | SOCS 59

More Related Content

What's hot

INF3703 - Chapter 14 Distributed Databases
INF3703 - Chapter 14 Distributed DatabasesINF3703 - Chapter 14 Distributed Databases
INF3703 - Chapter 14 Distributed Databasesbloeyyy
 
Dimensional modeling in oracle sql developer
Dimensional modeling in oracle sql developerDimensional modeling in oracle sql developer
Dimensional modeling in oracle sql developerJeff Smith
 
Object Storage Overview
Object Storage OverviewObject Storage Overview
Object Storage OverviewCloudian
 
Practical Recipes for Daily DBA Activities using DB2 9 and 10 for z/OS
Practical Recipes for Daily DBA Activities using DB2 9 and 10 for z/OSPractical Recipes for Daily DBA Activities using DB2 9 and 10 for z/OS
Practical Recipes for Daily DBA Activities using DB2 9 and 10 for z/OSCuneyt Goksu
 
Understanding Data Partitioning and Replication in Apache Cassandra
Understanding Data Partitioning and Replication in Apache CassandraUnderstanding Data Partitioning and Replication in Apache Cassandra
Understanding Data Partitioning and Replication in Apache CassandraDataStax
 
Ms sql server architecture
Ms sql server architectureMs sql server architecture
Ms sql server architectureAjeet Singh
 
Z OS IBM Utilities
Z OS IBM UtilitiesZ OS IBM Utilities
Z OS IBM Utilitieskapa rohit
 
NoSQL databases - An introduction
NoSQL databases - An introductionNoSQL databases - An introduction
NoSQL databases - An introductionPooyan Mehrparvar
 
Taming the PDB: Resource Management and Lockdown Profiles
Taming the PDB: Resource Management and Lockdown ProfilesTaming the PDB: Resource Management and Lockdown Profiles
Taming the PDB: Resource Management and Lockdown ProfilesMarkus Flechtner
 

What's hot (20)

Database overview
Database overviewDatabase overview
Database overview
 
INF3703 - Chapter 14 Distributed Databases
INF3703 - Chapter 14 Distributed DatabasesINF3703 - Chapter 14 Distributed Databases
INF3703 - Chapter 14 Distributed Databases
 
Dimensional modeling in oracle sql developer
Dimensional modeling in oracle sql developerDimensional modeling in oracle sql developer
Dimensional modeling in oracle sql developer
 
Dbms slides
Dbms slidesDbms slides
Dbms slides
 
Programming in c++
Programming in c++Programming in c++
Programming in c++
 
DB2 on Mainframe
DB2 on MainframeDB2 on Mainframe
DB2 on Mainframe
 
DB2 utilities
DB2 utilitiesDB2 utilities
DB2 utilities
 
Oracle ASM Training
Oracle ASM TrainingOracle ASM Training
Oracle ASM Training
 
Object Storage Overview
Object Storage OverviewObject Storage Overview
Object Storage Overview
 
Practical Recipes for Daily DBA Activities using DB2 9 and 10 for z/OS
Practical Recipes for Daily DBA Activities using DB2 9 and 10 for z/OSPractical Recipes for Daily DBA Activities using DB2 9 and 10 for z/OS
Practical Recipes for Daily DBA Activities using DB2 9 and 10 for z/OS
 
SKILLWISE-DB2 DBA
SKILLWISE-DB2 DBASKILLWISE-DB2 DBA
SKILLWISE-DB2 DBA
 
Understanding Data Partitioning and Replication in Apache Cassandra
Understanding Data Partitioning and Replication in Apache CassandraUnderstanding Data Partitioning and Replication in Apache Cassandra
Understanding Data Partitioning and Replication in Apache Cassandra
 
Oracle RAC 12c Overview
Oracle RAC 12c OverviewOracle RAC 12c Overview
Oracle RAC 12c Overview
 
Ms sql server architecture
Ms sql server architectureMs sql server architecture
Ms sql server architecture
 
Z OS IBM Utilities
Z OS IBM UtilitiesZ OS IBM Utilities
Z OS IBM Utilities
 
Data models
Data modelsData models
Data models
 
NoSQL databases - An introduction
NoSQL databases - An introductionNoSQL databases - An introduction
NoSQL databases - An introduction
 
Get to know PostgreSQL!
Get to know PostgreSQL!Get to know PostgreSQL!
Get to know PostgreSQL!
 
Calculation order
Calculation orderCalculation order
Calculation order
 
Taming the PDB: Resource Management and Lockdown Profiles
Taming the PDB: Resource Management and Lockdown ProfilesTaming the PDB: Resource Management and Lockdown Profiles
Taming the PDB: Resource Management and Lockdown Profiles
 

Similar to Data Modeling - Entity Relationship Diagrams-1.pdf

Week 2 - Database System Development Lifecycle-old.pptx
Week 2 - Database System Development Lifecycle-old.pptxWeek 2 - Database System Development Lifecycle-old.pptx
Week 2 - Database System Development Lifecycle-old.pptxNurulIzrin
 
Unit 2_DBMS_10.2.22.pptx
Unit 2_DBMS_10.2.22.pptxUnit 2_DBMS_10.2.22.pptx
Unit 2_DBMS_10.2.22.pptxMaryJoseph79
 
database management system
database management systemdatabase management system
database management systemNivetha Ganesan
 
ASMUG February 2015 Knowledge Event
ASMUG February 2015 Knowledge EventASMUG February 2015 Knowledge Event
ASMUG February 2015 Knowledge Eventjmustac
 
Chapter-2 Database System Concepts and Architecture
Chapter-2 Database System Concepts and ArchitectureChapter-2 Database System Concepts and Architecture
Chapter-2 Database System Concepts and ArchitectureKunal Anand
 
Chapter-3-Lesson 1 DM/ Data-Models.ppt/pptx
Chapter-3-Lesson 1 DM/ Data-Models.ppt/pptxChapter-3-Lesson 1 DM/ Data-Models.ppt/pptx
Chapter-3-Lesson 1 DM/ Data-Models.ppt/pptxmicayaseloisa
 
DBMS data modeling.pptx
DBMS data modeling.pptxDBMS data modeling.pptx
DBMS data modeling.pptxMrwafaAbbas
 
Fundamentals of Database ppt ch02
Fundamentals of Database ppt ch02Fundamentals of Database ppt ch02
Fundamentals of Database ppt ch02Jotham Gadot
 
Ch1.2_DB system Concepts and Architecture.pptx
Ch1.2_DB system Concepts and Architecture.pptxCh1.2_DB system Concepts and Architecture.pptx
Ch1.2_DB system Concepts and Architecture.pptx01fe20bcv092
 
Se ii unit3-architectural-design
Se ii unit3-architectural-designSe ii unit3-architectural-design
Se ii unit3-architectural-designAhmad sohail Kakar
 
Enterprise Software Development Patterns
Enterprise Software Development PatternsEnterprise Software Development Patterns
Enterprise Software Development PatternsJosh Lane
 
Diksha sda presentation
Diksha sda presentationDiksha sda presentation
Diksha sda presentationdikshagupta111
 
architectural design
 architectural design architectural design
architectural designPreeti Mishra
 
SysCon 2013 SysML & Requirements
SysCon 2013 SysML & RequirementsSysCon 2013 SysML & Requirements
SysCon 2013 SysML & RequirementsPascal Roques
 
Database Systems - Lecture Week 1
Database Systems - Lecture Week 1Database Systems - Lecture Week 1
Database Systems - Lecture Week 1Dios Kurniawan
 

Similar to Data Modeling - Entity Relationship Diagrams-1.pdf (20)

Week 2 - Database System Development Lifecycle-old.pptx
Week 2 - Database System Development Lifecycle-old.pptxWeek 2 - Database System Development Lifecycle-old.pptx
Week 2 - Database System Development Lifecycle-old.pptx
 
Unit 2_DBMS_10.2.22.pptx
Unit 2_DBMS_10.2.22.pptxUnit 2_DBMS_10.2.22.pptx
Unit 2_DBMS_10.2.22.pptx
 
database management system
database management systemdatabase management system
database management system
 
ASMUG February 2015 Knowledge Event
ASMUG February 2015 Knowledge EventASMUG February 2015 Knowledge Event
ASMUG February 2015 Knowledge Event
 
Chapter-2 Database System Concepts and Architecture
Chapter-2 Database System Concepts and ArchitectureChapter-2 Database System Concepts and Architecture
Chapter-2 Database System Concepts and Architecture
 
Chapter-3-Lesson 1 DM/ Data-Models.ppt/pptx
Chapter-3-Lesson 1 DM/ Data-Models.ppt/pptxChapter-3-Lesson 1 DM/ Data-Models.ppt/pptx
Chapter-3-Lesson 1 DM/ Data-Models.ppt/pptx
 
DBMS data modeling.pptx
DBMS data modeling.pptxDBMS data modeling.pptx
DBMS data modeling.pptx
 
Analysis
AnalysisAnalysis
Analysis
 
Fundamentals of Database ppt ch02
Fundamentals of Database ppt ch02Fundamentals of Database ppt ch02
Fundamentals of Database ppt ch02
 
Ch1.2_DB system Concepts and Architecture.pptx
Ch1.2_DB system Concepts and Architecture.pptxCh1.2_DB system Concepts and Architecture.pptx
Ch1.2_DB system Concepts and Architecture.pptx
 
Se ii unit3-architectural-design
Se ii unit3-architectural-designSe ii unit3-architectural-design
Se ii unit3-architectural-design
 
DBMS
DBMS DBMS
DBMS
 
(Dbms) class 1 & 2 (Presentation)
(Dbms) class 1 & 2 (Presentation)(Dbms) class 1 & 2 (Presentation)
(Dbms) class 1 & 2 (Presentation)
 
Enterprise Software Development Patterns
Enterprise Software Development PatternsEnterprise Software Development Patterns
Enterprise Software Development Patterns
 
Diksha sda presentation
Diksha sda presentationDiksha sda presentation
Diksha sda presentation
 
architectural design
 architectural design architectural design
architectural design
 
SysCon 2013 SysML & Requirements
SysCon 2013 SysML & RequirementsSysCon 2013 SysML & Requirements
SysCon 2013 SysML & Requirements
 
Dbms unit 1
Dbms unit 1Dbms unit 1
Dbms unit 1
 
Soft requirement
Soft requirementSoft requirement
Soft requirement
 
Database Systems - Lecture Week 1
Database Systems - Lecture Week 1Database Systems - Lecture Week 1
Database Systems - Lecture Week 1
 

More from Christalin Nelson

More from Christalin Nelson (20)

Concurrency Control in Database Management system
Concurrency Control in Database Management systemConcurrency Control in Database Management system
Concurrency Control in Database Management system
 
Transaction Management in Database Management System
Transaction Management in Database Management SystemTransaction Management in Database Management System
Transaction Management in Database Management System
 
Packages and Subpackages in Java
Packages and Subpackages in JavaPackages and Subpackages in Java
Packages and Subpackages in Java
 
Bitwise complement operator
Bitwise complement operatorBitwise complement operator
Bitwise complement operator
 
Advanced Data Structures - Vol.2
Advanced Data Structures - Vol.2Advanced Data Structures - Vol.2
Advanced Data Structures - Vol.2
 
Deadlocks
DeadlocksDeadlocks
Deadlocks
 
CPU Scheduling
CPU SchedulingCPU Scheduling
CPU Scheduling
 
Process Synchronization
Process SynchronizationProcess Synchronization
Process Synchronization
 
Process Management
Process ManagementProcess Management
Process Management
 
Applications of Stack
Applications of StackApplications of Stack
Applications of Stack
 
Storage system architecture
Storage system architectureStorage system architecture
Storage system architecture
 
Data Storage and Information Management
Data Storage and Information ManagementData Storage and Information Management
Data Storage and Information Management
 
Application Middleware Overview
Application Middleware OverviewApplication Middleware Overview
Application Middleware Overview
 
Network security
Network securityNetwork security
Network security
 
Directory services
Directory servicesDirectory services
Directory services
 
System overview
System overviewSystem overview
System overview
 
Storage overview
Storage overviewStorage overview
Storage overview
 
Computer Fundamentals-2
Computer Fundamentals-2Computer Fundamentals-2
Computer Fundamentals-2
 
Computer Fundamentals - 1
Computer Fundamentals - 1Computer Fundamentals - 1
Computer Fundamentals - 1
 
Advanced data structures vol. 1
Advanced data structures   vol. 1Advanced data structures   vol. 1
Advanced data structures vol. 1
 

Recently uploaded

CLASSIFICATION OF ANTI - CANCER DRUGS.pptx
CLASSIFICATION OF ANTI - CANCER DRUGS.pptxCLASSIFICATION OF ANTI - CANCER DRUGS.pptx
CLASSIFICATION OF ANTI - CANCER DRUGS.pptxAnupam32727
 
Grade Three -ELLNA-REVIEWER-ENGLISH.pptx
Grade Three -ELLNA-REVIEWER-ENGLISH.pptxGrade Three -ELLNA-REVIEWER-ENGLISH.pptx
Grade Three -ELLNA-REVIEWER-ENGLISH.pptxkarenfajardo43
 
Satirical Depths - A Study of Gabriel Okara's Poem - 'You Laughed and Laughed...
Satirical Depths - A Study of Gabriel Okara's Poem - 'You Laughed and Laughed...Satirical Depths - A Study of Gabriel Okara's Poem - 'You Laughed and Laughed...
Satirical Depths - A Study of Gabriel Okara's Poem - 'You Laughed and Laughed...HetalPathak10
 
6 ways Samsung’s Interactive Display powered by Android changes the classroom
6 ways Samsung’s Interactive Display powered by Android changes the classroom6 ways Samsung’s Interactive Display powered by Android changes the classroom
6 ways Samsung’s Interactive Display powered by Android changes the classroomSamsung Business USA
 
ARTERIAL BLOOD GAS ANALYSIS........pptx
ARTERIAL BLOOD  GAS ANALYSIS........pptxARTERIAL BLOOD  GAS ANALYSIS........pptx
ARTERIAL BLOOD GAS ANALYSIS........pptxAneriPatwari
 
Oppenheimer Film Discussion for Philosophy and Film
Oppenheimer Film Discussion for Philosophy and FilmOppenheimer Film Discussion for Philosophy and Film
Oppenheimer Film Discussion for Philosophy and FilmStan Meyer
 
Integumentary System SMP B. Pharm Sem I.ppt
Integumentary System SMP B. Pharm Sem I.pptIntegumentary System SMP B. Pharm Sem I.ppt
Integumentary System SMP B. Pharm Sem I.pptshraddhaparab530
 
4.9.24 Social Capital and Social Exclusion.pptx
4.9.24 Social Capital and Social Exclusion.pptx4.9.24 Social Capital and Social Exclusion.pptx
4.9.24 Social Capital and Social Exclusion.pptxmary850239
 
BÀI TẬP BỔ TRỢ TIẾNG ANH 11 THEO ĐƠN VỊ BÀI HỌC - CẢ NĂM - CÓ FILE NGHE (GLOB...
BÀI TẬP BỔ TRỢ TIẾNG ANH 11 THEO ĐƠN VỊ BÀI HỌC - CẢ NĂM - CÓ FILE NGHE (GLOB...BÀI TẬP BỔ TRỢ TIẾNG ANH 11 THEO ĐƠN VỊ BÀI HỌC - CẢ NĂM - CÓ FILE NGHE (GLOB...
BÀI TẬP BỔ TRỢ TIẾNG ANH 11 THEO ĐƠN VỊ BÀI HỌC - CẢ NĂM - CÓ FILE NGHE (GLOB...Nguyen Thanh Tu Collection
 
Team Lead Succeed – Helping you and your team achieve high-performance teamwo...
Team Lead Succeed – Helping you and your team achieve high-performance teamwo...Team Lead Succeed – Helping you and your team achieve high-performance teamwo...
Team Lead Succeed – Helping you and your team achieve high-performance teamwo...Association for Project Management
 
Healthy Minds, Flourishing Lives: A Philosophical Approach to Mental Health a...
Healthy Minds, Flourishing Lives: A Philosophical Approach to Mental Health a...Healthy Minds, Flourishing Lives: A Philosophical Approach to Mental Health a...
Healthy Minds, Flourishing Lives: A Philosophical Approach to Mental Health a...Osopher
 
Sulphonamides, mechanisms and their uses
Sulphonamides, mechanisms and their usesSulphonamides, mechanisms and their uses
Sulphonamides, mechanisms and their usesVijayaLaxmi84
 
31 ĐỀ THI THỬ VÀO LỚP 10 - TIẾNG ANH - FORM MỚI 2025 - 40 CÂU HỎI - BÙI VĂN V...
31 ĐỀ THI THỬ VÀO LỚP 10 - TIẾNG ANH - FORM MỚI 2025 - 40 CÂU HỎI - BÙI VĂN V...31 ĐỀ THI THỬ VÀO LỚP 10 - TIẾNG ANH - FORM MỚI 2025 - 40 CÂU HỎI - BÙI VĂN V...
31 ĐỀ THI THỬ VÀO LỚP 10 - TIẾNG ANH - FORM MỚI 2025 - 40 CÂU HỎI - BÙI VĂN V...Nguyen Thanh Tu Collection
 
Employablity presentation and Future Career Plan.pptx
Employablity presentation and Future Career Plan.pptxEmployablity presentation and Future Career Plan.pptx
Employablity presentation and Future Career Plan.pptxryandux83rd
 

Recently uploaded (20)

CLASSIFICATION OF ANTI - CANCER DRUGS.pptx
CLASSIFICATION OF ANTI - CANCER DRUGS.pptxCLASSIFICATION OF ANTI - CANCER DRUGS.pptx
CLASSIFICATION OF ANTI - CANCER DRUGS.pptx
 
Grade Three -ELLNA-REVIEWER-ENGLISH.pptx
Grade Three -ELLNA-REVIEWER-ENGLISH.pptxGrade Three -ELLNA-REVIEWER-ENGLISH.pptx
Grade Three -ELLNA-REVIEWER-ENGLISH.pptx
 
Satirical Depths - A Study of Gabriel Okara's Poem - 'You Laughed and Laughed...
Satirical Depths - A Study of Gabriel Okara's Poem - 'You Laughed and Laughed...Satirical Depths - A Study of Gabriel Okara's Poem - 'You Laughed and Laughed...
Satirical Depths - A Study of Gabriel Okara's Poem - 'You Laughed and Laughed...
 
INCLUSIVE EDUCATION PRACTICES FOR TEACHERS AND TRAINERS.pptx
INCLUSIVE EDUCATION PRACTICES FOR TEACHERS AND TRAINERS.pptxINCLUSIVE EDUCATION PRACTICES FOR TEACHERS AND TRAINERS.pptx
INCLUSIVE EDUCATION PRACTICES FOR TEACHERS AND TRAINERS.pptx
 
6 ways Samsung’s Interactive Display powered by Android changes the classroom
6 ways Samsung’s Interactive Display powered by Android changes the classroom6 ways Samsung’s Interactive Display powered by Android changes the classroom
6 ways Samsung’s Interactive Display powered by Android changes the classroom
 
Paradigm shift in nursing research by RS MEHTA
Paradigm shift in nursing research by RS MEHTAParadigm shift in nursing research by RS MEHTA
Paradigm shift in nursing research by RS MEHTA
 
Introduction to Research ,Need for research, Need for design of Experiments, ...
Introduction to Research ,Need for research, Need for design of Experiments, ...Introduction to Research ,Need for research, Need for design of Experiments, ...
Introduction to Research ,Need for research, Need for design of Experiments, ...
 
ARTERIAL BLOOD GAS ANALYSIS........pptx
ARTERIAL BLOOD  GAS ANALYSIS........pptxARTERIAL BLOOD  GAS ANALYSIS........pptx
ARTERIAL BLOOD GAS ANALYSIS........pptx
 
Oppenheimer Film Discussion for Philosophy and Film
Oppenheimer Film Discussion for Philosophy and FilmOppenheimer Film Discussion for Philosophy and Film
Oppenheimer Film Discussion for Philosophy and Film
 
Integumentary System SMP B. Pharm Sem I.ppt
Integumentary System SMP B. Pharm Sem I.pptIntegumentary System SMP B. Pharm Sem I.ppt
Integumentary System SMP B. Pharm Sem I.ppt
 
4.9.24 Social Capital and Social Exclusion.pptx
4.9.24 Social Capital and Social Exclusion.pptx4.9.24 Social Capital and Social Exclusion.pptx
4.9.24 Social Capital and Social Exclusion.pptx
 
BÀI TẬP BỔ TRỢ TIẾNG ANH 11 THEO ĐƠN VỊ BÀI HỌC - CẢ NĂM - CÓ FILE NGHE (GLOB...
BÀI TẬP BỔ TRỢ TIẾNG ANH 11 THEO ĐƠN VỊ BÀI HỌC - CẢ NĂM - CÓ FILE NGHE (GLOB...BÀI TẬP BỔ TRỢ TIẾNG ANH 11 THEO ĐƠN VỊ BÀI HỌC - CẢ NĂM - CÓ FILE NGHE (GLOB...
BÀI TẬP BỔ TRỢ TIẾNG ANH 11 THEO ĐƠN VỊ BÀI HỌC - CẢ NĂM - CÓ FILE NGHE (GLOB...
 
Team Lead Succeed – Helping you and your team achieve high-performance teamwo...
Team Lead Succeed – Helping you and your team achieve high-performance teamwo...Team Lead Succeed – Helping you and your team achieve high-performance teamwo...
Team Lead Succeed – Helping you and your team achieve high-performance teamwo...
 
Healthy Minds, Flourishing Lives: A Philosophical Approach to Mental Health a...
Healthy Minds, Flourishing Lives: A Philosophical Approach to Mental Health a...Healthy Minds, Flourishing Lives: A Philosophical Approach to Mental Health a...
Healthy Minds, Flourishing Lives: A Philosophical Approach to Mental Health a...
 
Sulphonamides, mechanisms and their uses
Sulphonamides, mechanisms and their usesSulphonamides, mechanisms and their uses
Sulphonamides, mechanisms and their uses
 
Faculty Profile prashantha K EEE dept Sri Sairam college of Engineering
Faculty Profile prashantha K EEE dept Sri Sairam college of EngineeringFaculty Profile prashantha K EEE dept Sri Sairam college of Engineering
Faculty Profile prashantha K EEE dept Sri Sairam college of Engineering
 
prashanth updated resume 2024 for Teaching Profession
prashanth updated resume 2024 for Teaching Professionprashanth updated resume 2024 for Teaching Profession
prashanth updated resume 2024 for Teaching Profession
 
31 ĐỀ THI THỬ VÀO LỚP 10 - TIẾNG ANH - FORM MỚI 2025 - 40 CÂU HỎI - BÙI VĂN V...
31 ĐỀ THI THỬ VÀO LỚP 10 - TIẾNG ANH - FORM MỚI 2025 - 40 CÂU HỎI - BÙI VĂN V...31 ĐỀ THI THỬ VÀO LỚP 10 - TIẾNG ANH - FORM MỚI 2025 - 40 CÂU HỎI - BÙI VĂN V...
31 ĐỀ THI THỬ VÀO LỚP 10 - TIẾNG ANH - FORM MỚI 2025 - 40 CÂU HỎI - BÙI VĂN V...
 
Employablity presentation and Future Career Plan.pptx
Employablity presentation and Future Career Plan.pptxEmployablity presentation and Future Career Plan.pptx
Employablity presentation and Future Career Plan.pptx
 
Mattingly "AI & Prompt Design: Large Language Models"
Mattingly "AI & Prompt Design: Large Language Models"Mattingly "AI & Prompt Design: Large Language Models"
Mattingly "AI & Prompt Design: Large Language Models"
 

Data Modeling - Entity Relationship Diagrams-1.pdf

  • 1.
  • 2. Data Modeling (Part – 1) Presented by: Mr. S. Christalin Nelson 2/20/2024 Christalin Nelson | Systems Cluster | SOCS 2
  • 3. At a Glance • Terminologies & Constraints • Using High-Level Conceptual Data Models for Database Design • Sample Database Application • Entity Types, Entity Sets, Attributes, Keys, and Value Sets • Relationship Types, Relationship Sets, Roles, and Structural Constraints • Weak Entity Types • Refining ER Design for COMPANY Database • ER Diagrams, Naming Conventions, and Design Issues • Relationship Types of Degrees Higher than Two 3 2/20/2024 Christalin Nelson | Systems Cluster | SOCS 3 of 59
  • 4. 2/20/2024 Few Terminologies (1/2) • Domain – Consists of Name, Data type, Format – Set of atomic values • Several Attributes can have the same domain – Example: Domain named "Phone number" can have attributes home_phone, office_phone, mob_phone • Relation – Table name • Relation Schema (or) Relation Intension – Includes Table Name, List of Attributes • Relation State (or) Relation Extension • Relation instance – Single row (or) tuple Christalin Nelson | Systems Cluster | SOCS 4 of 59
  • 5. 2/20/2024 Few Terminologies (2/2) • Degree or Arity – No. of Attributes • Tuples are considered as facts about a relation (or) values satisfying the predicate • Relations represent – Facts about entities – Facts about relationships • Tuple Ordering • Attribute Ordering • Basic Relational model – Composite and Multivalued attributes are not allowed – Also called a flat relational model Christalin Nelson | Systems Cluster | SOCS 5 of 59
  • 6. 2/20/2024 Types of Constraints (1/6) • Inherent model based constraints or Implicit constraints – Example: • A relation cannot have duplicate tuples • Schema-based constraints or Explicit constraints – Example: • Domain constraints • Constraints on NULLs • Key constraints • Entity Integrity constraints • Referential integrity constraints Christalin Nelson | Systems Cluster | SOCS 6 of 59
  • 7. 2/20/2024 Types of Constraints (2/6) • Application-based or semantic constraints or business rules – Specified and enforced on a relational database or by using general-purpose constraint specification language – Example • The salary of an employee should not exceed salary of employee’s supervisor at DB update – Mechanisms: Triggers, Assertions • Data Dependencies – Example: • Functional and Multivalued dependencies – Used with Normalization Christalin Nelson | Systems Cluster | SOCS 7 of 59
  • 8. 2/20/2024 Types of Constraints (3/6) • State constraints (or) Static constraints – Constraints discussed so far – Define the constraints that a valid state of DB must satisfy • Transition constraints (or) Dynamic constraints – Enforced by application programs or specified using active rules and triggers – Example: • Salary of an employee can only increase Christalin Nelson | Systems Cluster | SOCS 8 of 59
  • 9. 2/20/2024 Types of Constraints (4/6) • Domain Constraint – The value of each attribute must be an atomic value • Meanings for NULL values – (1) Not Applicable • E.g. Person with no college degree would have “null” for “College_degrees” attribute – (2) Unknown value – Value exists but is missing or unavailable • E.g. Height attribute of a person – (3) Unknown value – Does not know if value exists • E.g Home_phone attribute of a person Christalin Nelson | Systems Cluster | SOCS 9 of 59
  • 10. 2/20/2024 Types of Constraints (5/6) • Key constraints – Specified on individual relations – Every table has at least one “Superkey” (subset of attributes) – “Superkey” can have redundant attributes – “Key” cannot have redundant attributes – Any “Superkey” formed from a single attribute is also a “Key” – Rules • (1) “Superkey” & “Key” for each tuple should be distinct => “Unique” constraint • (2) “Key” is a “minimal superkey” – i.e. Removal of an attribute will compromise “Unique” constraint – A relation schema may have more than one “key” => termed as “Candidate key” • One candidate is identified as “Primary key” Christalin Nelson | Systems Cluster | SOCS 10 of 59
  • 11. 2/20/2024 Types of Constraints (6/6) • Entity Integrity constraint – Specified on individual relations – No “Primary key” value can be NULL • Referential integrity constraints – Specified between two relations – “Foreign key” in a dependent relation – Rules • (1) Attributes of FK should have the same domain as of PK • (2) Value of FK = value of PK (or) null – FK can refer to another tuple in its own relation Christalin Nelson | Systems Cluster | SOCS 11 of 59
  • 12. 2/20/2024 Data Modeling using ER Model • Data Application – Database, Application program that implements DB Queries and updates – DB design + Software Engineering (Design, Implementation, Testing of Appln.) • Entity-Relationship (ER) model – Popular high-level conceptual data model – ER diagrams • Diagrammatic notation associated with the ER model • Enhanced-ER (EER) model – Includes concepts such as specialization, generalization, inheritance, and union types (categories) • Unified Modeling Language (UML) – Object modeling Christalin Nelson | Systems Cluster | SOCS 12 of 59
  • 13. 2/20/2024 Using High-Level Conceptual Data Models (1/4) • Requirements collection and analysis – DB designers interview prospective DB users to understand and document data requirements & functional requirements • Result-1: Concise set of users’ requirements specified in a detailed and complete form • Result-2: User-defined operations/transactions applied to the DB – Note: • Techniques used to specify functional requirements in Software design include DFD, Sequence diagrams, scenarios • Functional Analysis – Identify high-level user queries and operations Christalin Nelson | Systems Cluster | SOCS 13 of 59
  • 14. Main phases of database design 2/20/2024 Christalin Nelson | Systems Cluster | SOCS 14 of 46 14 of 59
  • 15. 2/20/2024 Using High-Level Conceptual Data Models (3/4) • Conceptual design – Includes • Concise description of Data requirements • Detailed descriptions of entity types, relationships, and constraints • Use the basic data model operations to specify high-level user queries and operations • Note: Does not include implementation details – Result: Conceptual schema of high-level data model – Used to communicate with non-technical users – Used as a reference to ensure that all users’ data requirements are met and do not conflict Christalin Nelson | Systems Cluster | SOCS 15 of 59
  • 16. 2/20/2024 Using High-Level Conceptual Data Models (4/4) • Logical design (or) data model mapping – Transform Conceptual schema from High-level data model into Implementation data model • Actual implementation of DB using a commercial DBMS with an implementation data model (like Relational or Object-relational DB model) – Result: DB schema (Conceptual/Logical Schema in the data model of a specific DBMS) – Often automated or semi-automated within the DB design tools • Physical design phase – Internal storage structures, file organizations, indexes, access paths, and physical design parameters for the database files are specified Result: Internal schema • Application program development Christalin Nelson | Systems Cluster | SOCS 16 of 59
  • 17. 2/20/2024 Sample Database Application • COMPANY Database – Description – Employee • Each employee has a name, social security number, address, salary, sex (gender), and birth date • Each employee works for one department and can work on several projects that other departments can control – Track the current no. of hours per week that an employee works on each project • Track the direct supervisor of each employee (who is another employee) • A particular employee manages the department – Track the start date when an employee began managing the department – Department • Each department has a unique name, a unique number and may have several locations • Can control several projects – Project • Each project has a unique name, a unique number, and a single location – Dependents • Each dependent has a first name, sex (gender), birth date, and relationship to the employee. • Track the dependents of each employee for insurance purposes Christalin Nelson | Systems Cluster | SOCS 17 of 59
  • 18. 18 2/20/2024 Christalin Nelson | Systems Cluster | SOCS 18 of 59
  • 19. 2/20/2024 Entities and their Attributes (1/5) • ER model describes data as Entities, Relationships, and Attributes • Entities – Things in the real world with independent existence • Attributes – Properties that describe an entity – Types • Composite vs. Simple (atomic) attributes • Single-valued vs. Multi-valued attributes • Stored vs. Derived attributes • NULL values (Not Applicable & Unknown) • Complex attributes Christalin Nelson | Systems Cluster | SOCS 19 of 59
  • 20. 2/20/2024 Entities and their Attributes (2/5) • Composite vs. Simple (atomic) attributes – Attributes that are not divisible are called simple (or) atomic attributes – Composite attributes are divided into smaller subparts (basic attributes) • Useful to model situations in which a user sometimes refers to composite attribute as a unit but at other times refers specifically to its components • Value of composite attribute = Concatenation of values of its component simple attributes – Components of a composite attribute are given within parentheses () & separated with commas » Example: Address (Street_address(Number, Street, Apartment_number), City, State, Zip) • Can form a hierarchy (Pic) Christalin Nelson | Systems Cluster | SOCS 20 of 59
  • 21. 2/20/2024 Entities and their Attributes (3/5) • Single-valued vs. Multi-valued attributes – Singled-valued attributes have a single value for a particular entity • Example: “Age” is a single-valued attribute of a person – Multi-valued attributes have a set of values for the same entity • May have lower & upper bounds to constrain the number of values allowed for each entity • Multivalued attributes are mentioned using braces {} – Example: “color” attribute for a car is {blue, red} Christalin Nelson | Systems Cluster | SOCS 21 of 59
  • 22. 2/20/2024 Entities and their Attributes (4/5) • Stored vs. Derived attributes – Values of Stored attributes are given by the user and stored – Values of Derived attributes should be derived • Derived from the related attributes of an entity – Example: “Age” and “Birth_date” attributes of a person » Age attribute (Derived attribute), Birth_date attribute (Stored attribute) • Derived from related entities – Example: Attribute “Number_of_employees” of a DEPARTMENT entity can be derived by counting the number of employees working for that department Christalin Nelson | Systems Cluster | SOCS 22 of 59
  • 23. 2/20/2024 Entities and their Attributes (5/5) • Complex attributes – Composite and multivalued attributes can be nested arbitrarily – Example: Attribute “Address_phone” of a person who can have >1 residence, and each residence can have a single address and multiple phones { Address_phone ( {Phone(Area_code, Phone_number)}, Address(Street_address(Number, Street, Apartment_number), City, State, Zip) ) } Note: Here “Address” and “Phone” are composite attributes Christalin Nelson | Systems Cluster | SOCS 23 of 59
  • 24. 2/20/2024 Entity Types, Entity Sets, Keys, and Value Sets (1/4) • Entity type – Collection (or set) of entities that have the same attributes – Describes Schema (Intension) for the set of entities Christalin Nelson | Systems Cluster | SOCS 24 of 59
  • 25. 2/20/2024 Entity Types, Entity Sets, Keys, and Value Sets (2/4) • Key attribute – Table has one/more attributes whose values are distinct for each entity in entity set • Some entity types have >1 key attribute • Composite Key Attribute: Combination of attribute values must be distinct for each entity – Satisfies the key or uniqueness constraint – Note: • There is no concept of a primary key in the ER model • The primary key will be chosen during mapping to a relational schema (Relational Model) • Weak Entity Type – An entity type without even one key attribute Christalin Nelson | Systems Cluster | SOCS 25 of 59
  • 26. Entity type Rectangular box enclosing the entity type name Attribute names Enclosed in ovals & are attached to their entity type by straight lines Composite attributes Attached to their component attributes by straight lines Multivalued attributes Displayed in double ovals Key attribute Its name underlined inside the oval 2/20/2024 Christalin Nelson | Systems Cluster | SOCS 26 of 59
  • 27. 2/20/2024 Entity Types, Entity Sets, Keys, and Value Sets (4/4) • Value sets (or domain of values) of Attributes – Set of values that may be assigned to that attribute for each entity – Note: • Value sets are not displayed in ER diagrams • Specified using the basic data types available in most programming languages – An attribute (A) of entity set (E) whose value set is V can be defined as a function from E to the power set P(V) of V • A : E → P(V) – Value of attribute(A) for entity (e) is A(e) • NULL value is represented by empty set • For single-valued attributes, A(e) is restricted to a singleton set for each entity(e) in E • There is no restriction on multivalued attributes • For a composite attribute (A), the value set V is the power set of the Cartesian product of P(V1), P(V2), ..., P(Vn), where V1, V2, ..., Vn are the value sets of the simple component attributes that form A: – V = P (P(V1) × P(V2) × ... × P(Vn)) Christalin Nelson | Systems Cluster | SOCS 27 of 59
  • 28. 2/20/2024 Sample Database Application • COMPANY Database – Description – Employee • Each employee has a name, social security number, address, salary, sex (gender), and birth date • Each employee works for one department and can work on several projects that other departments can control – Track the current no. of hours per week that an employee works on each project • Track the direct supervisor of each employee (who is another employee) • A particular employee manages the department – Track the start date when an employee began managing the department – Department • Each department has a unique name, a unique number and may have several locations • Can control several projects – Project • Each project has a unique name, a unique number, and a single location – Dependents • Each dependent has a first name, sex (gender), birth date, and relationship to the employee. • Track the dependents of each employee for insurance purposes Christalin Nelson | Systems Cluster | SOCS 28 of 59
  • 29. 2/20/2024 Initial Conceptual Design of COMPANY Database Christalin Nelson | Systems Cluster | SOCS 29 of 59
  • 30. 2/20/2024 Relationship Types, Relationship Sets (1/3) • Relationship – An attribute of one entity type refers to another entity type – represent references as relationships, and not as attributes • Relationship Types – As with Entity types & Entity sets, a Relationship type and its corresponding Relationship set are referred to by the same name, R • A relationship type(R) among ‘n’ entity types E1, E2, ..., En defines a set of associations (or) a relationship set among entities from these entity types • Each relationship instance (ri) in R is an association of entities, where the association includes exactly one entity from each participating entity type – Each of the entity types E1, E 2, ..., En is said to participate in the relationship type R; similarly, each of the individual entities e1, e2, ..., en is said to participate in the relationship instance ri = (e1, e2, ..., en). Christalin Nelson | Systems Cluster | SOCS 30 of 59
  • 31. 2/20/2024 Relationship Types, Relationship Sets (2/3) • Example: – Consider a relationship type WORKS_FOR between two entity types EMPLOYEE and DEPARTMENT, which associates each employee with the department for which the employee works in the corresponding entity set • Each relationship instance in the relationship set WORKS_FOR associates one EMPLOYEE entity and one DEPARTMENT entity Christalin Nelson | Systems Cluster | SOCS 31 of 59
  • 32. 2/20/2024 Christalin Nelson | Systems Cluster | SOCS 32 of 59
  • 33. 2/20/2024 Relationship Degree • Degree of a relationship type – Number of participating entity types – Examples • WORKS_FOR relationship is of degree two (Binary) • SUPPLY relationship is of degree three (Ternary) Christalin Nelson | Systems Cluster | SOCS 33 of 59
  • 34. 2/20/2024 Relationship as Attributes • Binary relationship type can be thought of in terms of attributes – Consider WORKS_FOR relationship type • The attribute called ‘Department’ of EMPLOYEE entity type, where the value of ‘Department’ for each EMPLOYEE entity is a reference to the DEPARTMENT entity for which that employee works. – The concept of representing relationship types as attributes is used in a class of data models called functional data models • In object DBs, relationships can be represented by reference attributes, either in one direction or in both directions as inverses • In relational DBs, “foreign keys” are a type of reference attribute used to represent relationships Christalin Nelson | Systems Cluster | SOCS 34 of 59
  • 35. 2/20/2024 Role Names and Recursive Relationships (1/2) • Role names – Role name signifies role that a participating entity plays in each relationship instance – Example: • In WORKS_FOR relationship type, EMPLOYEE plays the role of employee/worker and DEPARTMENT plays the role of department/employer • Recursive relationships – The same entity type participates in >1 relationship types in different roles – The role name should be specified – Example: • SUPERVISION relationship type relates an employee to a supervisor, where both employee and supervisor entities are members of the same EMPLOYEE entity set. Here EMPLOYEE entity type participates twice in SUPERVISION in the role of supervisor & role of supervisee Christalin Nelson | Systems Cluster | SOCS 35 of 59
  • 36. 36 2/20/2024 Christalin Nelson | Systems Cluster | SOCS 36 of 59
  • 37. 2/20/2024 Binary Relationship Constraints (1/5) • The constraints limit the possible combinations of entities that may participate in the corresponding relationship set • Types – Cardinality ratio – Participation constraint • Cardinality ratio – Specifies the maximum no. of relationship instances that the entity can participate in – Possible cardinality ratios for binary relationship types are 1:1, 1:N, N:1, and M:N – Example: WORKS_FOR binary relationship type, DEPARTMENT:EMPLOYEE is of cardinality ratio 1:N • Each department can be related to (employs) any number of employees, but an employee can be related to (work for) only one department Christalin Nelson | Systems Cluster | SOCS 37 of 59
  • 38. 2/20/2024 Christalin Nelson | Systems Cluster | SOCS 38 of 59
  • 39. 2/20/2024 Christalin Nelson | Systems Cluster | SOCS 39 of 59
  • 40. 2/20/2024 Binary Relationship Constraints (4/5) • Participation constraint – Specifies whether the existence of an entity depends on it being related to another entity via relationship type – Specifies the minimum no. of relationship instances that each entity can participate in (sometimes called minimum cardinality constraint) – Types: Total & Partial • Examples: – A company policy states that “every employee must work for a department”. An employee entity can exist only if it participates in at least one WORKS_FOR relationship instance. This is called Total Participation (or) Existence Dependency. – Every employee is not expected to manage a department. The participation of EMPLOYEE in the MANAGES relationship type is Partial Participation. Christalin Nelson | Systems Cluster | SOCS 40 of 59
  • 41. 2/20/2024 Binary Relationship Constraints (5/5) • Structural Constraints – Cardinality ratio and Participation Constraints are together considered as structural constraints of a relationship type • ER Notation – Cardinality ratios: Display 1, M, and N on the diamonds – Total participation: Double line connecting participating entity type to the relationship – Partial participation: Single line • Note: – Either specify no minimum (partial participation) or a minimum of one (total participation) – Specify a specific minimum number on participation in the relationship, such as 4 or 5 Christalin Nelson | Systems Cluster | SOCS 41 of 59
  • 42. 2/20/2024 Attributes of Relationship Types (1/2) • Relationship types can also have attributes, similar to those of entity types. – Example • ‘Hours’ attribute for the WORK_ON relationship type to track the number of hours per week that an employee works on a particular project • ‘Start_date’ attribute for the MANAGES relationship type to track the date on which a manager started managing a department via an attribute Christalin Nelson | Systems Cluster | SOCS 42 of 59
  • 43. 2/20/2024 Attributes of Relationship Types (2/2) • Migration of Attribute of Relation Type => Attribute of Entity Type – Attributes of 1:1 relationship types => can be migrated to any one entity type • Example: ‘Start_date’ attribute for MANAGES relationship can be an attribute of either EMPLOYEE or DEPARTMENT, although conceptually it belongs to MANAGES – Attributes of 1:N relationship types => can be migrated only to entity type on the N- side of the relationship • Example: If WORKS_FOR relationship has an attribute ‘Start_date’ that indicates when an employee started working for a department, this attribute can be included as an attribute of EMPLOYEE – For M:N relationship types => No Migration • Example: The value of ‘Hours’ attribute of the M:N relationship WORKS_ON is determined by an employee-project combination and not separately by either entity Christalin Nelson | Systems Cluster | SOCS 43 of 59
  • 44. 2/20/2024 Weak Entity Type (1/4) • Entity Type that do not have key attributes of their own – vs. Strong Entity Type • Identifying relationship – Relates weak entity type (Child or subordinate entity type) to Owner (Parent or Dominant) entity type • Entities of a weak entity type are identified by being related to specific entities from owner – Always has a total participation constraint or existence dependency • Note: Not every existence dependency results in a weak entity type – Example: DRIVER_LICENSE entity cannot exist unless it is related to a PERSON entity, even though it has its own key (License_number). Hence is not a weak entity. Christalin Nelson | Systems Cluster | SOCS 44 of 59
  • 45. 2/20/2024 Weak Entity Type (2/4) • Example – Entity type DEPENDENT is related to EMPLOYEE via a 1:N relationship. Each employee entity is said to OWN the dependent entities that are related to it. • Note: Two dependents of two distinct employees may, by chance, have the same values for Name, Birth_date, Sex, and Relationship, but they are still distinct entities. They are identified as distinct entities ONLY after determining the employee entity to which each dependent is related. • Partial key or Discriminator – Attribute that uniquely identifies weak entities that are related to same owner entity – Example: The attribute ‘Name’ of DEPENDENT is the partial key Christalin Nelson | Systems Cluster | SOCS 45 of 59
  • 46. 2/20/2024 Weak Entity Type (3/4) • Notation used in ER diagrams – Weak entity type and it’s identifying relationship: Surround their boxes and diamonds with double lines – Partial key attribute: underlined with a dashed or dotted line • Weak entity types can also be represented as complex (composite, multivalued) attributes – Example: Specify a multivalued attribute ‘Dependents’ for EMPLOYEE, which is a composite attribute with component attributes Name, Birth_date, Sex, and Relationship Christalin Nelson | Systems Cluster | SOCS 46 of 59
  • 47. 2/20/2024 Weak Entity Type (4/4) • Any number of levels of weak entity types can be defined – i.e. An owner entity type may itself be a weak entity type • A weak entity type may have >1 identifying entity type • A weak entity type may have an identifying relationship type of degree >2 Christalin Nelson | Systems Cluster | SOCS 47 of 59
  • 48. 2/20/2024 Refining ER Design for COMPANY Database • Change attributes that represent relationships into relationship types • Determine cardinality ratio and participation constraint of each relationship type Christalin Nelson | Systems Cluster | SOCS Relation Type Relation between Cardinality Ratio Participation Constraint Attribute WORKS_FOR DEPARTMENT and EMPLOYEE 1:N EMPLOYEE total participation DEPARTMENT total participation Nil MANAGES EMPLOYEE and DEPARTMENT 1:1 EMPLOYEE partial participation DEPARTMENT total participation Start_date CONTROLS DEPARTMENT and PROJECT 1:N DEPARTMENT partial partcipation PROJECT total participation Nil SUPERVISION EMPLOYEE (supervisor role) and EMPLOYEE (supervisee role) 1:N EMPLOYEE (supervisor role) partial participation EMPLOYEE (supervisee role) partial participation Nil WORKS_ON EMPLOYEE and PROJECT M:N EMPLOYEE total participation PROJECT total participation Hours DEPENDENTS_OF EMPLOYEE and DEPENDENT 1:N EMPLOYEE partial participation DEPENDENT total participation Nil 48 of 59
  • 49. 2/20/2024 Proper naming of Schema Constructs • Choose names that convey meanings attached to different constructs in the schema • Entity types: Singular names rather than plural ones • Entity type names: Nouns, uppercase letters • Attribute names: Nouns, Initial letter is capitalized • Role names: lowercase letters • Relationship type names: Verbs, uppercase letters – Choose binary relationship names to make the ER diagram readable from left to right and from top to bottom • This issue arises because each binary relationship can be described starting from either of the two participating entity types Christalin Nelson | Systems Cluster | SOCS 49 of 59
  • 50. 2/20/2024 Christalin Nelson | Systems Cluster | SOCS Identifying 50 of 59
  • 51. 2/20/2024 Alternative Notations for ER Diagrams (1/2) • Specify structural constraints on relationships – Replace cardinality ratio and participation constraints. Associate a pair of integer numbers (min, max) with each participation of an entity type E in a relationship type R, where 0 ≤ min ≤ max and max ≥ 1 – Note: For Participation constraints • Partial participation (min = 0) • Total participation (min > 0) Christalin Nelson | Systems Cluster | SOCS 51 of 59
  • 52. 52 2/20/2024 Christalin Nelson | Systems Cluster | SOCS 52 of 59
  • 53. 2/20/2024 Choosing between Binary & Higher-Degree Relationships (1/5) • A relationship type(R) of degree(n) will have n edges in an ER diagram, one connecting R to each participating entity type Christalin Nelson | Systems Cluster | SOCS 53 of 59
  • 54. 2/20/2024 Choosing between Binary & Higher-Degree Relationships (2/5) • Three binary relationships cannot replace a ternary relationship, they may do so under certain additional constraints – Example: Existence of three relationship instances (s, p), ( j, p), and (s, j) in CAN_SUPPLY, USES, and SUPPLIES, respectively, does not necessarily imply that an instance (s, j, p) exists in ternary relationship SUPPLY Christalin Nelson | Systems Cluster | SOCS 54 of 59
  • 55. 2/20/2024 Choosing between Binary & Higher-Degree Relationships (3/5) • Some database design tools permit only binary relationships – Ternary relationships are represented as weak entity types with no partial key and with three identifying relationships • Example: The weak entity type SUPPLY is identified by a combination of its three owner entities from SUPPLIER, PART, and PROJECT Christalin Nelson | Systems Cluster | SOCS 55 of 59
  • 56. 2/20/2024 Choosing between Binary & Higher-Degree Relationships (4/5) • A weak entity type with a ternary (or n-ary) identifying relationship type – The weak entity type can have a partial key and several owner entity types Christalin Nelson | Systems Cluster | SOCS 56 of 59
  • 57. 2/20/2024 Choosing between Binary & Higher-Degree Relationships (5/5) • Represent ternary relationship as a regular entity type by introducing an artificial or surrogate key – Example: Ternary relationship SUPPLY is converted to a regular entity type by using artificial Key attribute Supply_id. Three binary N:1 relationships relate SUPPLY to the three participating entity types. Christalin Nelson | Systems Cluster | SOCS 57 of 59
  • 58. 2/20/2024 Constraints on Ternary (or Higher-Degree) Relationships • Two Notations to be used for fully specifying structural constraints on higher-degree relationships – First notation is based on the cardinality ratio notation of binary relationships • If among the three cardinalities, one participation has cardinality specified as 1, then the key will be the combination of the other two participants – Example: Relationship set of SUPPLY is a set of relationship instances (s, j, p), where s - SUPPLIER, j - PROJECT, and p - PART. Suppose that the constraint exists that for a particular project-part combination only one supplier will be used, then, any relationship instance (s, j, p) is uniquely identified in relationship set by its (j, p) combination, which makes (j, p) a key for the relationship set • If all three cardinalities are M or N, then the key will be the combination of all three participants – Second notation is based on (min, max) notation for binary relationships • This constraint have no bearing on determining the key of a higher-degree relationship • Specifies a constraint that places restrictions on how many relationship instances each entity can participate in Christalin Nelson | Systems Cluster | SOCS 58 of 59
  • 59. 2/20/2024 Christalin Nelson | Systems Cluster | SOCS 59