Database Management CH2

relationship type

meaningful association between (or among) entity types

It is important to note that any _______________________ requires special annotations, not always present in a diagramming tool, to show all the business rules of the organizational situation you are modeling

notation

An attribute without a value is said to be _____________

null

Documenting ____________________ and ________________________ of an organization that govern data is exactly what data modeling is all about

rules; policies

The __________________________ at the end of each line on an ERD specify relationship ________________________________, which represent how many entities of one kind relate to how many entities of another kind

symbols; cardinalities

identifying owner

the entity type on which the weak entity depends on; known as owner for short

maximum cardinality

the maximum number of instances of one entity that may be associated with each instance of another entity

minimum cardinality

the minimum number of instances of one entity that may be associated with each instance of another entity

degree

the number of entity types that participate in a relationship

identifying relationship

the relationship between a weak entity type and its owner

entity type

a collection of entities that share common properties or characteristics

Entity-relationship diagram (E-R diagram, or ERD)

a graphical representation of an entity-relationship model

entity-relationship model (E-R model)

a logical representation of the data for an organization or for a business area, using entities for categories of data and relationships for associations between entities

entity

a person, a place, an object, an event, or a concept in which the user environment about which the organization wishes to maintain data

attribute

a property of characteristic of an entity or relationship type that is of interest to the organization; has a noun name

unary relationship

a relationship between the instances of a single entity type; also called recursive relationships

binary relationship

a relationship between the instances of two entity types

cardinality constraint

a rule that specifies the number of instances of one entity that can (or must) be associated with each instance of another entity

ternary relationship

a simultaneous relationship among the instances of three entity types

entity instance

a single occurrence of an entity type

business rule

a statement that defines or constrains some aspect of the business; intended to assert business structure or control or influence behavior of the business

time stamp

a time value that is associated with a data value, often indicating when some event occurred that affected the data value

relationship instance

an association between (or among) entity instances where each relationship instance associates exactly one entity instance from each participating entity type

identifier (attribute)

an attribute (or combination of attributes) whose value distinguishes instance from an entity type

identifier

an attribute or combination of attributes that uniquely distinguish each occurrence of that entity; part of strong entity type

simple (or atomic) attribute

an attribute that cannot be broken down into smaller components that are meaningful to the organization

composite attribute

an attribute that has meaningful component parts (attributes)

optional attribute

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

multivalued attribute

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

required attribute

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

derived attribute

an attribute whose values can be calculated from related attribute values

strong entity type

an entity that exists independently of other entity types; always have a unique characteristic; also known as independent entity

associative entity

an entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity instances

weak entity type

an entity type whose existence depends on some other entity type; known as dependent entity; no business meaning in an E-R diagram without the entity on which it depends; depends on an identifying owner; has a partial identifier

composite identifier

an identifier that consists of a composite attribute

A common mistake people make when they are learning to draw E-R is to _____________________ data entities with other elements of an overall information systems model. A rule to avoid the confusion is that a true data entity will have many possible _____________________________, each with a distinguishing characteristic, as well as one or more other descriptive pieces of _________________-.

confuse; instances; data

definition

considered a type of business rule; explanation of a concept or association between concepts; also known as a structural assertion

An _________________________ is described just once (using metadata) in a database, whereas many ____________________________ of that entity type may be represented by data stored in the database

entity type; instances

__________________________ must be named and defined before they can be used unambiguously in a model of organizational data

Data objects

Special guidelines for naming relationships

1) A relationship name is a verb phrase 2) Avoid vague names

We convert a relationship into an associative entity type when these conditions are met:

1) All relationships participating entity types are "many" relationships 2) The resulting associative entity type has independent meaning to end users and can be identified with a single-attribute identifier 3) The associative entity has one or more attributes in addition to the identifier 4) The associative entity participates in one or more relationships independent of the entities related in the associated relationship

Criteria for selecting identifiers

1) Choose an identifier that will not change its value over the life of each instance of entity type 2) Choose an identifier such that for each instance of the entity, the attribute is guaranteed to have valid values and not be null 3) Avoid the use of intelligent identifiers (or keys) whose structure indicates classifications, locations, etc. 4) Consider substituting single-attribute surrogate identifiers for large composite identifiers

Special guidelines for defining relationships

1) Definition explains what action is being taken and possibly why it is important 2) Give examples to clarify the action 3) Explain any optional participation 4) Explain the reason for any explicit maximum cardinality other than many 6) Should explain any mutually exclusive relationships 7) Explain any restrictions on participation in the relationship 8) Explain the extent of history that is kept in the relationship 9) Explain whether an entity instance involved in a relationship instance can transfer participation to another relationship instance

Guidelines to make data definitions

1) Definitions are gathered from the same sources as all requirements for information systems 2) Should be accompanied by diagrams 3) Be stated in the singular and explain what the data element is, not what it is not 4) Should not be added to a data model until after it has been carefully defined and there is an agreement about the definition

Special guidelines for naming an entity

1) Name is a singular noun 2) Should be specific to the organization 3) Should be concise, using as few words as possible 4) An abbreviation, or a short name, should be specified for each entity type name, and the abbreviation may be sufficient to use in the E-R diagram 5) Event entity types should be named for the result of the event, not the activity or process of the event 6) The name used for the same entity type should be the same on E-R diagrams on which the entity type appears

Special guidelines for naming attributes

1) Name is a singular noun or noun phrase 2) Should be unique 3) Each attribute name should follow a standard format 4) Similar attributes of different entity types should use the same qualifiers and classes, as long as those are the names used in the organization

One should develop data names by...

1) Preparing a definition of the data 2) Removing insignificant or illegal work 3) Arranging the words in a meaningful, repeatable way 4) Assigning a standard abbreviation for each word 5) Determining whether the name already exists, and if so, adding other qualifiers to make the name unique

Data names should...

1) Relate to business, not technical characteristics 2) Be meaningful 3) Be unique 4) Be readable 5) Be composed of words taken from an approved list 6) Be repeatable 7) Follow a standard syntax

Special guidelines for defining attributes

1) State what the attribute is and possibly why it is important 2) Should make it clear what is included and what is not included in the attribute's value 3) Any aliases, or alternative names for the attribute can be specified in the definition or may be included elsewhere in the documentation about the attribute 4) Should indicate if a value for the attribute is required or optional 5) Indicate whether a value for the attribute may change once a value is provided and before the entity instance is deleted 6) Indicate the maximum and minimum number of occurrences of an attribute value for an entity instance (multivalued attribute) 7) Indicate any relationships that attribute has with other attributes

Alternative ways to make a data defintion

1) Use multiple definitions to cover the various situations 2) Use a very general definition that will cover most situations 3) Consider using multiple, related data objects

Special guidelines for defining an entity

1) an entity type definition using starts with "An X is..."; most direct and clear way to state the meaning of an entity type 2) Should include a statement of what the unique characteristic is for each instance of the entity type 3) Should make it clear what entity instances are included and not included in the entity type 4) Include a description of when an instance of the entity type is created and deleted 5) Must specify when an instance might change into an instance of another entity type 6) Must specify what history is to be kept about the instances of the entity type

A database analyst must do the following:

1) identify and understand those rules that govern data 2) represent those rules so that they can be unambiguously understood by information systems developers and users 3) implement those rules in database technology

The __________________________ is the most used as a tool for communications between database designers and end users during the analysis phase of database development

E-R model

The ________________________is used to construct a conceptual data model, which is a representation of the structure and constraints of a database that is independent of software.

E-R model

An accurate and thorough ____________ without metadata may be interpreted in different ways by different people

ERD