UNIT-IIInformation Modeling

Information ModelInformation ModelAn information model is a representation of concepts and the relationships, constraints, rules, and operations to specify data semantics for a chosen domain of discourse. It can provide sharable, stable, and organized structure of information requirements or knowledge for the domain context.

An information model provides formalism to the description of a problem domain without constraining how that description is mapped to an actual implementation in software.

There may be many mappings of the information model. Such mappings are called data models, irrespective of whether they are object models (e.g. using UML), entity relationship model or XML schemas

Different Views Of Modelling Static or structural view point:

It focuses on the main information structures and the relationship between these structures.

It describes the 'what' part of the problem domain.

Data model used for modeling the static view is Entity Relationship (ER) diagram, class/object diagram

Functional view point:

It describes the functionality of the system in terms of the main processes of the business and the flow of data among these processes.

It describes the 'how' part of the problem domain.

Data model used for modeling functional view is DFD, use case diagram, activity diagram.

Different Views Of Modelling

Different Views Of Modelling Dynamic Viewpoint:

It shows the time dependent behavior of the system i.e., how the system responds to the external environment.

Functional and Dynamic view together also called the behavioral view of the problem domain.

Data model used for modeling the dynamic view is state chart, sequence & collaboration diagram.

Different Views Of Modelling

Activities operate on the information structures (identified using static view) and events that trigger these activities. Events may be external to the system or may be generated internally by the system eg. Placing of order by the customer is an example of event taking place in the system

ER Model Conceptual design: (ER Model is used at this

stage.) What are the entities and relationships in the

enterprise? What information about these entities and

relationships should we store in the database? What are the integrity constraints or business

rules that hold? A database `schema’ in the ER Model can be

represented pictorially (ER diagrams). An ER diagram can be mapped into a

relational schema.

SUMMARY OF ER-DIAGRAM NOTATION FOR ER SCHEMAS

Meaning

ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

IDENTIFYING RELATIONSHIP TYPE

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE

DERIVED ATTRIBUTE

TOTAL PARTICIPATION OF E2 IN R

CARDINALITY RATIO 1:N FOR E1:E2 IN R

Symbol

E1 R E2

E1 R E2N

ER Model Basics

Entity: Real-world object distinguishable from other objects. An entity is described (in DB) using a set of attributes.

Entity Set: A collection of similar entities. E.g., all employees. All entities in an entity set have the same

set of attributes. (Until we consider ISA hierarchies, anyway!)

Each entity set has a key. Each attribute has a domain.

Employees

ssnname

lot

ER Model Basics

Key and key attributes: Key: a unique value for an entity Key attributes: a group of one or more attributes

that uniquely identify an entity in the entity set Super key, candidate key, and primary key

Super key: a set of attributes that allows to identify an entity uniquely in the entity set

Candidate key: minimal super key There can be many candidate keys

Primary key: a candidate key chosen by the designer Denoted by underlining in ER attributes

Employees

ssnname

lot

ER Model Basics (Contd.)

Relationship: Association among two or more entities. e.g., Jack works in Pharmacy department.

Relationship Set: Collection of similar relationships. An n-ary relationship set R relates n entity sets E1 ... En;

each relationship in R involves entities e1 in E1, ..., en in En Same entity set could participate in different relationship

sets, or in different “roles” in same set.

lotdname

budgetdid

sincename

Works_In DepartmentsEmployees

ssn

Reports_To

lot

name

Employees

subor-dinate

super-visor

ssn

Key Constraints

Consider Works_In: An employee can work in many departments; a dept can have many employees.

In contrast, each dept has at most one manager, according to the key constraint on Manages.

Many-to-Many1-to-1 1-to Many Many-to-1

dnamebudgetdid

since

lot

namessn

ManagesEmployees Departments

Example ER An ER diagram represents

several assertions about the real world. What are they?

When attributes are added, more assertions are made.

How can we ensure they are correct?

A DB is judged correct if it captures ER diagram correctly.

Students

Professor teaches

Department

faculty

major offers

Courses

enrollmentadvisor

Participation Constraints Does every department have a manager?

If so, this is a participation constraint: the participation of Departments in Manages is said to be total (vs. partial). Every Departments entity must appear in an

instance of the Manages relationship.

lotname dname

budgetdid

sincename dname

budgetdid

since

Manages

since

DepartmentsEmployees

ssn

Works_In

Weak Entities A weak entity can be identified uniquely only by

considering the primary key of another (owner) entity. Owner entity set and weak entity set must participate

in a one-to-many relationship set (one owner, many weak entities).

Weak entity set must have total participation in this identifying relationship set.

lot

nameagepname

DependentsEmployees

ssn

Policy

cost

ISA (`is a’) Hierarchies

