Chapter 2: Modeling Data in The Organization

Defining Entities

*"An X is..." *Describe unique characteristics of each instance *Explicit about what is and is not the entity *When an instance is created or destroyed *Changes to other entity types *History that should be kept

Names:

*Singular noun *Specific to organization *Concise, or abbreviation *For event entities, the result not the process *Name consistent for all diagrams

An entity SHOULD NOT BE

+A user of the database system +An output of the database system (e.g., a report)

An entity SHOULD BE:

+An object that will have many instances in the database +An object that will be composed of multiple attributes +An object that we are trying to model

Attributes

Properties or characteristics of an entity or relationship type (often corresponds to a field in a table)

Choose Identifiers that

Will not change in value Will not be null

Common mistake people make when they are learning to draw E-R diagrams,

especially if they are already familiar with data process modeling (such as data flow diagramming), is to confuse data entities with other elements of an overall information systems model.

Entity relationship (ER) diagrams

include rectangles representing entities, and lines between the entities representing relationships.

A simple rule to avoid confusing data entities with other elements of an overall information systems model

is that a true data entity will have many possible instances, each with a distinguishing characteristic, as well as one or more other descriptive pieces of data.

Relationship instance

link between entities (corresponds to primary key-foreign key equivalencies in related tables)

Optional

may not have a value for every entity (or relationship) instance with which it is associated

Multivalued

may take on more than one value for a given entity (or relationship) instance

Required

must have a value for every entity (or relationship) instance with which it is associated

Entity Instance

person, place, object, event, concept (often corresponds to a row in a table)

Attribute

property or characteristic of an entity or relationship type

Unary degree

represents a relationship between entities of the same entity type

Ternary degree

represents a relationship between entities of three different entity types.

Binary degree

represents a relationship between entities of two different entity types

Entities can be

strong, weak, or associative.

Composite attribute

An attribute that has meaningful component parts (attributes)

Identifier (Key)

an attribute (or combination of attributes) that uniquely identifies individual instances of an entity type

Candidate Identifier

an attribute that could be an identifier...satisfies the requirements for being an identifier

Relationships have

cardinalities, which can be one-to-one, one-to-many, or many-to-many. In addition, on each side of the relationship you can specify that it is mandatory or optional.

Relationship type

category of relationship...link between entity types

Entity Type

collection of entities (often corresponds to a table)

Derived

values can be calculated from related attribute values (not physically stored in the database)

Principle of Realtionship

you can have relationships between any number of entity types, so the term for this degree is "n-ary".