Chapter 2

4 conditions that suggest the designer should model a relationship an an associate entity type

1) All relationships of participating entity types are "many" relationships 2) The resulting associative entity type has independent meaning to end users and, preferable, can be identified with a single-attribute identifier 3) The associate 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

4 reasons why many systems designers believe that data modeling is important and arguable the most important part of the systems development process

1) Allows data integrity in an information system 2) Facilitates interaction and communication between all employees thus reducing misunderstandings 3) Fosters the understanding of the organization (rules) that are being developed 4) Provide savings in maintenance or development costs by knowing the requirements before software development and hardware acquisitions

6 general guidelines for naming data objects in a data model

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

4 criteria for selecting identifiers of entites

1) choose identifier that will not change its value over the life of each instance of the entity type 2) choose such that for each instance of the entity, the attribute is guaranteed to have valid values and not be null 3) avoid so-called intelligent identifiers, whose structure indicates classifications, locations and so on 4) consider substituting single-attribute surrogate identifies for large composite identifiers

4 types of cardinality constraints

1) mandatory one 2) mandatory many 3) optional one 4) optional many

Where can you find business rules in an organization

Business rules appear in descriptions of business functions, events, policies, units, stakeholders, and other objects. These descriptions can be found in interview notes from individual and group sources. Rules are identified by asking questions about the who, what, when, where, why, and how of the organization

Give an example of the use of effective dates as attributes of an entity

In a university, students must work on an assignment for a given time period. Entity would be student. PK is student ID. Another attribute, advisor, is listed as, Advisor (Advisor Name Advise Start Date Advise End Date)

identifying relationship

The relationship between a weak entity type and its owner

State a rule that says when to extract an attribute from one entity type and place it in a linked entity type

When the attribute of one entity type is found as an identifier, a data designer should place the extracted attribute from an entity type into another related entity type. In such case, both the exchanging entity types should take part in the relationship. Also suits when same attributes should be shared by a number of entity instances.

entity type

a collection of entities that share common properties or characteristics

relationship type

a meaningful association between entity types

attribute

a property or characteristic of an entity or relationship type that is of interest to the organization

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 (minimum/maximum cardinality)

entity instance

a single occurrence of an entity type

business rule

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

example of a composite identifier attribute

employee details. need employee name and ID number.

explain the distinction between entity type and entity instance

entity instance is one occurrence of an entity type. entity type name is given to each. but under each single entity type, there will be hundreds of entity instances. example: type: EMPLOYEE. hundreds of Employee ID or Employee Name

example of an optional attribute

middle name of a person. first and last required but middle is optional.

example of unary relationship

on campus student residence. entity is student. relationship "is roommate". relationship comes from student and goes back into student.

in addition to explaining what action is being taken, what else should a relationship definition explain?

optional participation of entity types, maximum cardinality, relationship of mutually exclusive, restrictions, history extent

give example of a weak entity type. why is it necessary to indicate an identifying relationship?

person to phone call. double line one to many. phone call must be made by a person.

example of composite attribute

phone number. is split into many parts - counting code, area code, and remaining number

example of a multivalued attribute

programming skills of a person. person knows more than one programming language.

example of ternary relationship

sale of a property. the three entities are buyer, owner, property. they are all related with single relationship called "sells"

special guidelines for naming relationships?

should be verbal phrase, represent the action to be taken by the entity types, creative and descriptive, no vague names

bill-of-materials

shows all types of components. subassemblies and parts and so on.

example of an atomic (simple) attribute

social security number. can't be broken down smaller.

why must some identifies be composite rather than simple?

A simple attribute is not unique for all occurrences of an entity type. A combo of simple is needed to identify the entity instances uniquely. Hence composite.

4 reasons why a business rules approach is advocated as a new paradigm for specifying IS requirements

1. Are a core concept in an enterprise because they are an expression of business policy and guide individual and aggregate behavior. Well-structured business rules can be stated in natural language for end users and in a data model for systems developers. 2. Can be expressed in terms that are familiar to end users. Thus, users can define and then maintain their own rules. 3. Are highly maintainable. They are stored in a central repository, and each rule is expressed only once, then shared throughout the organization. Each rule is discovered and documented only once, to be applied in all systems development projects. 4. Enforcement of business rules can be automated through the use of software that can interpret the rules and enforce them using the integrity mechanisms of the database management system.

entity-relationship model

A logical representation of data for an organization or for a business area, using entities for categories of data and relationships for associations between entities. An ERD is the graphical representation.

identifier

an attribute (or combo of attributes) whose value distinguishes instances of an entity type

composite attribute

an attribute that has meaningful component parts

multivalued attribute

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

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

associative entity

an entity type that associates that 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

example of a derived attribute

calculate distance of an object. requires rate and time to compute which are stored in the database.

degree

the number of entity types that participate in a relationship

why is it recommended that every ternary relationship be converted into an associative entity?

the representation of cardinality constraints cannot be shown for ternary relationship for instance. Ternary relationships cannot be represented by E-R diagram tools.

types of relationships (unary, binary, ternary)

unary - relationship between instances of a single entity type binary - rel b/w the instances of two entity types ternary - a simultaneous rel among the instances of three entity types

3 types of relationship degrees

unary, binary, ternary