Contract_Emps

namessn

Employees

lot

hourly_wagesISA

Hourly_Emps

contractid

hours_worked As in C++, or other PLs, attributes are inherited. If we declare A ISA B, every A entity is also considered to be a B entity. Overlap constraints: Can Joe be an Hourly_Emps as well as a

Contract_Emps entity? (default: disallowed; A overlaps B) Covering constraints: Does every Employees entity also have

to be an Hourly_Emps or a Contract_Emps entity? (default: no; A AND B COVER C)

Reasons for using ISA: To add descriptive attributes specific to a subclass. To identify entities that participate in a relationship.

What are DFDs? Data flow diagrams (DFDs) is used to model the functional

view of the system in terms of processes and flow of data between these processes.

Also called as: Process model Work flow diagrams Function model Bubble chart Bubble diagram

Data flow diagrams show: Data flowing through a system to or from users (external

entities) The processes that transform the data The data stores that hold the data

Elements of DFDs1. Process

Used to show some kind of transformation on data

Represented by a circle with name and number of process

Normally require at least one input and produce at least one output

Inputs / outputs (I/O) may flow to or from other processes, data stores or external entities

Process names should be meaningful verb object phrases not nouns.

2Compute

salary

Processes in a DFDCorrect vs. Incorrect

Incorrect Correct

Elements of DFDs2. Data Flows(shows data in motion)

Flows of data between: external entities and processes processes and other processes processes and data stores

Represented by arrows. Can be simple data elements or complex data structures It represents:

Data input to a process Output from a process Insertion of new data in the store or retrieval of

existing data Updating existing data in the store Deletion of existing data from the store

Elements of DFDs Data flow labels are normally entity or attributes in ER

diagram i.e., the static view.

Data flow can be classified as convergent and divergent data flows.

Convergent data flow is formed by merging multiple data flows into a single data flow.

Divergent data flow breaks up into multiple data flows.

ComputeSalary

PrintReport

Emp_id

No. of HoursSalary

Salary Slip

Data Flows in a DFDIncorrect vs. Correct

Incorrect Correct

Elements of DFDs3. Data Stores

Represents data at rest Represent the places where data is stored Typically files or database tables

Campaigns Campaigns

Elements of DFDs4. External Entities

(Source/Sink/Terminator) People, organizations or systems external to

the system being developed An external entity is not necessarily a direct

user of the system Provide input to the system and also receive

output from the system. Typically trigger processes Represented by a rectangular box

CampaignManager

Naming and Drawing DFD Elements

Process

Data flow

Data store

Externalentity

Creating a Data Flow Model It enables software engineer to develop models of the

information domain and functional domain at the same time.

Data flow diagram may be used to represent a system or software at any level of abstraction

As DFD is refined into greater levels of detail, the analyst performs an implicit functional decomposition of the system.

As DFD refinement results in corresponding refinement of data as it moves through the processes that represent the application

DFD Guidelines1. All names should be unique2. All data flows are named.3. The direction of flow is from source to destination.4. Processes are always running, they do not start or stop.5. Context level DFD should depict the system as a single

bubble.6. Primary input and primary output should be clearly

identified.7. While doing the refinement isolate processes, data

objects and data stores to represent the next level.8. Information flow continuity must be maintained from

level to level.9. Do numbering of processes.

DFD for Patient Record management system

A level 0 DFD, also called a fundamental system model or a context model, represents the working of entire organization, by a single process and its interaction with external agents through exchange of data.

External agents can be some people, organization, some other system or even some other software.

