Bab 3 data modeling dan analysis 2010


Published on

Published in: Education, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Bab 3 data modeling dan analysis 2010

  2. 2. A. Determining System Requirements Performing Requirements Determination Gather information on what system should do from many sources Users Reports Forms Procedures kipram 2
  3. 3. Performing Requirements Determination Characteristics for gathering requirements Impertinence Question everything Impartiality Find the best organizational solution Relaxation of constraints Attention to detail Reframing View the organization in new ways kipram 3
  4. 4. Deliverables and OutcomesTypes of deliverables: Information collected from users Existing documents and files Computer-based information Understanding of organizational components Business objective Information needs Rules of data processing Key events kipram 4
  5. 5. Traditional Methods for Determining Requirements Interviewing and Listening Gather facts, opinions and speculations Observe body language and emotions Guidelines Plan Checklist Appointment Be neutral Listen Seek a diverse view kipram 5
  6. 6. Traditional Methods for Determining Requirements Interviewing (Continued) Interview Questions Open-Ended No pre-specified answers Close-Ended Respondent is asked to choose from a set of specified responses Additional Guidelines Do not phrase questions in ways that imply a wrong or right answer Listen very carefully to what is being said Type up notes within 48 hours Do not set expectations about the new system kipram 6
  7. 7. Traditional Methods for Determining Requirements Administering Questionnaires More cost-effective than interviews Choosing respondents Should be representative of all users Types of samples Convenient Random sample Purposeful sample Stratified sample kipram 7
  8. 8. Traditional Methods for Determining Requirements Questionnaires Design Mostly closed-ended questions Can be administered over the phone or in person Vs. Interviews Interviews cost more but yield more information Questionnaires are more cost-effective See table 7-4 for a complete comparison kipram 8
  9. 9. Traditional Methods for Determining Requirements Interviewing Groups Advantages More effective use of time Enables people to hear opinions of others and to agree or disagree Disadvantages Difficulty in scheduling Nominal Group Technique Facilitated process to support idea generation by groups Individuals work alone to generate ideas which are pooled under guidance of a trained facilitator kipram 9
  10. 10. Traditional Methods for Determining Requirements Directly Observing Users Serves as a good method to supplement interviews Often difficult to obtain unbiased data People often work differently when being observed kipram 10
  11. 11. Analyzing Procedures and Other DocumentsTypes of information to be discovered: Problems with existing system Opportunity to meet new need Organizational direction Names of key individuals Values of organization Special information processing circumstances Reasons for current system design Rules for processing data kipram 11
  12. 12. Analyzing Procedures and Other DocumentsFour types of useful documents Written work procedures Describes how a job is performed Includes data and information used and created in the process of performing the job or task Business form Explicitly indicate data flow in or out of a system Report Enables the analyst to work backwards from the report to the data that generated it Description of current information system kipram 12
  13. 13. Modern Methods for Determining RequirementsJoint Application Design (JAD) Brings together key users, managers and systems analysts Purpose: collect system requirements simultaneously from key people Conducted off-sitePrototyping Repetitive process Rudimentary version of system is built Replaces or augments SDLC Goal: to develop concrete specifications for ultimate system kipram 13
  14. 14. Joint Application Design (JAD) Participants Session Leader Users Managers Sponsor Systems Analysts Scribe IS Staff kipram 14
  15. 15. Joint Application Design (JAD)End Result Documentation detailing existing system Features of proposed systemCASE Tools During JAD Upper CASE tools are used Enables analysts to enter system models directly into CASE during the JAD session Screen designs and prototyping can be done during JAD and shown to usersSupporting JAD with GSS Group support systems (GSS) can be used to enable more participation by group members in JAD Members type their answers into the computer All members of the group see what other members have been typing kipram 15
  16. 16. PrototypingQuickly converts requirements to workingversion of systemOnce the user sees requirements convertedto system, will ask for modifications or willgenerate additional requestsMost useful when: User requests are not clear Few users are involved in the system Designs are complex and require concrete form History of communication problems between analysts and users Tools are readily available to build prototype kipram 16
  17. 17. PrototypingDrawbacks Tendency to avoid formal documentation Difficult to adapt to more general user audience Sharing data with other systems is often not considered Systems Development Life Cycle (SDLC) checks are often bypassed kipram 17
  18. 18. Business Process Reengineering (BPR) Search for and implementation of radical change in business processes to achieve breakthrough improvements in products and services Goals Reorganize complete flow of data in major sections of an organization Eliminate unnecessary steps Combine steps Become more responsive to future change Identification of processes to reengineer Key business processes Set of activities designed to produce specific output for a particular customer or market Focused on customers and outcome Same techniques are used as were used for requirements7.187.18 determination kipram 18
  19. 19. Business Process Reengineering (BPR)Identify specific activities that can beimproved through BPRDisruptive technologies Technologies that enable the breaking of long-held business rules that inhibit organizations from making radical business changes kipram 19
  20. 20. B. Structuring System Requirements: 1. Process Modeling kipram 20
  21. 21. Process ModelingGraphically represent the processes that capture,manipulate, store and distribute data between a systemand its environment and among system componentsData flow diagrams (DFD) Graphically illustrate movement of data between external entities and the processes and data stores within a systemModeling a system’s process Utilize information gathered during requirements determination Structure of the data is also modeled in addition to the processesDeliverables and Outcomes Set of coherent, interrelated data flow diagrams kipram 21
  22. 22. Process ModelingDeliverables and outcomes (continued) Context data flow diagram (DFD) Scope of system DFDs of current system Enables analysts to understand current system DFDs of new logical system Technology independent Show data flows, structure and functional requirements of new systemProject dictionary and CASE repository kipram 22
  23. 23. Data Flow Diagramming Mechanics Four symbols are used See Figure 8-2 Two different standard sets can be used DeMarco and Yourdan Gane and Sarson kipram 23
  24. 24. Figure 8-2Comparison of DeMarco & Yourdan and Gane & Sarson DFD symbol sets kipram 24
  25. 25. Data Flow Diagramming MechanicsData Flow Depicts data that are in motion and moving as a unit from one place to another in the system. Drawn as an arrow Select a meaningful name to represent the dataData Store Depicts data at rest May represent data in File folder Computer-based file Notebook The name of the store as well as the number are recorded in between lines kipram 25
  26. 26. Data Flow Diagramming Mechanics Process Depicts work or action performed on data so that they are transformed, stored or distributed Number of process as well as name are recorded Source/Sink Depicts the origin and/or destination of the data Sometimes referred to as an external entity Drawn as a square symbol Name states what the external agent is Because they are external, many characteristics are not of interest to us8.268.26 kipram 26
  27. 27. Data Flow Diagramming Definitions Context Diagram A data flow diagram (DFD) of the scope of an organizational system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the system Level-O Diagram A data flow diagram (DFD) that represents a system’s major processes, data flows and data stores at a high level of detail kipram 27
  28. 28. Developing DFDs: An ExampleHoosier Burger’s automated foodordering systemContext Diagram (Figure 8-4) containsno data storesNext step is to expand the contextdiagram to show the breakdown ofprocesses (Figure 8-5) kipram 28
  29. 29. Figure 8-4Context diagram of Hoosier Burger’s food ordering system kipram 29
  30. 30. Figure 8-5Level-0 DFD of Hoosier Burger’s food ordering system kipram 30
  31. 31. Data Flow Diagramming Rules Basic rules that apply to all DFDs Inputs to a process are always different than outputs Objects always have a unique name In order to keep the diagram uncluttered, you can repeat data stores and sources/sinks on a diagram kipram 31
  32. 32. Data Flow Diagramming Rules Process Data Store No process can have Data cannot be moved directly from one store to only outputs (a another miracle) Data cannot move No process can have directly from an outside only inputs (black source to a data store hole) Data cannot move directly from a data store A process has a verb to a data sink phrase label Data store has a noun phrase label kipram 32
  33. 33. Data Flow Diagramming Rules Source/Sink Data Flow Data cannot move A data flow has only one direction of flow between directly from a symbols source to a sink A fork means that exactly A source/sink has a the same data goes from noun phrase label a common location to two or more processes, data stores or sources/sinks kipram 33
  34. 34. Data Flow Diagramming Rules Data Flow (Continued) L. A join means that exactly the same data comes from any two or more different processes, data stores or sources/sinks to a common location M. A data flow cannot go directly back to the same process it leaves N. A data flow to a data store means update O. A data flow from a data store means retrieve or use P. A data flow has a noun phrase label kipram 34
  35. 35. Decomposition of DFDsFunctional decomposition Act of going from one single system to many component processes Repetitive procedure Lowest level is called a primitive DFDLevel-N Diagrams A DFD that is the result of n nested decompositions of a series of subprocesses from a process on a level-0 diagram kipram 35
  36. 36. Balancing DFDsWhen decomposing a DFD, you mustconserve inputs to and outputs from aprocess at the next level of decompositionThis is called balancingExample: Hoosier Burgers In Figure 8-4, notice that there is one input to the system, the customer order Three outputs: Customer receipt Food order Management reports kipram 36
  37. 37. Balancing DFDsExample (Continued) Notice Figure 8-5. We have the same inputs and outputs No new inputs or outputs have been introduced We can say that the context diagram and level-0 DFD are balanced kipram 37
  38. 38. Balancing DFDsAn unbalanced example Figure 8-10 In context diagram, we have one input to the system, A and one output, B Level-0 diagram has one additional data flow, C These DFDs are not balanced kipram 38
  39. 39. Figure 8-10An unbalanced set of data flow diagrams (a) Context diagram (b) Level-0 diagram kipram 39
  40. 40. Balancing DFDsWe can split a data flow into separatedata flows on a lower level diagram (seeFigure 8-11)Balancing leads to four additionaladvanced rules (See Table 8-3) kipram 40
  41. 41. Four Different Types of DFDS Current Physical Process label includes an identification of the technology (people or systems) used to process the data Data flows and data stores are labeled with the actual name of the physical media on which data flow or in which data are stored kipram 41
  42. 42. Four Different Types of DFDSCurrent Logical Physical aspects of system are removed as much as possible Current system is reduced to data and processes that transform themNew Logical Includes additional functions Obsolete functions are removed Inefficient data flows are reorganizedNew Physical Represents the physical implementation of the new system kipram 42
  43. 43. Guidelines for Drawing DFDs Completeness DFD must include all components necessary for system Each component must be fully described in the project dictionary or CASE repository Consistency The extent to which information contained on one level of a set of nested DFDs is also included on other levels kipram 43
  44. 44. Guidelines for Drawing DFDsTiming Time is not represented well on DFDs Best to draw DFDs as if the system has never started and will never stop.Iterative Development Analyst should expect to redraw diagram several times before reaching the closest approximation to the system being modeledPrimitive DFDs Lowest logical level of decomposition Decision has to be made when to stop decomposition kipram 44
  45. 45. Guidelines for Drawing DFDs Rules for stopping decomposition When each process has been reduced to a single decision, calculation or database operation When each data store represents data about a single entity When the system user does not care to see any more detail kipram 45
  46. 46. Guidelines for Drawing DFDs Rules for stopping decomposition (continued) When every data flow does not need to be split further to show that data are handled in various ways When you believe that you have shown each business form or transaction, on-line display and report as a single data flow When you believe that there is a separate process for each choice on all lowest-level menu options kipram 46
  47. 47. Using DFDs as Analysis Tools Gap Analysis The process of discovering discrepancies between two or more sets of data flow diagrams or discrepancies within a single DFD Inefficiencies in a system can often be identified through DFDs kipram 47
  48. 48. Using DFDs in Business Process ReengineeringExample: IBM Credit See Figure 8-20 – before reengineering Credit approval process required six days before BPR Figure 8-21 depicts DFD after reengineering IBM was able to process 100 times the number of transactions in the same amount of time kipram 48
  49. 49. Oracle’s Process Modeler and Functional Hierarchy DiagramsProcess Modeler Unique to Oracle Similar to DFDS but outputs and methods differ in several ways. Table 8-4 illustrates differencesFunctional Hierarchy Diagrams Picture of various tasks performed in a business and how they are related Tasks are broken down into their various parts Does not include data flows kipram 49
  50. 50. Simple Data Flow Diagram Data flow Process Data store (internal entity)External agent(entity) kipram 50
  51. 51. Process Decomposition kipram 51
  52. 52. Decomposition Diagrams kipram 52
  53. 53. Illegal Data FlowsPractice data flow conservation – only data needed should move kipram 53
  54. 54. SummaryData flow diagrams (DFD) Symbols Rules for creating Decomposition BalancingFour different kinds of DFDs Current Physical Current Logical New Logical New Physical kipram 54
  55. 55. Summary DFDs for Analysis DFDs for Business Process Reengineering (BPR) Oracle’s Process Modeler Functional Hierarchy Diagrams8.558.55 kipram 55
  56. 56. 2. Logic Modeling kipram 56
  57. 57. Logic ModelingData flow diagrams do not show thelogic inside the processesLogic modeling involves representinginternal structure and functionality ofprocesses depicted on a DFDLogic modeling can also be used toshow when processes on a DFD occur kipram 57
  58. 58. Logic ModelingDeliverables and Outcomes Structured English Decision Tables Decision Trees State-transition diagrams Sequence diagrams Activity diagrams kipram 58
  59. 59. Modeling Logic with Structured EnglishModified form of English used to specifythe logic of information processesUses a subset of English Action verbs Noun phrases No adjectives or adverbsNo specific standards kipram 59
  60. 60. Modeling Logic with Structured EnglishSimilar to programming language If conditions Case statementsFigure 9-3 shows Structured Englishrepresentation for Hoosier Burger kipram 60
  61. 61. Modeling Logic with Decision TablesA matrix representation of the logic of a decisionSpecifies the possible conditions and the resultingactionsBest used for complicated decision logicConsists of three parts Condition stubs Lists condition relevant to decision Action stubs Actions that result from a given set of conditions Rules Specify which actions are to be followed for a given set of conditions kipram 61
  62. 62. Modeling Logic with Decision TablesIndifferent Condition Condition whose value does not affect which action is taken for two or more rulesStandard procedure for creating decisiontables Name the condition and values each condition can assume Name all possible actions that can occur List all rules Define the actions for each rule Simplify the table kipram 62
  63. 63. Figure 9-4Complete decision table for payroll system example kipram 63
  64. 64. Modeling Logic with Decision Trees A graphical representation of a decision situation Decision situation points are connected together by arcs and terminate in ovals Two main components Decision points represented by nodes Actions represented by ovals kipram 64
  65. 65. Modeling Logic with Decision Trees Read from left to right Each node corresponds to a numbered choice on a legend All possible actions are listed on the far right kipram 65
  66. 66. Figure 9-9Decision tree representation of the decision logic in the decisiontables in Figures 9-4 and 9-5, with only two choices per decision point kipram 66
  67. 67. Deciding Among Structured English,Decision Tables and Decision TreesCriteria Structured Decision Decision English Tables TreesDetermining Second Best Third Best BestConditions andActionsTransforming Best Third Best BestConditions andActions intoSequenceChecking Third Best Best BestConsistencyandCompleteness kipram 67
  68. 68. SummarySeveral methods of logic modeling Structured English Primarily communication technique for analysts and users Decision Tables Conditions are listed in condition stubs Possible actions are listed in action stubs Rules link conditions with actions kipram 68
  69. 69. SummaryDecision Tables Lists all possible rulesDecision Trees Conditions are portrayed by decision points Values are represented by paths between decision points and ovals that contain actions kipram 69
  70. 70. SummaryComparison of Structured English,Decision Tables and Decision Trees Most studies show that decision trees are best for many criteria There is no best technique Analyst must be proficient in all three kipram 70
  71. 71. C. Conceptual Data Modeling kipram 71
  72. 72. Learning ObjectivesDefine key data modeling terms Entity type Attribute Multivalued attribute Relationship Degree Cardinality Business Rule Associative entity Trigger Supertype Subtype kipram 72
  73. 73. Conceptual Data ModelingRepresentation of organizational dataPurpose is to show rules about the meaning andinterrelationships among dataEntity-Relationship (E-R) diagrams are commonlyused to show how data are organizedMain goal of conceptual data modeling is to createaccurate E-R diagramsMethods such as interviewing, questionnaires andJAD are used to collect informationConsistency must be maintained between processflow, decision logic and data modeling descriptions kipram 73
  74. 74. Process of Conceptual Data ModelingFirst step is to develop a data model for thesystem being replacedNext, a new conceptual data model is builtthat includes all the requirements of the newsystemIn the design stage, the conceptual datamodel is translated into a physical designProject repository links all design and datamodeling steps performed during SDLC kipram 74
  75. 75. Deliverables and OutcomePrimary deliverable is the entity-relationshipdiagramThere may be as many as 4 E-R diagramsproduced and analyzed during conceptualdata modeling Covers just data needed in the project’s application E-R diagram for system being replaced An E-R diagram for the whole database from which the new application’s data are extracted An E-R diagram for the whole database from which data for the application system being replaced is drawn kipram 75
  76. 76. Figure 10-3Sample conceptual data model diagram kipram 76
  77. 77. Deliverables and OutcomeSecond deliverable is a set of entries aboutdata objects to be stored in repository orproject dictionary Repository links data, process and logic models of an information system Data elements that are included in the DFD must appear in the data model and visa versa Each data store in a process model must relate to business objects represented in the data model kipram 77
  78. 78. Gathering Information for Conceptual Data Modeling Two perspectives Top-down Data model is derived from an intimate understanding of the business Bottom-up Data model is derived by reviewing specifications and business documents kipram 78
  79. 79. Introduction to Entity-Relationship (E-R) Modeling Notation uses three main constructs Data entities Relationships Attributes Entity-Relationship (E-R) Diagram A detailed, logical representation of the entities, associations and data elements for an organization or business kipram 79
  80. 80. Entity-Relationship (E-R) ModelingEntity Key Terms A person, place, object, event or concept in the user environment about which the organization wishes to maintain data Represented by a rectangle in E-R diagramsEntity Type A collection of entities that share common properties or characteristicsAttribute A named property or characteristic of an entity that is of interest to an organization kipram 80
  81. 81. Entity-Relationship (E-R) Modeling Key Terms Candidate keys and identifiers Each entity type must have an attribute or set of attributes that distinguishes one instance from other instances of the same type Candidate key Attribute (or combination of attributes) that uniquely identifies each instance of an entity type kipram 81
  82. 82. Entity-Relationship (E-R) Modeling Key Terms Identifier A candidate key that has been selected as the unique identifying characteristic for an entity type Selection rules for an identifier 1. Choose a candidate key that will not change its value 2. Choose a candidate key that will never be null 3. Avoid using intelligent keys 4. Consider substituting single value surrogate keys for large composite keys kipram 82
  83. 83. Entity-Relationship (E-R) Modeling Key TermsMultivalued Attribute An attribute that may take on more than one value for each entity instance Represented on E-R Diagram in two ways: double-lined ellipse weak entity kipram 83
  84. 84. Entity-Relationship (E-R) Modeling Relationship Key Terms An association between the instances of one or more entity types that is of interest to the organization Association indicates that an event has occurred or that there is a natural link between entity types Relationships are always labeled with verb phrases kipram 84
  85. 85. Conceptual Data Modeling and the E-R Diagram Goal Capture as much of the meaning of the data as possible Result A better design that is easier to maintain kipram 85
  86. 86. Degree of Relationship Degree Number of entity types that participate in a relationship Three cases Unary A relationship between two instances of one entity type Binary A relationship between the instances of two entity types Ternary A simultaneous relationship among the instances of three entity types Not the same as three binary relationships10.8610.86 kipram 86
  87. 87. Figure 10-6Example relationships of different degrees kipram 87
  88. 88. CardinalityThe number of instances of entity B that canbe associated with each instance of entity AMinimum Cardinality The minimum number of instances of entity B that may be associated with each instance of entity AMaximum Cardinality The maximum number of instances of entity B that may be associated with each instance of entity A kipram 88
  89. 89. Naming and Defining Relationships Relationship name is a verb phrase Avoid vague names Guidelines for defining relationships Definition explains what action is being taken and why it is important Give examples to clarify the action Optional participation should be explained Explain reasons for any explicit maximum cardinality10.8910.89 kipram 89
  90. 90. Naming and Defining Relationships Guidelines for defining relationships Explain any restrictions on participation in the relationship Explain extent of the history that is kept in the relationship Explain whether an entity instance involved in a relationship instance can transfer participation to another relationship instance kipram 90
  91. 91. 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 instances10.9110.91 kipram 91
  92. 92. Domains The set of all data types and ranges of values that an attribute can assume Several advantages1. Verify that the values for an attribute are valid2. Ensure that various data manipulation operations are logical3. Help conserve effort in describing attribute characteristics kipram 92
  93. 93. Triggering OperationsAn assertion or rule that governs the validity of datamanipulation operations such as insert, update and deleteIncludes the following components: User rule Statement of the business rule to be enforced by the trigger Event Data manipulation operation that initiates the operation Entity Name Name of entity being accessed or modified Condition Condition that causes the operation to be triggered Action Action taken when the operation is triggered kipram 93
  94. 94. Triggering OperationsResponsibility for data integrity lieswithin scope of database managementsystem, not individual applications kipram 94
  95. 95. The Role of CASE in Conceptual Data CASE tools provide two important functions: Maintain E-R diagrams as a visual depiction of structured data requirements Link objects on E-R diagrams to corresponding descriptions in a repository kipram 95
  96. 96. SummaryProcess of conceptual data modeling Deliverables Gathering informationEntity-Relationship Modeling Entities Attributes Candidate keys and identifiers Multivalued attributesDegree of relationship kipram 96
  97. 97. SummaryCardinalityNaming and defining relationshipsAssociative entitiesDomainsTriggering OperationsRole of CASE kipram 97