1. Entity-Relationship Design
Information Level Design
8/25/98 and 8/337/98

2. TOP DOWN DATA ANALYSIS
Computer systems are extremely complicated and cannot be developed without careful planning. The most common MIS is the Systems Development Life Cycle. This approach is to build a model of the information system based on the objectives and goals it must meet. This is called top down modeling.

3. The Data Life Cycle

4. Data Modeling Stages

5. Babysitter Service
The AITP Service Club wants to run a babysitting service. Customers call to request a sitter and the Club Coordinator assigns an employee to sit for the customer from a list of employees available for the particular day requested.

6. CRUD Analysis: Functional Decomposition
Assign Employee
Take Call
Check Availability
Assign to Job
Contact Employee
Confirm Appointment
Determine Availability

7. Function-Entity Decomposition

8. Entity-Relationship Model
A logical representation of the data of an organization or business area in graphical form

9. Enterprise E-R Diagram
Employee
Customer
Job

10. Data-Flow Model
A logical representation of the processes and data transformation of a system or organization in graphical form

11. Data Flow Diagram Context Diagram Request Customer Confirm- ation
Babysitter Information
System
Availability
Assignment
Employee

12. Data Flow Diagram Level 1
Request
Assignment
Availability
Confirm-
ation 1.
Assign
Employee
Avail
Times 2.
Record
Avail-
ability
New
Current
Avail
Times
Job
Assign
D1 | Customer
D2 | Employee
D3 | Jobs

13. Communications Model
A representation of the location at which data is stored and processed and the communications links that connect them.

14. Entity Relationship Models
A good E-R model has
One table for every entity in the business system
Correctly drawn relationships indicating 1-1 or 1-m cardinalities
Optionality indicators to support needed referential integrity

15. ENTITY:
A person, place, object, event, or concept about which the organization wishes to maintain data.
Must need to store data
Must have at least two attributes
Must have at least two records

16. ENTITY TYPES
classes of people, objects or concepts about which we wish to store data.
become tables in a new computer system.
Instances are rows
Attributes are columns

17. ATTRIBUTE: A description or property of a given entity type.
Must depend on the entity key alone
Must contain information that we explicitly need
Must have the same data type for all entity occurrences

18. RELATIONSHIP: .
A connection between entity instances in different entity classes
Must specify what row connects with what row in associated tables
Must not describe processing

19. LOGICAL AND PHYSICAL COMPONENTS

20. Narrative Description
The conceptual modeling process starts with a narrative description of the process. This is a direct, active depiction of what the system should do. This is the basis of the initial data and process models.

21. Discovering Entities
Entities are normally described by NOUNS and ADJECTIVES
Entities do not change anything.
Entity occurrences are records, entity types are files.
Reports are derived output and not entities.

22. Discovering Entities
Entities with only one attribute are usually modeled as attributes of another entity.
Entities that have only one record are usually modeled as a set of parameters and not as files.
Include only files (entity types) that are needed by a system. Extra entities require maintenance and space that can add considerably to the cost of a system.

23. Converting a text description into an E-R model:
1. Review the conceptual description of the business area for nouns that describe the system.
2. Each entity type should have more than one potential instance.
3. Each entity type should have more than one attribute.
4. Each entity type should be relevant..

24. DEVELOPING E-R KEYS
Attributes are properties that describe features of entity types. Attributes are usually nouns that describe properties of entity instances (like address for a customer). Attributes become fields in a database.

25. DEVELOPING E-R KEYS
Candidate keys are any attribute or combination of attributes that uniquely identify a record. The entire record is a candidate key.
A Primary Key is one candidate key. A good primary key is short and does not change over the life of the database.

26. Keys
Names are normally poor primary keys. They have multiple valid representations. Primary keys:
1. Should not change values over the life of the instance.
2. Should not have null values.
3. Should not be "intelligent keys". These are keys that also describe properties of the entity.
4. Should not be large composite keys.

27. Not null vs nulls allowed
Null values represent
inapplicable,
applicable but not known,
and applicable but not present values.
Primary keys cannot have null values.
Null values are different from zeros or blanks

28. TYPES OF ATTRIBUTES: Composite or Simple (atomic)
Single valued or Multivalued (repeating group)
Relational database models cannot represent multivalued attributes but objects and structured databases can. Repeating groups (sets of related multivalued attributes) usually represent entities or subclasses.

29. Diagrams: Attributes
Entity
Key
Attribute
Attribute

30. Diagrams: Repeating Groups
Course
SectionNum

31. E-R MODEL:
MULTI-VALUED ATTRIBUTES can be indicated on an E-R graph by using a double line around the bubble..
REPEATING GROUPS are stored differently in structured models (hierarchical or network) than in relational models.
DERIVED VALUES: cause data consistency problems and are not normally included in a database.

32. PREMIERE PRODUCTS EXAMPLE
The Premier Products Company is a wholesale hardware company that provides products to customers. Each customer is served by a salesman who processes orders. The salesmen is paid from commissions earned on each customer order. A customer places an order by calling the company and contacting the salesman. The salesman records the ordering person, products and quantity ordered.

33. PREMIERE PRODUCTS: REPEATING GROUPS
In the Premier Products Company each salesmen is paid from commissions earned on each customer order. A customer places an order by calling the company and contacting the salesman. The salesman records the ordering person, products and quantity ordered. The order consists of Customer data, Salesman data and a list of products, price, and quantity for the products that the customer wants delivered. The attributes {PRODUCT, PRICE, QUANTITY} constitute a repeating group.

34. Example: Order ORDER PRODUCT PRICE QUANTITY 5103 IRON 17.95 11
SKILLET
5110 TOASTER
IRON
Each instance of an order has several order lines. Order lines {Description, Price, Quantity} are examples of repeating groups.

35. Relationships
A relationship is a connection between records in one table and those in another.
Instructor assigned to class (section)
Student enrolled in class (section)

36. RELATIONSHIP.
Does not describe processing or change any data. Relationship names should be passive (ordered by).
CARDINALITY Refers to the number of records that a relationship connects to a given child record in a relationship.
PARTICIPATION (Optionality) Refers to whether a record must exist in one table before a related one is inserted into another.

37. Diagrams: 1:m Relationships
InstructorID
Section
CourseSection
Instructor
InstructorID

38. Diagrams: m:n Relationships
CourseSection
StudentID
Section
Student-Section
CourseSection
Student
StudentID

39. Optionality (Referential Integrity)
Records in a table that have a relationship with another table may be restricted by optionality requirements.
Relationship Optional
Relationship Mandatory (referential integrity enforced)

40. Optionality
Optional (0 allowed)
Mandatory (1 or more required) 1

41. Optionality
A constraint should be mandatory only if the relationship must be known whenever a record is first entered. Most relationships are optional.

42. Maintaining Integrity
If a parent record is deleted then an optionality relationships can be maintained in several ways
Cascade delete
Cascade update
Cascade null

43. Data