It defines the boundary of the system being developed and shows how a system interacts with the external world.

Leveled DFD:Context Diagram(Level 0 DFD)

Level 0 DFD refinement into level 1 DFD with all relevant processes to the system.

Level 1 DFD each processes can be refined into level 2 DFD.

Refinement of DFD continues until each bubble performs a simple function.

Leveled DFD:Context Diagram(Level 0 DFD)

Context Diagram (Level 0 DFD)

Process

External Entity

External Entity

External Entity

External Entity

External Entity

Relationship Among DFD levels

Level1DFD

Level 2DFDfor process 2

Level 3 DFDfor process 2.2

Data Dictionaries DFDs are supported by data dictionary entries It is the organized listing of all data elements of the system

with their precise and unambiguous definitions. It helps user and system analyst to have common

understanding of inputs, outputs, components of stores and intermediate calculations.

Each element is defined in a data dictionary Data elements - name and data type Data structures - name and composition Data flows - name and content Data stores - name and data structures contained Processes - name and specification of the process, for

example in Structured English

Data dictionary Data dictionaries are simply repositories to store

information about all data items defined in DFDs.

Data dictionary store following information :1. Name of the data item2. Aliases(other names for item)3. Description/Purpose4. Related data item5. Range of values6. Data Structure definition

The notation used to develop a content description is noted in the following table:

Notation Meaning= Is defined as/ Composed of+ and

Min{ }max Iteration with min & max values specified

( ) Optional data elements[ | ] Selection of one data from several

choices separated by |** comment{ } Iteration(0 or more occurrences)@ Store identifier

Data dictionary example

Advantages of Data Dictionary

1. It defines the data items unambiguously

2. It is a valuable reference in any organization

3. It is a store of organizational knowledge linking analysis, design and implementation.

4. It is an important step in building a database. Most database management systems have a data dictionary as a standard feature.

Decision Tables A decision table specifies a system as set of possible

conditions, rules for reacting to stimuli when those conditions are met, and specific actions to be taken as result.

Use a decision table when there is a complicated sub-policy selection that depends upon combinations of conditions.

There are holes or omissions in the users’ statements, and some parts of the problem requirements are not described at all.

A decision table makes those requirements omissions or contradictions explicit so the software engineer can go back to the client and ask specific questions regarding what to do when these conditions arise.

Parts of Decision Table Condition Stubs

Condition stubs describe the conditions or factors that will affect the decision or policy. They are listed in the upper section of the decision table.

Action Stubs Action stubs describe, in the form of statements, the

possible policy actions or decisions. They are listed in the lower section of the decision table.

Rules Rules describe which actions are to be taken under a

specific combination of conditions. They are specified by first inserting different combinations of condition attribute values and then putting X's in the appropriate columns of the action section of the table.

Structure of Decision Table

Decision rulesRule 1 Rule 2 Rule 3 Rule 4

(condition stub) (Condition entries)

(action stub) (Action entries)

Decision Table Format Identify all the possible conditions (the decision variables) and

place them in the left hand column of the table. Then identify all the possible combinations of the conditions to

define the rules which form the other columns. The rows hold the possible values for each of the

conditions/variables and the rules. The values may be Boolean, (as in this first example) or domain

specific values. Below the conditions in the left-hand column you add Actions. Create a row for each possible action that could occur. Then fill in the values for the actions based on the combination

of conditions specified in the column about the current value to be determined.

Then using the values for the conditions specified for each rule, place the action that the requirements say should occur.

Decision Table Methodology1. Identify Conditions & Values

Find the data attribute each condition tests and all of the attribute's values.

2. Compute Max Number of Rules Multiply the number of values for each condition data attribute by

each other.3. Identify Possible Actions

Determine each independent action to be taken for the decision or policy.

4. Enter All Possible Rules Fill in the values of the condition data attributes in each numbered

rule column. 5. Define Actions for each Rule

For each rule, mark the appropriate actions with an X in the decision table.

6. Verify the Policy Review completed decision table with end-users.

7. Simplify the Table Eliminate and/or consolidate rules to reduce the number of columns.