The following notes were taken during a lecture in COMP 230 Systems Analysis & Design at Camosun College by Marla Weston.  These notes are here mainly to help me study, but if you can find some guidance through them then all the better!

Conceptual Data Modeling Process

In the design stage, the conceptual data model is translated into a physical design

Deliverables and Outcome

• Primary deliverable is an entity-relationship diagram (ER Diagram)
• Second deliverable is a set of entries about data obnects to be stored in repository or project dictionary
  • repository links data, process, and lopgic models of an information system
  • data elements included in the DFD must appear in the ERD

Conceptual Data Model

• The 30,000 foot view.
• Very high level
• Just the system and any external entities that interact with it.

Gathering Information for Conceptual Data Modeling

• Top Down approach for the data model is derived from an intimate understanding of the system
• Bottom Up approach which builds simple low-level objects into more complex higher-level objects.

Entity Relationship Model

• Entity type name should always be a singular noun
• Entity type definition should:
  • Include a statement of what the unique characteristics is/are for each instance
  • Make clear what entity instances are included and not included in the entity type
• Attributes: a named property characteristic of an entity that is of interest to the organization
  • Naming an attribute: eg Vehicle_ID
  • Place its name inside the rectangle for the associated entity in the E-R Diagram
  • Name is a noun and should be unique
  • States what the attribute is and possibly why it is important
  • Should indicate if a value is required or optional
• Relationships
  • A relationship name is a verb phrase and avoid vague names
  • A relationship definition should:
    • Explain any optiontion participation
    • Explain the extent of history that is kept in the relationship
• 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 instances
  • Used mostly in many-many relationships
• Subtypes: A type together with a constraint which possibly restricts the allowed range of values
• Supertypes: A generic entity type that has a relationship with one or more subtypes
• Business Rules: specifications that preserve the integrity of the logical data model
  • Entity Integrity
  • Referential
  • Trigger/Triggering Operation – An assertion or rule that governs the validity of data manipulations such as insert update and delete

The following notes were taken during a lecture in COMP 230 Systems Analysis & Design at Camosun College by Marla Weston.  These notes are here mainly to help me study, but if you can find some guidance through them then all the better!

Data Flow Diagrams (DFD)

• Technology independent
• show data flows, structure, and functional requirements of new system
• Useful for depicting purely logical information flows
• DFDs that detail physical systems differ from system flowcharts which depict details of physical computing equipment

Process: work or actions performed on data (inside the system)
Data store: data at rest (inside the system)
Source/sink: external entitty that is orgingin or destination of dara (ouotside the system)
Data flow: arrow depicting movement of data.
Context Diagram: is an overview of an organizational system that shows:

• the system boundaries
• external entities that interact with the system
• major information flows between the entities

Level-0 Diagram

DFD Rules

There are DFD guidelines that apply:

- the inputs to a process are different form the outputs of that provess
- no process can only have outputs or only inputs. processes must have both inputs and outputs.
- process labels should be verb phrases
- all flows to or from a data store must move through a process
- no data move directly between external entities without going through a process
- bidirectional flwo between process and data store is represented by two separate arrow (no bi-directional arrow)
- forked data flow must refer to exact same data item (not different data items) from a common location
- joined data flow must refer to exact same data item (not different data items) from multiple souces to a common location
- data flow caonn go diretly from a process to itself (no recursive data flows)
- data flow from  a process to a data store means update( insert, delete or change)
Functional decomposition is an iterative process of breaking a system description down into finer and finer detail.

• creates a set of charts in which one process on a given chart is explained in great detail on another chart.
• continues until no sub process can logically be broken down any further

Primitive DFD – the lowest level of a DFD.
level 1 diagram results from decomposition of level 0 diagram
BPR: Business Process Re-engineering