Cardinality vs Degree

Whats the difference between cardinality and degree?

Cardinality is the min and max # of occurences of one entity that may be related to a single occurence of another entity.

Degree is the # of entities that participate in a relationship.

Logical vs Physical models

What's the difference between logical and physical models?

Logical models:

• Document business requirements to show what a system does
• Are implementation independent
• illustrate the essence of the system

Physical models:

• Show not only what a system does but how a system is physically and technically implemented.
• Are technology depenent because they reflect the technology choices and the limitations of those choices.
  

Why are logical models better than physical models for systems analysis?

• They are technology implementation independent. This makes them more likely to be usable in the future when current tecchnology becomes outdated.
  
  
• They keep the focus on business requirements. They are less detailed so the readers don't get lost in technical details
  
  
• They are more viewer/user friendly. It would be easier to communicate system ideas to users with logical models because they wouldn't be overwhelmed with technical details.
  

Feasibility Definitions

Feasability:

The measure of how beneficial, or practical and info sys wil be to an org.

Feasability Analysis:

The process by which feasability is measured.

Operational Feasibility:

A measure of how well a solution will work or be accepted by an org.

• Usability analysis: a test of the systems user interfaces
• will it work? (keyboard vs gloves)

Technical Feasibility:

A measure of the practicality of a technical solution + the availability of technical resources and expertise.

Schedule Feasiblity:

A measure of how reasonable the project timetable is.

Economic Feasibility:

A measure of the cost effectiveness of a project or solution. (Return on investment)

Relationship Definitions

Relationship:

A natural business association between 1 or more entities.

Recursive Relationship:

A relationship that exists between instances of the same entity.

Nonidentifying Relationship:

A relationship in which each participating entity has its own indie primary key.

Identifying Relationship:

A relationship in which the parent entitiy's key is also part of the primary key for the child entity.

Nonspecific Relationship:

A relationship where many instances of an entity are associated with many instances of another entity (aka many to many relationship)

Cardinality Symbols

The Process Modelling Stages

1. Context DFD
• Establishes initial project scope
• Simple, shows only sys's main interfaces w/ its environment
  
  
2. Functional Decomposition Diagram
• partition the system into logical subsystems and/or functions
  
  
3. Event Responses (Use Case List)
• ID's + confirms the biz events which the sys must respond to
• Describes required or possible responses to events
  
  
4. Add Event Handler to decomp dia.
• Further partitions the functions
  
  
5. Event Diagram (1 for each event)
• Simple DFD w/ event handler, inputs + outputs for events.
  
  
6. System Diagram
• Merge event diagrams into sys dia.
• Shows the 'big picture' of the system
  
  
7. Primitive Diagram
• Build for event processes that need additional processing deets.
  
• Logic of each process explained
• Data structure of each elementary data flow described.
  

Logical Data Model Dev Stages

1. Entity Discovery
   
• Discover entities
• Build Entity Matrix
  
  
2. Context Data Model
• Establish project scope
  
  
3. Key Based Data Model
• Eliminate non specific relationships
• Add associative entities
• Include primary and alternative keys
• Precise cardinalities
  
  
4. Fully Attributed Data Model
• All remaining attributes
• Include subsetting criteria
  
  
5. Normalize Data Model
• 1st normal
• 2nd normal
• 3rd normal
  

And then in long form...

ENTITY DISCOVERY (ED)
First comes entity discovery. You must figure out what all of the entities in a system are. Usually you put them into an entity matrix with a row for entity names and a row for the business definition.

CONTEXT DATA MODEL (CDM)
Next a context data model is drawn up. The context data model establishes the scope of the project. It is pretty basic and includes the entities showing their relationships with each other. It also includes cardinality which makes non specific relationships apparent.

KEY BASED DATA MODEL (KBDM)
Then a key based data model is made. Non specific relationships are resolved and associative identities are added. The KBDM includes primary and alternatekeys and precise cardinalities.

FULLY ATTRIBUTED DATA MODEL (FADM)
Next step, the fully attributed data model. The FADM includes all remaining attributes and subsetting criteria.

NORMAL FORM (NF)
The final step is normalizing the FADM into 1st 2nd and 3rd normal form.

1. 1NF: All enties attributes have no more than 1 value per instance
2. 2NF: In 1NF + non PK atts depend on the full PK
3. 3NF: In 2NF + non PK atts don't depend on other non PK atts
   

Exam Notes

Chapters 8, 9 + 10

Be sure and read chapters 8 and 9.


Data Modelling ℜ

Know the process

1. Define entities.
2. Build a context diagram (showing relationships).
3. Build a key based data model(hierarchies, associative entites).
4. Build a fully attributed data model
5. Normalize the data model (1 2 3 normal forms) look at normalization info on page 323
   

Process Modelling ℜ

Know the process

1. Build context diagram
2. Build decomposition (subsystems)
3. Use case analysis
4. 
   

Things to Know:

• Know diagrams on page 299 ℜ
  
• Be able to explain relationships ℜ
  
• Be able to talk thru the different data/process models ℜ
  
• Be able to explain normalization ℜ
  
• Explain feasability and what it is ℜ
  
• Draw up a entity relationship diagram and a data flow diagram

Test structure

• 9 short answer
• true/false
• fill in the blank

5:45 room 840