Minimum Cardinality
Minimum Cardinality
The minimum cardinality is the number of entity instances that must participate in a relationship. Generally, minimums are stated as either zero or one. If zero, then participation in the relationship is optional. If one, then at least one entity instance must participate in the relationship, which is called mandatory participation. In E-R diagrams, an optional relationship is represented by a small circle on the relationship line; a mandatory relationship is represented by a hash mark or line across the relationship line.
To better understand these terms, consider Figure 5-6. In the Employee_Identity relationship in Figure 5-6(a), the hash marks indicate that an EMPLOYEE is required to have a BADGE, and a BADGE must be allocated to an EMPLOYEE. Such a relationship is referred to as a mandatory- to-mandatory (M-M) relationship, because entities are required on both sides. The complete specification for the Employee_Identity relationship is that it is a 1:1, M-M relationship.
In Figure 5-6(b), the two small circles indicate that the Computer_Assignment relation- ship is an optional-to-optional (O-O) relationship. This means that an EMPLOYEE need not have a COMPUTER, and a COMPUTER need not be assigned to an EMPLOYEE. The Com- puter_Assignment relationship is thus a 1:N, O-O relationship.
Finally, in Figure 5-6(c) the combination of a circle and a hash mark indicates an optional-to-mandatory (O-M) relationship. Here, an EMPLOYEE must be assigned to at least one SKILL, but a SKILL may not necessarily be related to any EMPLOYEE. The complete specification for the Qualification relationship is thus an N:M, O-M relationship. The position of the circle and the hash mark are important. Because the circle is in front of EMPLOYEE, it means that the employee is optional in the relationship.
Figure 5-6 (a) Mandatory-to-Mandatory (M-M) Relationship
BADGE Examples
Minimum Cardinality
EMPLOYEE
Employee_Identity
(b) Optional-to-Optional (O-O) Relationship
Computer_Assignment
(c) Optional-to-Mandatory (O-M) Relationship
EMPLOYEE
N:M
SKILL
Qualification
Part 2 Database Design
Sometimes when interpreting diagrams like Figure 5-6(c) students become confused about which entity is optional and which is required. An easy way
to clarify this situation is to imagine that you are standing in the diamond on the relation- ship line. Imagine looking toward one of the entities. If you see an circle in that direction, then that entity is optional; if you see a hash mark, then that entity is required. Thus, in Figure 5-6(c), if you stand on the diamond and look toward SKILL, you see a hash mark. This means that SKILL is required in the relationship.
A fourth option, a mandatory-to-optional (M-O) relationship is not shown in Figure 5-6. But, if we exchange the circle and the hash mark in Figure 5-6(c), then Qualification becomes an M-O relationship. In that case, an EMPLOYEE need not have a SKILL, but a SKILL must have at least one EMPLOYEE.
As with maximum cardinalities, in rare cases the minimum cardinality is a specific number. To represent the relationship between PERSON and MARRIAGE, for example, the minimum cardinality would be 2:Optional.
Parts
» This page intentionally left blank
» Reporting and Data Mining Database Applications
» Database Applications and SQL
» Reading Specified Columns and Rows from a Single Table
» “Does Not Work with Microsoft Access ANSI-89 SQL”
» Processing SQL Statements in Microsoft Access 2010
» Using SQL in Microsoft SQL Server 2008 R2
» Using SQL in Oracle Database 11g
» Using SQL in Oracle MySQL 5.5
» Wildcards in SQL WHERE Clauses
» Using SQL Built-in Functions
» SQL Expressions in SQL SELECT Statements
» Querying Multiple Tables with Subqueries
» Querying Multiple Tables with Joins
» Comparing Subqueries and Joins
» Finding Functional Dependencies
» Eliminating Anomalies from Multivalued Dependencies
» The Multivalue, Multicolumn Problem
» The General-Purpose Remarks Column
» R Diagrams Using the IE Crow’s Foot Model
» The Multivalued Attribute Pattern
» The Archetype/Instance Pattern
» The Student Acceptance Letter
» X This is a warning, no further action is required.
» 1:1 Relationships Between Strong Entities
» M Relationships Between Strong Entities
» Relationships in Mixed Entity Designs
» Representing Ternary and Higher-Order Relationships
» Relational Representation of the Highline University Data Model
» Surrogate Key Database Design
» Column Properties for the View Ridge Database Design Tables
» Variations in SQL Data Types
» Implementing Data Constraints
» Populating the View Ridge Database Tables
» Using Triggers to Provide Default Values
» The WORK_AddWorkTransaction Stored Procedure
» • If a PROJECT row is deleted, then the project has been canceled, and it is unneces-
» Reducing Cardinalities (with Data Loss)
» Optimistic Versus Pessimistic Locking
» Declaring Lock Characteristics
» Processing Rights and Responsibilities
» Recovery via Rollback/Rollforward
» Maintaining the Data Repository
» Types of Distributed Databases
» • Express Edition. This free, feature-limited version is available for download. It
» SQL Server 2008 R2 SQL Statements and SQL Scripts
» Creating the View Ridge Database Table Structure
» Populating the VRG Tables with Data
» The Stored Procedure InsertCustomerAndInterests
» The Stored Procedure InsertCustomerWithTransaction
» A Trigger for Setting Default Values
» A Trigger for Enforcing a Data Constraint
» A Trigger for Enforcing a Required Child Constraint
» Creating an ODBC Data Source Name
» Materializing XML Documents with XSLT
» Using the SQL SELECT . . . FOR XML Statement
» Multitable SELECT with FOR XML
» A Schema with Two Multivalued Paths
» Problems with Operational Data
» Using SQL for Market Basket Analysis
Show more