• Like
Bab 3 data modeling dan analysis 2010
Upcoming SlideShare
Loading in...5
×

Bab 3 data modeling dan analysis 2010

  • 2,319 views
Uploaded on

 

More in: Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,319
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
88
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. BAB IIIDATA MODELING dan ANALYSIS kipram 1
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Joint Application Design (JAD) Participants Session Leader Users Managers Sponsor Systems Analysts Scribe IS Staff kipram 14
  • 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. 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. 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. 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. 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. B. Structuring System Requirements: 1. Process Modeling kipram 20
  • 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. 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. 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. Figure 8-2Comparison of DeMarco & Yourdan and Gane & Sarson DFD symbol sets kipram 24
  • 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. 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. 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. 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. Figure 8-4Context diagram of Hoosier Burger’s food ordering system kipram 29
  • 30. Figure 8-5Level-0 DFD of Hoosier Burger’s food ordering system kipram 30
  • 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. 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. 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. 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. 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. 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. 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. 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. Figure 8-10An unbalanced set of data flow diagrams (a) Context diagram (b) Level-0 diagram kipram 39
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Simple Data Flow Diagram Data flow Process Data store (internal entity)External agent(entity) kipram 50
  • 51. Process Decomposition kipram 51
  • 52. Decomposition Diagrams kipram 52
  • 53. Illegal Data FlowsPractice data flow conservation – only data needed should move kipram 53
  • 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. Summary DFDs for Analysis DFDs for Business Process Reengineering (BPR) Oracle’s Process Modeler Functional Hierarchy Diagrams8.558.55 kipram 55
  • 56. 2. Logic Modeling kipram 56
  • 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. Logic ModelingDeliverables and Outcomes Structured English Decision Tables Decision Trees State-transition diagrams Sequence diagrams Activity diagrams kipram 58
  • 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. Modeling Logic with Structured EnglishSimilar to programming language If conditions Case statementsFigure 9-3 shows Structured Englishrepresentation for Hoosier Burger kipram 60
  • 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. 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. Figure 9-4Complete decision table for payroll system example kipram 63
  • 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. 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. 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. 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. 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. 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. 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. C. Conceptual Data Modeling kipram 71
  • 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. 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. 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. 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. Figure 10-3Sample conceptual data model diagram kipram 76
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Figure 10-6Example relationships of different degrees kipram 87
  • 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. 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. 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. 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. 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. 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. Triggering OperationsResponsibility for data integrity lieswithin scope of database managementsystem, not individual applications kipram 94
  • 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. SummaryProcess of conceptual data modeling Deliverables Gathering informationEntity-Relationship Modeling Entities Attributes Candidate keys and identifiers Multivalued attributesDegree of relationship kipram 96
  • 97. SummaryCardinalityNaming and defining relationshipsAssociative entitiesDomainsTriggering OperationsRole of CASE kipram 97