Sheena Jane U.

Patane BSAT - 3

Chens format
Relationship lines contain a diamond in which is written a word or short phrase that describes
the relationship. For example, the relationship between Invoice and Product may be read as An
invoice contains many products. Some variations permit another word or phrase to be used in
reading the relationship in the other direction, separated with a slash. If the diamond read
Contains/Appears on, then the relationship from Product to Invoice would be read as A
product appears on many invoices.
For many-to-many relationships that require an intersection table in an RDBMS, such as the
one between Invoice and Product, a rectangle is often drawn around the diamond.
Maximum cardinality of each relationship is shown using the symbol 1 for one or M for
many.
Minimum cardinality is not shown.
Attributes, when shown, appear in ellipses (elongated circles), connected to the entity or
relationship to which they belong with a line
The Relational Format
Relationship cardinality is shown with an arrowhead on the line end to signify one and
nothing on the line end to signify many. This will seem odd at first, but it aligns nicely with
object diagrams, so this format is favored by object-oriented designers and developers.
Attributes are shown inside the rectangle that represents each entity.
Unique identifier attributes are shown above a horizontal line within the rectangle and are
usually also shown with PK in bold type (for primary key) in the margin to the left of the
attribute name.
Attributes that are foreign keys are shown with FK and a number in the margin to the left of
the attribute name.



The Information Engineering Format
Identifying relationships Shown with a solid line, are those for which the foreign key is part of
the child entitys primary key.
Non-identifying relationships Shown with a dotted line, are those for which the foreign key is
a non-key attribute in the child entity. In Figure 7-3, the relationship between PRODUCT and
INVOICE_LINE_ITEM is identifying, but the one between CUSTOMER and INVOICE is non-
identifying.
Maximum relationship cardinality Shown with a short perpendicular line across the
relationship near its line end to signify one and a crows foot on the line end to signify
many. This is best understood in combination with minimum cardinality, described next.
Minimum relationship cardinality Shown with a small circle near the end of the line to signify
zero (participation in the relationship is optional) or a short perpendicular line across the
relationship line to signify one (participation in the relationship is mandatory). Figure 7-3
notes a few combinations of minimum and maximum cardinality. For example:
A PRODUCT May have zero to many associated INVOICE_LINE_ITEM occurrences (shown
as a circle and a crows foot); an INVOICE_LINE_ITEM must have one and only one associated
PRODUCT (shown as two vertical bars).
An INVOICE must have one or more associated INVOICE_LINE_ITEM occurrences (shown
as a vertical bar and a crows foot); an INVOICE_LINE_ITEM must have one and only one
associated INVOICE (shown as two vertical bars).
Dependent entities Shown with the corners of the rectangle rounded, have an existence
dependency on one or more other entities (that is, those that cannot exist without the existence of
another). For example, the INVOICE_LINE_ITEM entity depends on both the PRODUCT and
INVOICE entities. Therefore, you cannot delete either an invoice or a product unless you
somehow deal with any related invoice line items. This is valuable information during physical
database design because you must consider the options for handling situations when the
application attempts to delete table rows when dependent entities exist.



The IDEF1X Format
Like the IE format, a solid line indicates that the foreign key is part of the dependent entitys
primary key, while a broken line indicates that the foreign key will be a non-key attribute.
A solid circle next to an entity generally means zero, one, or more occurrences of that entity as
shown on the many end of the line between PRODUCT and INVOICE_LINE_ITEM.
However, there are exceptions:
Adding the symbol P near the solid circle makes the relationship mandatory, signifying that the
cardinality must be one or more. In Figure 7-4, the relationship from INVOICE to
INVOICE_LINE_ITEM is one-to-many and mandatory, meaning that every invoice must have at
least one line item.
Adding the symbol 1 also makes the relationship mandatory. However, this changes the
cardinality of the relationship to one. Said another way, it changes the meaning of the solid circle
from may be one or more to must be one and only one.
Absence of a solid circle at the end of the relationship line means that only one occurrence of
the entity is involved. For example, the absence of any symbol on the end of the line next to
CUSTOMER means one and only one. It may be modified for optionality as well:
If no symbol appears next to the entity at that end of the line, the entity is mandatory in the
relationship. Therefore, an INVOICE_LINE_ITEM must be related to one and only one
PRODUCT.
If a small diamond symbol appears next to the entity, the entity is optional. Were we to add a
diamond next to the CUSTOMER end of the relationship between INVOICE and CUSTOMER,
it would mean that each INVOICE may have zero or one related CUSTOMER occurrences.



Entity Relationship Modeling with Unified Modeling
Each entity is shown as an object class in a rectangle. The symbol <<Entity>> is included with
the class name to denote the type of class.
Unique identifiers (primary keys) are not shown in class diagrams; they are specified elsewhere
within the UML model.
Foreign keys are not shown because they are not used in object-oriented systems. I discuss
object-oriented technology in Chapter 13.
Attributes are shown with a name and a type (separated with a colon). The type is very much
like a relational data type. Attributes in entities are preceded by the symbol +, which means they
are public (visible throughout the entire model).
Relationships are shown with lines.
Cardinality and optionality are shown with a combined symbol near the end of the line.
Available symbols include those shown in the following table:
Symbol Meaning
1 One and only one
* Zero, one, or more
1..* One or more
x..y Between x and y occurrences. Also
x can be 0 or any positive integer
y can be any positive integer or * to denote or more
y must be greater than x (if y and x are the same, then y is simply omitted)
The diamond symbol on the end of a relationship line, as shown in Figure 7-5 on the one end
of the two relationships connected to InvoiceLineItem, denotes what UML calls an aggregation.
An aggregation is a dependency between two entity types that is required for the existence of the
dependent entity. In this case, a line item cannot exist without both the product and the invoice.
If the dependency is always a single entity, the diamond is shown as a solid diamond instead of a
hollow one.
Generalization and specialization (super types and subtypes) are denoted using a line between
the two entities with a hollow arrow pointing toward the general class (the super type).


Super Types and Subtypes