three properties of Relationships in er studio data model

近来首次用er studio对负责的一个项目的数据库进行设计。便学边用，对其中的一些东东有了小小心得，与大家
分享。
er studio数据之间的大概有三个属性，建立表之间的关系时，有5种类型可选(identifying relationship,non-identifying mandatory relationship,non-identifying optional relationship,) 这5种关系类型，都是由3种属性演化过来的，为了不失原义，下面引用英文表述说明问题

ER/Studio propagates foreign keys based on three properties:

1，Type

      DEF1X supports three relationship types:

Identifying
Non-Identifying
Non-Specific

The selection of relationship types is fundamental to the referential integrity built into your data models. To help you select the relationship type appropriate to your environment, each of the supported relationship types is described below.

Identifying Relationships

Identifying relationships propagate the parent entity's primary key to the child's primary key. In the IDEF1X notation, identifying relationships are drawn as solid lines with a solid circle terminating the child entity.

Non-Identifying Relationships

Non-identifying relationships propagate the parent entity's primary key to the non-key attributes of the child. In the IDEF1X notation, non-identifying relationships are drawn as dashed lines with a solid circle terminating the child entity. If the non-identifying relationship is optional, then a hollow diamond terminates the parent entity.

Non-Specific Relationships

Non-specific relationships denote many-to-many relationships. Because many-to-many relationships cannot be resolved, non-specific relationships do not propagate any foreign keys. Many-to-many relationships are undesirable and should be removed as you normalize your data model. In the IDEF1X notation, non-specific relationships are drawn as solid lines with solid circles terminating both entities.

       Relationship Types and Compound Keys

Think carefully about the use of different relationship types and its implications concerning identification. Identifying relationships propagate primary keys as primary keys to child entities, resulting in compound keys. The use of compound keys is often valid and appropriate. However, you should use them only when needed since they limit the flexibility of your data model. Whenever you use a compound key, this means that the data contained in the child entity can only be identified in the context of its parent. If you ever need to use the data independently, then you will have a problem.

 2，Existence
       

      Understanding Relationship Existence

---

Existence describes the relationship between a pair of entities from the perspective of the child entity. Fundamentally, it asks the question, "Is a foreign key value always required in the child entity?" The possible answers are:

Existence	Meaning
Optional	A foreign key value is not always required in the child entity. However, if a value does exist, then the foreign key value must be found in the primary key of the parent.
Mandatory	A foreign key value must exist in the child entity and the foreign key value must be found in the primary key of the parent.

To illustrate the use of existence, let's take the example of Order and OrderStatus. If you set the relationship existence to optional, then Orders could exist without being assigned an OrderStatus. Thus, you may or may not know whether any given Order is fulfilled, cancelled or on back order, which would certainly complicate business operations and probably lead to poor customer service. In this example, it probably is desirable to set existence to mandatory. However, you must enforce the specification of this information, both through your information systems and business practices.

Relationship Type Settings

Identifying Relationships: Are always mandatory.
Non-Identifying Relationships: Can be mandatory or optional. In the IDEF1X notation, optional non-identifying relationships are notated with a hollow diamond at the parent end of the relationship line.
Non-Specific Relationships: Cannot be enforced in non-specific relationships because we cannot resolve many-to-many relationships.

Effect on Cardinality

Relationship existence also has implications for relationship cardinality. If a relationship is mandatory, then the cardinality must be in the form of one-to-something. If it is optional, then the cardinality would be in the form of zero or one-to-something.

Enforcing Existence in the Physical Design

ER/Studio carries the meaning of relationship to the physical design. To enforce relationship existence rules, it defaults the foreign key columns propagated by a mandatory relationship to NOT NULL. Optional relationships propagate foreign key columns that can be NULL.

3，Cardinality
     

Cardinality describes the quantitative dimension in the relationship between a pair of entities as viewed from the perspective of the parent entity. Fundamentally, it asks the question, "How many corresponding instances in the child entity might I find for any given primary key value of the parent entity?" The answer can range from zero to many (N).

To illustrate the use of cardinality, we start with the example of Customer and CustomerNote. In this example, customer is the parent to CustomerNote via an identifying relationship. Although a Customer must identify every CustomerNote, this does not mean that every Customer must have a CustomerNote, since this assertion would be impractical. To accommodate flexible business practice, we would set cardinality to One-to-Zero or More (each Customer may have zero or more CustomerNotes).

To contrast the use of cardinality, let's now take the example of Order and OrderDetail. Of course, every Order must have at least OrderDetail, otherwise how would we know what a customer has purchased? In this example, we would set cardinality to One-to-One or More (each Order must have at least one OrderDetail).

Although cardinality is a powerful concept for expressing business rules, you should know that no database can directly enforce cardinality. To enforce cardinality constraints, you must effect it through procedural database logic or somewhere other than in the database.

Cardinality Notation

Cardinality is read as the ratio of related parent and child entity instances. The cardinality ratio for the parent entity depends on whether the relationship is mandatory (one or more) or optional (zero or more). IDEF1X supports four different cardinality ratios for the child entity: zero-or-more, one-or-more (P), zero-or-one (Z), and exactly N (N). The IDEF1X notation is illustrated below: