*Multiplicity of Relationships*

Like the binary relationships of the E/R model, a pair of inverse relationships in ODL can be classified as either many-many, many-one in either direction, or one-one. The type declarations for the pair of relationships tells us which.

1. If we have a many-many relationship between classes C and D, then in class C the type of the relationship is Set<D>, and in class D the type is set <C>.

2. If the relationship is many-one from C to D, then the type of the relationship in C is just D, while the type of the relationship in D is Set<C>.

3. If the relationship is many-one from D to C, then the roles of C and D are reversed in (2) above.

4. If the relationship is one-one, then the type of the relationship in C is just D, and in D it is just C.

Note, that as in the E/R model, we allow a many-one or one-one relationship to include the case where for some objects the "one" is in fact "none". For example, a many-one relationship from C to D might have a missing or "null" value of the relationship in some of the C objects. Certainly, since a D object could be linked with any set of C objects, it is also allowable for that set to be empty for some D objects.**Example :** In "Relationships in ODL / Inverse Relationships" Figure (a), we have the declaration of three classes, Movie, Star, and Studio. The first two of these have already been introduced in "Attributes in ODL" Examples (a) and (b). We also discussed the relationship pair stars and starredIn. Since each of their types uses Set, we see that this pair represents a many-many relationship between Star and Movie.

Studio objects have attributes name and address; these appear in lines (13) and (14). Note that the type of addresses here is a string, rather than a structure as was used for the address attribute of class Star on line (10). There is nothing wrong with using attributes of the same name but different types in different classes.

In line (7) we see a relationship ownedBy from movies to studios. Since the type of the relationship is Studio, and not Set<Studio>, we are asserting that for each movie there is one studio that owns it. The inverse of this relationship is found on line (15). There we see the relationship owns from studios to movies. The type of this relationship is Set<Movie>, showing that each studio owns a set of movies - perhaps 0, perhaps 1, or perhaps a large number of movies.

### Tags

- binary relationship
- inverse relationship
- attributes
- e/r model
- Simple Table Declarations
- Defining a Relation Schema in SQL
- Deletion / Updates
- Database Modifications
- Grouping / HAVING Clauses
- Full-Relation Operations
- Natural Joins / Outerjoins
- Subqueries in FROM Clauses
- Conditions Involving Tuples
- Subqueries
- Union, Intersection, and Difference of Queries
- Interpreting Multirelation Queries
- Disambiguating Attributes
- Queries Involving More Than One Relation
- Null Values and Comparisons Involving NULL
- Selection in SQL
- Projection in SQL
- Additional Constraint Examples
- Extending the Projection Operator
- Extended Operators of Relational Algebra
- Union, Intersection, and Difference of Bags
- Relational Operations on Bags
- A Linear Notation for Algebraic Expressions
- Dependent and Independent Operations
- Renaming
- Combining Operations to Form Queries
- Selection / Cartesian Product
- Set Operations on Relations
- An Algebra of Relational Operations
- Relational Algebra
- Attribute Lists
- Semistructured Data Representation
- Object-Oriented Versus Object-Relational
- Nested Relations
- What If There Is No Key
- Representing ODL Relationships
- Representing Other Type Constructors
- Representing Set-Valued Attributes
- Nonatomic Attributes in Classes
- Declaring Keys in ODL
- Subclasses in ODL / Multiple Inheritance in ODL
- Types in ODL
- Methods in ODL
- Relationships in ODL / Inverse Relationships
- Attributes in ODL
- Introduction to ODL
- The Type System
- Decomposition into Fourth Normal Form
- Reasoning About Multivalued Dependencies
- Definition of Multivalued Dependencies
- Multivalued Dependencies
- Third Normal Form
- Boyce-Codd Normal Form
- Projecting Functional Dependencies
- Closing Sets of Functional Dependencies
- The Transitive Rule
- Why the Closure Algorithm Works
- Computing the Closure of Attributes
- Trivial Functional Dependencies
- The Splitting/Combining Rule
- Rules About Functional Dependencies
- Keys of Relations
- Using Null Values to Combine Relations - Comparison of Approaches
- An Object-Oriented Approach
- Converting Subclass Structures to Relations
- Handling Weak Entity Sets
- Combining Relations
- From E/R Relationships to Relations
- From Entity Sets to Relations
- Relation Instances
- Equivalent Representations of a Relation
- Tuples / Domains
- Attributes / Schemas
- The Relational Data Model
- Summary of The Entity-Relationship Data Model
- Weak Entity Set Notation
- Requirements for Weak Entity Sets
- Representing Keys in the E/R Model
- Keys in the E/R Model
- The Modeling of Constraints
- Picking the Right Kind of Element
- Design Principles
- Subclasses in the E/R Model
- Attributes on Relationships
- Elements of the E/R Model
- Relational Database Systems