Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Systems Analysis & Design Data Modeling IS 431: Lecture 5 CSUN Information Systems

Similar presentations


Presentation on theme: "1 Systems Analysis & Design Data Modeling IS 431: Lecture 5 CSUN Information Systems"— Presentation transcript:

1 1 Systems Analysis & Design Data Modeling IS 431: Lecture 5 CSUN Information Systems

2 IS 431 : Lecture 5 2 Data Modeling  Elements of Entity Relationship Diagram (ERD)  Relational Data Model

3 IS 431 : Lecture 5 3 Data Modeling Data Modeling (database modeling, information modeling) is a technique for organizing and documenting a system’s data in a model. Entity Relationship Diagram (ERD) depicts data in terms of the entities and relationships described by the data.

4 IS 431 : Lecture 5 4 From Data Model to DB Implementation ERD: a conceptual model of data entities (things of interest), their attributes (characteristics of interest), and their relationships (with other things) in an information system (technical independent).(Analysis) Relational Data Model: a blueprint for implementation of a conceptual data model (ERD) in relational database environment (software independent)(Design) MS Access Relationship Window: a graph showing how a data model is implemented with Microsoft Access (a specific DBMS software)(Implementation)

5 IS 431 : Lecture 5 5 Entity-Relationship Diagrams Database = data + relationship ERD is used to model data and their relationship ERD is a graphical representation of a conceptual data model ERD is resource independent: it does not commit to any particular database environment.

6 IS 431 : Lecture 5 6 Entities Entity is a group of attributes corresponding to the same conceptual object about which we need to capture and store data –objects, persons, places, events concepts whose existence is not dependent on many other entities Entity is a set of occurrences (instances) of the object that it represents Entity must have a unique name (a singular noun), unique identifier, and at least one attribute (the identifier itself)

7 IS 431 : Lecture 5 7  Persons: agency, contractor, customer, department, division, employee, instructor, student, supplier.  Places: sales region, building, room, branch office, campus.  Objects: book, machine, part, product, raw material, software license, software package, tool, vehicle model, vehicle.  Events: application, award, cancellation, class, flight, invoice, order, registration, renewal, requisition, reservation, sale, trip.  Concepts: account, block of time, bond, course, fund, qualification, stock. Entities: Examples

8 IS 431 : Lecture 5 8 Entity Instance: Example Entity instance – a single occurrence of an entity. Student IDLast NameFirst Name 2144ArnoldBetty 3122TaylorJohn 3843SimmonsLisa 9844MacyBill 2837LeathHeather 2293WrenchTim Entity Instances Attributes

9 IS 431 : Lecture 5 9 Entities: Attributes An attribute is a descriptive property or characteristic of interest of an entity. Also called element, property, and field. The data type for an attribute defines what type of data can be stored in that attribute. The domain of an attribute defines what values an attribute can legitimately take on. The default value for an attribute is the value that will be recorded if not specified by the user.

10 IS 431 : Lecture 5 10 Data Type Representative Logical Data Types for Attributes Logical Data Type Logical Business Meaning NUMBERAny number, real or integer. TEXTA string of characters, inclusive of numbers. When numbers are included in a TEXT attribute, it means that we do not expect to perform arithmetic or comparisons with those numbers. MEMOSame as TEXT but of an indeterminate size. Some business systems require the ability to attach potentially lengthy notes to a give database record. DATEAny date in any format. TIMEAny time in any format. YES/NOAn attribute that can assume only one of these two values. VALUE SETA finite set of values. In most cases, a coding scheme would be established (e.g., FR=Freshman, SO=Sophomore, JR=Junior, SR=Senior). IMAGEAny picture or image.

11 IS 431 : Lecture 5 11 Data Domains Representative Logical Domains for Logical Data Types Data TypeDomainExamples NUMBERFor integers, specify the range. For real numbers, specify the range and precision. {10-99} { } TEXTMaximum size of attribute. Actual values are usually infinite; however, users may specify certain narrative restrictions. Text(30) DATEVariation on the MMDDYYYY format.MMDDYYYY MMYYYY TIMEFor AM/PM times: HHMMT For military (24-hour times): HHMM HHMMT HHMM YES/NO{YES, NO}{YES, NO} {ON, OFF} VALUE SET {value#1, value#2,…value#n} {table of codes and meanings} {M=Male F=Female}

12 IS 431 : Lecture 5 12 Entities: Identification  A key is an attribute, or a group of attributes, that assumes a unique value for each entity instance.  A group of attributes that uniquely identifies an instance of an entity is called a composite (or concatenated) key.  A candidate key is a “candidate to become the primary key” of instances of an entity. (StudentID, SSN, DriverLicenseNo)  A primary key (identifier) is that candidate key that will most commonly be used to uniquely identify a single entity instance. (StudentID)  Any candidate key that is not selected to become the primary key is called an alternate key. (SSN, DriverLicenseNo)  A secondary key is an attribute whose values divide all entity instances into useful subgroups/sub-criteria. (Major, Gender, etc)

13 IS 431 : Lecture 5 13 Entities... ENTITY NAME - entity id - attribute 1 - attribute 2 - ………….. - attribute n CUSTOMER - Customer_ID - Cust_Name - Cust_Address - Cust_Phone

14 IS 431 : Lecture 5 14 Relationships A Relationship documents an association between one, two, or more entities It must have a name (and may carry data) Degree of Relationship (number of entities) Cardinalities of Relationship (number of instances/members)

15 IS 431 : Lecture 5 15 Relationships: Degree Degree of Relationship defines how many entities are involved in a relationship: –Recursive (Unary) –Binary –Ternary – ….

16 IS 431 : Lecture 5 16 Relationships: Cardinalities Cardinalities document how many occurrences/members of one entity can relate to a single occurrence/member of another entity in a relationship. Max / Min number of occurrences Reflect business policies or general business practices (e.g., how many classes a student can take, how many students a class can hold). StudentClassTake (15, 35) (1, 5)

17 IS 431 : Lecture 5 17 Cardinalities... SalesPay Cash Collections One-to-One (1:1) Relationship 11 One-to-Many (1:M) Relationship Ex: Cash Sales Sales Cash Collections Pay 1 M Ex: Installment Payments

18 IS 431 : Lecture 5 18 Cardinalities... SalesPay Cash Collections Many-to-One (M:1) Relationship M1 Many-to-Many (M:N) Relationship Ex: Pay many credit purchases in full Sales Cash Collections Pay M N Ex:Pay credit purchases with partial payments over some months

19 IS 431 : Lecture 5 19 Cardinalities... Maximum / Minimum Cardinality EmployeeSkillPossess (0,E)(1,S) EmployeeProjectBelong (1,E)(0,P) An employee must have minimum one skill A particular skill may not be possessed by any employee A project must have minimum one employee A particular employee may not belong to any project

20 IS 431 : Lecture 5 20 Relationships... Recursive relationships involve only one entity (occurrences in the same entity) ENTITY - entityID - attribute 1 - attribute 2 Relationship Name Attrib 1, Attrib 2 TOWN -TownID -Town_Name TRAVEL Distance N M N M

21 IS 431 : Lecture 5 21 Relationships... Binary relationship ENTITY 1 -entity1_ID -attribute 11 -attribute 12 ENTITY 2 -entity2_ID -attribute 21 -attribute 22 EMPLOYEE - Emp_ID - Emp_Name - Emp_Title PROJECT - Project_ID - Proj_Name - Proj_Due Relationship Name Attrib 1, Attrib 2 Manage Date MN MN

22 IS 431 : Lecture 5 22 Relationships... Ternary relationship EMPLOYEE - EmpID - Emp_Name - Emp_Title TASK - TaskID - TaskName Assign Date M N PROJECT - ProjectID - Proj_Name - Proj_Due P

23 IS 431 : Lecture 5 23 Logical Data Modeling Stages 1.Context Data model –To establish project scope 2.Key-base data model –Eliminate nonspecific relationships –Add associative entities –Include primary and alternate keys –Precise cardinalities 3.Fully attributed data model –All remaining attributes –Subsetting criteria 4.Normalized data model

24 IS 431 : Lecture 5 24 What is a Good Data Model? A good data model is simple. –Data attributes that describe any given entity should describe only that entity. –Each attribute of an entity instance can have only one value. A good data model is essentially non redundant. –Each data attribute, other than foreign keys, describes at most one entity. –Look for the same attribute recorded more than once under different names. A good data model should be flexible and adaptable to future needs.

25 IS 431 : Lecture 5 25 Building ERD Identify entities of interest (Use REAL framework – Resources/Event/Agents/Locations – more in Lecture 5B) – (Top Down) Identify all the attributes with sufficient details (context specific) Assign attributes to entities – (Bottom Up) Identify degrees of relationships between entities (context specific) Complete the relationships with cardinalities (context specific) Build the model

26 IS 431 : Lecture 5 26 Rules in ERD Building Each entity must have a name Each entity must have an identifier An occurrence itself cannot be an entity (a constant or a table with one unique record?) Each relationship must have a name (may or may not carry data) Reasonable cardinalities (context specific)

27 IS 431 : Lecture 5 27 Alternative ERD Notations Entity 1 Attribute 1Attribute 2 Attribute 3 Attribute 4Attribute 5 Entity 2 Attribute 1 Attribute 2 Attribute 3Attribute 4 relates to is related to

28 IS 431 : Lecture 5 28 Alternative ERD Notations Entity M 0 M 1 (0, * ) Entity (1, * ) Entity (1, 1) Entity (0, 1)

29 IS 431 : Lecture 5 29 Associative Entity An associative entity is an entity that inherits its primary key from more than one other entity (called parents). Each part of that composite (concatenated) key points to one and only one instance of each of the connecting entities. Represent an M:N relationship carrying data EMPLOYEE - Emp_ID - Emp_Name - Emp_Title PROJECT - Project_ID - Proj_Name - Proj_Due ASSIGN Date MN 11

30 IS 431 : Lecture 5 30 M:N Relationship vs. Associative Entity EMPLOYEE - Emp_ID - Emp_Name - Emp_Title PROJECT - Project_ID - Proj_Name - Proj_Due MN11 EMPLOYEE - Emp_ID - Emp_Name - Emp_Title PROJECT - Project_ID - Proj_Name - Proj_Due ASSIGN Date MN ASSIGNMENT - Emp_ID - Proj_ID - Date

31 IS 431 : Lecture 5 31 Foreign Keys in Relational Database A foreign key (FK) in Entity E1(CustID in ORDER) is a primary key of another Entity E2 (CustID in CUSTOMER), which is used to identify (link) a 1:M relationship between E1 and E2 (CUSTOMER and ORDER). Foreign key is made on the many side (CUSTOMER has many ORDERS, therefore ORDER carries CustID as FK to show which Customer places that Order)

32 IS 431 : Lecture 5 32 Foreign Key CUSTOMERORDER CUSTOMER CustomerID ORDER OrderID CustomerID Primary Key Foreign Key 1:M Relationship

33 IS 431 : Lecture 5 33 Foreign Keys in Relational Database... In M:N relationship, the associative/junction table with a composite key will be used to capture the relationship. – ORDER involved many PRODUCTS, PRODUCT involved in many ORDERS. Composite key ProductID-OrderID for LINE ITEM to indicate which product involves in which sales Each part of the composite key serves like a foreign key. Sometimes, a “surrogate” key (RecordNo) is used as primary key to simplify the identification of record.

34 IS 431 : Lecture 5 34 Composite Key ORDERPRODUCT LINE_ITEM RecordNo OrderID ProductID ORDER OrderID Primary Key M:N Relationship PRODUCT ProductID Composite Key JUNCTION TABLE

35 IS 431 : Lecture 5 35 ERD Case Studies ERD 1: Group Consultants Database ERD 2: Video Rental Database ERD 3: Health Club Database ERD 4: Music Store Database to be discussed in class

36 IS 431 : Lecture 5 36 Convert ERD to Relational Data Model Legend – E1, E2, E3, … represent entities – a1, a2, a3, …, b1, b2, b3, … represent entity attributes – R represents a relationship – r represents one or many attributes that can be carried by a relationship

37 IS 431 : Lecture 5 37 Pattern # 1 E1 - a1 - a2 TASK - TaskID - TaskName E1( a1, a2 ) TASK( TaskID, TaskName ) Convert ERD to Relational Data Model …

38 IS 431 : Lecture 5 38 Pattern # 2 E1 - a1 - a2 INDIVIDUAL - SSN - Name E1( a1, a2 ) R( a1, a1’, r) INDIVIDUAL ( SSN, Name) MARRY ( SSN, SSN’, Date) R r MARRY Date Husband Wife Convert ERD to Relational Data Model …

39 IS 431 : Lecture 5 39 Pattern # 3 E1 - a1 - a2 INDIVIDUAL - SSN - Name E1( a1, a2 ) R( a1’, a1 ) INDIVIDUAL ( SSN, Name) LEAD ( SSN’, SSN ) R LEAD 1 M 1 M Member Leader Convert ERD to Relational Data Model …

40 IS 431 : Lecture 5 40 Pattern # 4 E1 - a1 - a2 TOWN - TownID - Name E1( a1, a2 ) R( a1, a1’, r) TOWN ( TownID, Name) TOUR ( TownID, TownID’, Date ) R Tour M N M N Date r Convert ERD to Relational Data Model …

41 IS 431 : Lecture 5 41 Pattern # 5 E1 - a1 - a2 E1( a1, a2 ) E2( b1, b2, b3, a1) R 1 1 E2 - b1 - b2 - b3 E1( a1, a2, b1 ) E2( b1, b2, b3 ) OR EMPLOYEE - EmpID - EmpName PROJECT - ProID - ProName - ProDue 11 EMPLOYEE(EmpID, EmpName) PROJECT(ProID, ProName, ProDue, EmpID) EMPLOYEE(EmpID, EmpName, ProID) PROJECT(ProID, ProName, ProDue ) OR MANAGE Convert ERD to Relational Data Model …

42 IS 431 : Lecture 5 42 Pattern # 6 E1 - a1 - a2 E1( a1, a2 ) E2( b1, b2, b3, a1) R 1 M E2 - b1 - b2 - b3 CUSTOMER - CustID - CustName PURCHASE - PurchID - Item - Quantity 1 CUSTOMER (CustID, CustName) PURCHASE(PurchID, Item, Quantity, CustID) INVOLVE M Convert ERD to Relational Data Model …

43 IS 431 : Lecture 5 43 Pattern # 7 E1 - a1 - a2 E1( a1, a2 ) E2( b1, b2, b3) R( a1, b1, r) R M N E2 - b1 - b2 - b3 CUSTOMER - CustID - CustName SALESREP - RepID - RepName M CUSTOMER (CustID, CustName) SALESREP (RepID, RepName) SALE(CustID, RepID, Date) SALE N r Date Convert ERD to Relational Data Model …

44 IS 431 : Lecture 5 44 Pattern # 8 E1 - a1 - a2 E1( a1, a2 ) E2( b1, b2, b3) E3( c1, c2, c3 ) R( b1, c1, a1, r) R 1 N E2 - b1 - b2 - b3 E3 - c1 - c2 - c3 r P Convert ERD to Relational Data Model …

45 IS 431 : Lecture 5 45 Pattern # 8 (example) EXECUTIVE - ExecID - ExecName EXECUTIVE( ExecID, ExecName) DEPT( DeptID, DeptName) PROJECT (ProjectID) RESPONSIBLE (DeptID, ProjectID, ExecID, AppointDate ) RESPONSIBLE 1 N DEPT - DeptID - DeptName PROJECT - ProjectID AppointDate P Convert ERD to Relational Data Model …

46 IS 431 : Lecture 5 46 Pattern # 9 E1 - a1 - a2 E1( a1, a2 ) E2( b1, b2, b3) E3( c1, c2, c3 ) R(a1, b1, c1, r) R M N E2 - b1 - b2 - b3 E3 - c1 - c2 - c3 r P Convert ERD to Relational Data Model …

47 IS 431 : Lecture 5 47 Pattern # 9 (example) EMPLOYEE - EmpID - EmpName EMPLOYEE( EmpID, EmpName ) TASK( TaskID) PROJECT( ProjectID) ASSIGN(EmpID, TaskID, ProjectID, Date) ASSIGN M N TASK - TaskID PROJECT - ProjectID Date P Convert ERD to Relational Data Model …

48 IS 431 : Lecture 5 48 Generalization Generalization is a technique wherein the attributes that are common to several types of an entity are grouped into their own entity, called a supertype. An entity supertype is an entity whose instances store attributes that are common to one or more entity subtypes. An entity subtype is an entity whose instances inherit some common attributes from an entity supertype and then add other attributes that are unique to an instance of the subtype.

49 IS 431 : Lecture 5 49 Type & Subtypes Employee Name DOB SSN DateHire Executive Position Location DateAppoint Salary Foreperson Factory Station DateAppoint Wage Rate Worker Rank Wage Rate

50 IS 431 : Lecture 5 50 Generalization Hierarchy

51 IS 431 : Lecture 5 51 Data Analysis & Normalization Data analysis is a process that prepares a data model for implementation as a simple, non-redundant, flexible, and adaptable database. The specific technique is called normalization. Normalization is a technique to organize data attributes such that they are grouped to form non- redundant, stable, flexible, and adaptive entities.

52 IS 431 : Lecture 5 52 Normalization (in Latin) First normal form (1NF) – an entity whose attributes have no more than one value for a single instance of that entity –Any attributes that can have multiple values actually describe a separate entity, possibly an entity and relationship. Second normal form (2NF) – an entity whose nonprimary-key attributes are dependent on the full primary key. –Any nonkey attributes that are dependent on only part of the primary key should be moved to any entity where that partial key is actually the full key. This may require creating a new entity and relationship on the model. Third normal form (3NF) – an entity whose nonprimary-key attributes are not dependent on any other non-primary key attributes. –Any nonkey attributes that are dependent on other nonkey attributes must be moved or deleted. Again, new entities and relationships may have to be added to the data model.

53 IS 431 : Lecture 5 53 Normalization (in Plain English !!!) First normal form (1NF) : –No repeating group of a same attribute (multi-valued attribute) –If not: create a new record / entity for this group. Second normal form (2NF) –Attributes should depend on the whole (composite) key, not part of it (partial functional dependency). –If not: create a new entity for these partial depended attributes Third normal form (3NF) –Attributes should depend on the (primary) key only, not on each other (transitive dependency) –If not: create new entity for these partial depended attributes

54 Un-normalized Relation IS 431 : Lecture 5 54 Observation: Repeating groups / multi-value attributes !!!

55 Relation in 1NF IS 431 : Lecture 5 55 Observation: Attributes still depend on a part of the key !!!

56 Relations in 2NF IS 431 : Lecture 5 56 Observation: Attributes still depend on a non-key attribute !!!

57 Relations in 3NF IS 431 : Lecture 5 57 Observation: Now each table stores data about one thing only.

58 Example of Relational Database IS 431 : Lecture 5 58

59 Example of Relational Database... IS 431 : Lecture 5 59

60 IS 431 : Lecture 5 60 Data Dictionary EMPLOYEE AttributesTypeSizeDescriptionAuthorization EmpIDNumeric6IdentifierHR Manager EmpFirstNameText10Employee First NameHR Manager EmpLastNameText10Employee Last NameHR Manager AddressText50Employee AddressHR Manager CityText10Employee CityHR Manager StateText2Employee Last NameHR Manager ZipTextXXXXXEmployee Last NameHR Manager PhoneTextXXX-XXX-XXXXEmployee Last NameHR Manager Date HiredDateMM/DD/YYDate Hired EmployeeHR Manager PositionText15Position of EmployeeHR Manager EXPENSES AttributesTypesSizeDescriptionAuthorization EntryNumberNumeric6IdentifierProject Manager EntryDateDateMM/DD/YYDate of EntryProject Manager HoursWorkedNumeric3Hours on TaskProject Manager HotelExpenseCurrency4Fund Spent on HotelProject Manager TravelExpenseCurrency4Fund Spent on TravelProject Manager FoodExpenseCurrency4Fund Spent on FoodProject Manager ApprovedY/N1Approved / Not YetProject Manager

61 IS 431 : Lecture 4 61 Data to Process Matrix

62 IS 431 : Lecture 5 62 Data-to-Location CRUD Matrix


Download ppt "1 Systems Analysis & Design Data Modeling IS 431: Lecture 5 CSUN Information Systems"

Similar presentations


Ads by Google