Presentation is loading. Please wait.

Presentation is loading. Please wait.

Information Access Mgt09/12/971 Entity-Relationship Design Information Level Design.

Similar presentations


Presentation on theme: "Information Access Mgt09/12/971 Entity-Relationship Design Information Level Design."— Presentation transcript:

1 Information Access Mgt09/12/971 Entity-Relationship Design Information Level Design

2 Information Access Mgt09/12/972 TOP DOWN DATA ANALYSIS – Computer systems are extremely complicated and cannot be developed without careful planning. The first step is generally to build a model of the information system based on the general objectives and goals it must meet. This is called top down modeling.

3 Information Access Mgt09/12/973 The Data Life Cycle

4 Information Access Mgt09/12/974 Data Modeling Stages

5 Information Access Mgt09/12/975 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 Information Access Mgt09/12/976 The Data Life Cycle

7 Information Access Mgt09/12/977 The Data Life Cycle

8 Information Access Mgt09/12/978 Functional Decomposition l Assign Employee Take Call Check Availability Assign to Job Contact Employee Confirm Appointment l Determine Availability

9 Information Access Mgt09/12/979 Functional-Entity Decomposition

10 Information Access Mgt09/12/9710 The Data Life Cycle

11 Information Access Mgt09/12/9711 Entity-Relationship Model A logical representation of the data of an organization or business area in graphical form

12 Information Access Mgt09/12/9712 E-R Diagram Employee Job Customer

13 Information Access Mgt09/12/9713 Data-Flow Model A logical representation of the processes and data transformation of a system or organization in graphical form

14 Information Access Mgt09/12/9714 Data Flow Diagram Context Diagram Babysitter Information System Customer Employee Request Confirm- ation Assignment Availability

15 Information Access Mgt09/12/9715 Data Flow Diagram Level 1 Request Confirm- ation 1. Assign Employee Availability 2. Record Avail- ability Assignment D1 | Customer D2 | Employee New CurrentAvail Times D3 | Jobs Job Assign Avail Times

16 Information Access Mgt09/12/9716 Communications Model A representation of the location at which data is stored and processed and the communications links that connect them.

17 Information Access Mgt09/12/9717 Entity Relationship Models l 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

18 Information Access Mgt09/12/9718 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

19 Information Access Mgt09/12/9719 ENTITY TYPES classes of people, objects or concepts about which we wish to store data. l become tables in a new computer system. l Instances are rows l Attributes are columns

20 Information Access Mgt09/12/9720 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

21 Information Access Mgt09/12/9721 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

22 Information Access Mgt09/12/9722 LOGICAL AND PHYSICAL COMPONENTS

23 Information Access Mgt09/12/9723 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.

24 Information Access Mgt09/12/9724 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.

25 Information Access Mgt09/12/9725 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..

26 Information Access Mgt09/12/9726 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.

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

28 Information Access Mgt09/12/9728 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.

29 Information Access Mgt09/12/9729 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

30 Information Access Mgt09/12/9730 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.

31 Information Access Mgt09/12/9731 Diagrams: Attributes Entity Key... Attribute

32 Information Access Mgt09/12/9732 Diagrams: Repeating Groups Course SectionNum

33 Information Access Mgt09/12/9733 E-R MODEL: Repeating attributes can be indicated on an E-R graph by using a double line around the bubble.. COMPUTER CODE: Repeating groups are stored differently in structured models (hierarchical or network) than in relational models. Derived Derived values cause data consistency problems and are not normally included in a database.

34 Information Access Mgt09/12/9734 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.

35 Information Access Mgt09/12/9735 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.

36 Information Access Mgt09/12/9736 Example: Order ORDERPRODUCTPRICEQUANTITY 5103IRON17.9511 SKILLET19.95 6 5110TOASTER57.95 4 IRON17.95 3 Each instance of an order has several order lines. Order lines {Description, Price, Quantity} are examples of repeating groups.

37 Information Access Mgt09/12/9737 Relationships A relationship is a connection between records in one table and those in another. l Instructor assigned to class (section) l Student enrolled in class (section)

38 Information Access Mgt09/12/9738 RELATIONSHIP. Does not describe processing or change any data. Relationship names should be passive (ordered by). CARDINALITYRefers 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.

39 Information Access Mgt09/12/9739 Diagrams: 1:m Relationships Section Instructor CourseSection InstructorID

40 Information Access Mgt09/12/9740 Diagrams: m:n Relationships Section Student CourseSection StudentID Student-Section CourseSection StudentID

41 Information Access Mgt09/12/9741 Optionality (Referential Integrity) Records in a table that have a relationship with another table may be restricted by optionality requirements. l Relationship Optional l Relationship Mandatory (referential integrity enforced)

42 Information Access Mgt09/12/9742 Optionality 0 1 Optional (0 allowed) Mandatory (1 or more required)

43 Information Access Mgt09/12/9743 Optionality A constraint should be mandatory only if the relationship must be known whenever a record is first entered. Most relationships are optional.

44 Information Access Mgt09/12/9744 Maintaining Integrity If a parent record is deleted then an optionality relationships can be maintained in several ways l Cascade delete l Cascade update l Cascade null

45 Information Access Mgt09/12/9745 Data


Download ppt "Information Access Mgt09/12/971 Entity-Relationship Design Information Level Design."

Similar presentations


Ads by Google