1 / 37

Business Process Modeling

Business Process Modeling. What is a process model? A formal way of representing how a business system operates. Illustrates the activities that are performed and how data moves through the process. A process model can be used to document current system or to illustrate new system

emilie
Download Presentation

Business Process Modeling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Business Process Modeling • What is a process model? • A formal way of representing how a business system operates. • Illustrates the activities that are performed and how data moves through the process. • A process model can be used to document current system or to illustrate new system • Use Cases and Data Flow Diagrams (DFD) are among many techniques to support Business Process Modeling

  2. Week 7 Agenda • What’s new in technology? • A couple of ‘Interesting’ Questions • Lecture Material • Data Modeling • Entity-Relationship Diagrams • Normalizing Data • Summary – where we are • NOTE: No tutorials next week (midterm)

  3. The Systems Development Life Cycle (SDLC) Project Identification & Selection Project Initiation & Planning Process Model Data Structure Logic Modeling Analysis Logical Design Physical Design Implementation Maintenance

  4. Data Modeling Context • DFDs and Logic Modeling • show how, where and when data is used • Data Modeling • shows data definition, structure & relationships • Importance • crucial information for the design phase • data is often more complex than processes • data has reasonably permanent characteristics

  5. Data Models • A data model shows the people, places, and things of interest to an organization and the relationships among them. • The logical data model is an abstraction. Once again, it shows the organization of data without indicating how it is stored, created, or manipulated.

  6. Data Models • A physical data model shows how the data will actually be stored in the database. • Normalization is the process analysts use to check for data redundancy.

  7. Conceptual Data Modeling • What is it? • Captures the structure of organizational data • Is independent of a DBMS or implementation • When is it used? • Conceptual Data Modeling is during analysis • Other data modeling is done throughout SDLC • What form does it take? • Entity Relationship Diagrams (ERDs)

  8. Basic ERD Symbols (IDEF1X) Entity-Name Identifier Attribute-name Attribute-name Attribute-name Relationship-name

  9. A Note • There are several different notations for ERD’s. • none are the de facto standard • we will look at commonalities

  10. Entities • A person, place, object, event or concept that you want to maintain data about • e.g., Customer, Product, Sale, Course, etc. • entities are named with a noun • represented by a rectangle Place Entity Name Here

  11. Figuring Out What Entities to Use • Top Down Modeling • Asking Questions • Determining Business Rules “What things do we care about, in that we need to store them in our data base to perform business operations?” • persons • places • objects • events • concepts

  12. Figuring Out What Entities to Use • Bottom-Up Modeling • looking at forms and reports required in the system • identifying entities from DFD’s

  13. Entity Types and Instances(aka: distinctions modelers make to keep you confused) • Entity Type (or class) refers to a collection of entities that share common properties • e.g. The entity “student” may have two entity types, graduate and undergraduate student • Entity Instance refers to a single unique object within an entity type • e.g., Employee is an entity, customer service representative (CSR) is an entity type, and the CSR named ‘Carl’ is an entity instance.

  14. Attributes A named characteristic of an entity that is of interest to the organization or application e.g., Customer #, Customer Address, etc. Attributes are listed under the entity name attributes are named with nouns Customer C_lastname C_firstname C_telephone

  15. Attributes that are Keys • A key is an attribute that uniquely identifies every instance of an entity type. • Candidate keys are one or more attributes that uniquely identify every entity instance • Primary key - the candidate key that is chosen as the unique identifier for every instance of the entity type. • choose stable, non null, and simple attributes • primary keys are marked with an asterisk in the diagram

  16. Candidate Keys and Identifiers • Title and Copy could uniquely identify a single physical DVD. • It would probably be better to choose a Movie_Serial_Number for each specific DVD so we could keep the key to one attribute (could include mnemonics like the first word and a number:Avengers01)

  17. Relationships • The link that combines entity types. • More formally, a relationship is an association between instances of one or more entity types • labeled with verb phases - one or two • may be represented as a diamond or not shown at all on the diagram to avoid clutter

  18. Relationships • Relationships typically represent a transaction of the organization Rent Members DVDs 1 0 0

  19. Relationship Types: Cardinality One to One One to Many Many to Many Assigned Employee Parking Space 1 1 Owns Student Textbooks 1 N Takes Student Classes N N

  20. Relationship Types: Modality Optional: Rent Members DVDs 1 0 0

  21. More on ERD Concepts • Degrees of Relationships • Cardinality • Many to many relationships

  22. Relationships - Cardinalities The number of instances of entity A that can be associated with instances of entity B For example: Owns Student Textbooks 1 N Cardinalities Takes Student Classes N N

  23. Cardinality - Mandatory The crow’s foot indicates many This line indicates mandatory (at least one must exist) One Many Example: Patient has Patient History Patient Patient History has

  24. Cardinality- Optional The “0” indicates the entity may have zero instances. This means the relation is optional One Many Example: Movie is available on DVD Movie DVD Stored as

  25. Many-to-Many Relationships • Generally implies that there are attributes associated with the relationship • i.e., attributes that do not belong with one of the entities alone but with the combination • Many to Many relationships are very difficult to deal with in databases • A typical approach is to create a 3rd entity when we are faced with a many to many relation • the primary key for the new entity will be the keys of the entities that it connects

  26. Many-to-Many Example 0 Flight books Customer Can be transformed into: Seat 0 Books Is on Flight Customer This transformation makes the relationship easier to handle. In general, we seek to eliminate many to many relationships whenever possible.

  27. Many-to-Many Issues What information does this M-to-M assume is not important to keep track of?

  28. Objectives of Data Modeling • To minimize redundancy of a data base • To completely represent the required data in an information system

  29. Normalizing Data Bases • A set of rules to determine appropriate behavior for a data base. • First, fill in the blanks for EVERY record • Second, remove redundant items (partial dependency) • Third, eliminate complex relations where two or more relational meanings exist (transitive dependency)

  30. A Spreadsheet

  31. First Normal Form

  32. Second Normal Form Orders: Ordered Items: Item Descriptions:

  33. Third Normal Form Customers: Orders: City, Province: Ordered Items: Item Descriptions:

  34. Summary • We have covered the Systems Analysis part of the course… • Seek to understand a system, and to start to build a model of that system • Focus on the Systems Development Life Cycle • Process, Data, or Object Oriented • Works with traditional and rapid application development

  35. Summary • We ask questions: • Feasibility • Economic • Technical • Organizational • We plan major steps of the project • Understand current system • Envision possible improvements • automation • process improvement • process reengineering

  36. Summary • We gather data • questionnaires • interviews • observation • JAD • We start to model what we understand to be the processes under study • Build Use Cases • draw DFD’s

  37. Summary • We start to distill the required logic of the process • Logical data flows • Key processes • Logic within the processes themselves • And the data we need to keep within the system • ERD and logical data modeling

More Related