Management Information System

(Module 3)
Database Management System

Prof. George Mathew

B.Sc., B.Tech, PGDCA, PGDM, MBA

Head Of Department

MSN INSTITUTE OF MANAGEMENT AND TECHNOLOGY

File Systems and Databases

Database Systems: Design, Implementation, and Management,

Database Management Systems

Database A structured set of data Database management system (DBMS) A combination of software and data, made up of a physical database, a database engine, and a database schema Physical database A collection of files that contain the data

Database Management Systems

Database engine Software that supports access to and modification of the database contents Database schema A specification of the logical structure of the data stored in the database Database query A request to retrieve data from a database

Database Management Systems

Figure 12.6 The elements of a database management system

The Relational Model

Relational DBMS A DBMS in which the data items and the relationships among them are organized into tables Tables A collection of records Records (object, entity) A collection of related fields that make up a single database entry Fields (attributes)

A Database Table
Key One or more fields of a database record that uniquely identifies it among all other records in the table We can express the schema for this part of the database as follows:
Movie (MovieId:key, Title, Genre, Rating)

Introducing the Database

Data versus Information
Data constitute building blocks of information Information produced by processing data Information reveals meaning of data Good, timely, relevant information key to decision making Good decision making key to organizational survival

Database Management
Database is shared, integrated computer structure housing:
End user data Metadata

Database Management System (DBMS)

Manages Database structure Controls access to data Contains query language

Importance of DBMS
Makes data management more efficient and effective Query language allows quick answers to ad hoc queries Provides better access to more and bettermanaged data Promotes integrated view of organizations operations Reduces the probability of inconsistent data

DBMS Manages Interaction

Figure 1.2

Database Design
Importance of Good Design
Poor design results in unwanted data redundancy Poor design generates errors leading to bad decisions

Practical Approach
Focus on principles and concepts of database design Importance of logical design

View of Data
An architecture for a database system

Instances and Schemas

Similar to types and variables in programming languages Schema the logical structure of the database e.g., the database consists of information about a set of customers and accounts and the relationship between them) Analogous to type information of a variable in a program Physical schema: database design at the physical level Logical schema: database design at the logical level Instance the actual content of the database at a particular point in time Analogous to the value of a variable Physical Data Independence the ability to modify the physical schema without changing the logical schema Applications depend on the logical schema In general, the interfaces between the various levels and components should be well defined so that changes in some parts do not seriously influence others.

Data Models
A collection of tools for describing
data data relationships data semantics data constraints

Entity-Relationship model Relational model Other models:

object-oriented model semi-structured data models Older models: network model and

Entity-Relationship Model
Example of schema in the entityrelationship model

Entity Relationship Model (Cont.)

E-R model of real world
Entities (objects)
E.g. customers, accounts, bank branch

Relationships between entities

E.g. Account A-101 is held by customer Johnson Relationship set depositor associates customers with accounts

Widely used for database design

Database design in E-R model usually converted to design in the relational model (coming up next) which is used for storage and processing

File Terminology
Data
Raw Facts

Field
Group of characters with specific meaning

Record
Logically connected fields that describe a person, place, or thing

File
Collection of related records

Database Systems
Database consists of logically related data stored in a single repository Provides advantages over file system management approach
Eliminates inconsistency, data anomalies, data dependency, and structural dependency problems Stores data structures, relationships, and access paths

Database vs. File Systems

Database System Environment

Figure 1.7

Database System Types

Single-user vs. Multiuser Database
Desktop Workgroup Enterprise

Centralized vs. Distributed Use

Production or transactional Decision support or data warehouse

DBMS Functions
Data dictionary management Data storage management Data transformation and presentation Security management Multiuser access control Backup and recovery management Data integrity management Database language and application programming interfaces Database communication interfaces

Database Models
Collection of logical constructs used to represent data structure and relationships within the database
Conceptual models: logical nature of data representation Implementation models: emphasis on how the data are represented in the database

Database Models (cont.)

Relationships in Conceptual Models
One-to-one (1:1) One-to-many (1:M) Many-to-many (M:N)

Implementation Database Models

Hierarchical Network Relational

Hierarchical Database Model

Logically represented by an upside down tree
Each parent can have many children Each child has only one parent

Hierarchical Database Model

Advantages
Conceptual simplicity Database security and integrity Data independence Efficiency

Disadvantages
Complex implementation Difficult to manage and lack of standards Lacks structural independence Applications programming and use complexity Implementation limitations

Network Database Model

Each record can have multiple parents
Composed of sets Each set has owner record and member record Member may have several owners

Figure 1.10

Network Database Model

Advantages
Conceptual simplicity Handles more relationship types Data access flexibility Promotes database integrity Data independence Conformance to standards

Disadvantages
System complexity Lack of structural independence

Relational Database Model

Perceived by user as a collection of tables for data storage Tables are a series of row/column intersections Tables related by sharing common entity characteristic(s)

Relational Database Model (cont.)

Figure 1.11

Relational Database Model

Advantages
Structural independence Improved conceptual simplicity Easier database design, implementation, management, and use Ad hoc query capability with SQL Powerful database management system

Relational Database Model

Disadvantages
Substantial hardware and system software overhead Poor design and implementation is made easy May promote islands of information problems

The Relational Database Model

Logical View of Data

Relational Database
Designer focuses on logical representation rather than physical Use of table advantageous
Structural and data independence Related records stored in independent tables Logical simplicity

Allows for more effective design strategies

Logical View of Data (cont.)

Entities and Attributes
Entity is a person, place, event, or thing about which data is collected Attributes are characteristics of the entity

Tables
Holds related entities or entity set Also called relations Comprised of rows and columns

Table Characteristics
Two-dimensional structure with rows and columns Rows (tuples) represent single entity Columns represent attributes Row/column intersection represents single value Tables must have an attribute to uniquely identify each row

Table Characteristics (cont.)

Column values all have same data format Each column has range of values called attribute domain Order of the rows and columns is immaterial to the DBMS

Keys
One or more attributes that determine other attributes
Key attribute Composite key

Full functional dependence Entity integrity

Uniqueness No null value in key

Example Tables

Figure 2.1

Simple Relational Database

Figure 2.2

Keys (cont.)
Superkey
Uniquely identifies each entity

Candidate key
Minimal superkey

Primary key
Candidate key to uniquely identify all other attributes in a given row

Secondary key
Used only for data retrieval

Foreign key
Values must match primary key in another table

Integrity Rules
Entity integrity
Ensures all entities are unique Each entity has unique key

Referential integrity
Foreign key must have null value or match primary key values Makes it impossible to delete row whose primary key has mandatory matching foreign key values in another table

Relational Database Operators

Relational algebra determines table manipulations Key operators
SELECT PROJECT JOIN

Other operators
INTERSECT UNION DIFFERENCE PRODUCT DIVIDE

Union
Combines all rows

Figure 2.5

Intersect
Yields rows that appear in both tables

Figure 2.6

Difference
Yields rows not found in other tables

Figure 2.7

Product
Yields all possible pairs from two tables

Figure 2.8

Select
Yields a subset of rows based on specified criterion

Project
Yields all values for selected attributes

Figure 2.10

Join
Information from two or more tables is combined

Figure 2.11

Figure 2.14

Data dictionary

Data Dictionary and System Catalog

Provides detailed account of all tables found within database Metadata Attribute names and characteristics

System catalog
Detailed data dictionary System-created database Stores database characteristics and contents Tables can be queried just like any other tables Automatically produces database documentation

Relationships within Relational Database

Relationship classifications
1:1 1:M M:N

E-R Model
ERD Maps E-R model Chen Crows Feet

ERD Symbols
Rectangles represent entities Diamonds represent the relationship(s) between the entities 1 side of relationship
Number 1 in Chen Model Bar crossing line in Crows Feet Model

Many relationships
Letter M and N in Chen Model Three pronged Crows foot in Crows Feet Model

The Entity Relationship (E-R) Model

Represents conceptual view Main Components
Entities
Corresponds to entire table, not row Represented by rectangle

Attributes Relationships

Attributes
Characteristics of entities Domain is set of possible values Primary keys underlined

Figure 3.6

Attributes (cont.)
Simple
Cannot be subdivided Age, sex, marital status

Multi-valued
Can have many values Person may have several college degrees

Composite
Can be subdivided into additional attributes Address into street, city, zip

Derived
Can be derived with algorithm Age can be derived from date of birth

Single-valued
Can have only a single value Person has one social security number

Relationships
Association between entities Connected entities are called participants Operate in both directions Connectivity describes relationship classification
1:1, 1:M, M:N

Cardinality
Expresses number of entity occurrences associated with one occurrence of related entity

Modern Systems Analysis and Design

The Systems Development Environment

Copyright 2002 Prentice-Hall, Inc.

Introduction
Information Systems Analysis and Design
Complex process whereby computer-based information systems are developed and maintained

Application Software
Result of systems analysis and design Designed to support specific organizational functions or processes

1.5

Introduction
Software engineering processes have been developed to assist in analysis and design
Methodologies
Comprehensive, multi-step approaches to systems development

Techniques
Processes that are followed to ensure that work is well thought-out, complete and comprehensible to others on the project team

Tools
Computer programs to assist in application of techniques to the analysis and design process
1.6

Introduction
Information Systems Analysis and Design
A method used by companies to create and maintain systems that perform basic business functions Main goal is to improve employee efficiency by applying software solutions to key business tasks A structured approach must be used in order to ensure success

1.7

Introduction
Systems Analyst performs analysis and design based upon:
Understanding of organizations objectives, structure and processes Knowledge of how to exploit information technology for advantage

1.8

Systems Analysis
Focus is the logical view of the system, not the physical What the system is to accomplish, not how Tools:
data flow diagrams data dictionary process specification entity-relationship diagrams

Software Engineering Process

A process used to create an information system Consists of:
Methodologies
A sequence of step-by-step approaches that help develop the information system

Techniques
Processes that the analyst follows to ensure thorough, complete and comprehensive analysis and design

Tools
Computer programs that aid in applying techniques

1.11

Data and Processes

Three key components of an information system
Data Data Flows Processing Logic

Data vs. Information

Data
Raw facts

Information
Derived from data Organized in a manner that humans can understand.

Data and Processes

Data
Understanding the source and use of data is key to good system design Various techniques are used to describe data and the relationship amongst data

Data Flows
Groups of data that move and flow through the system
1.67

Data and Processes

Data Flows (Continued)
Include description of sources and destination for each data flow

Processing Logic
Describe steps that transform data and events that trigger the steps

1.68

Approaches to Systems Development

Process-Oriented Approach
Focus is on flow, use and transformation of data in an information system Involves creating graphical representations such as data flow diagrams and charts Data are tracked from sources, through intermediate steps and to final destinations Natural structure of data is not specified Disadvantage: data files are tied to specific applications

1.69

Approaches to Systems Development

Data-Oriented Approach
Depicts ideal organization of data, independent of where and how data are used Data model describes kinds of data and business relationships among the data Business rules depict how organization captures and processes the data

1.70

Databases and Application Independence

Database
Shared collection of logically related data Organized to facilitate capture, storage and retrieval by multiple users Centrally managed Designed around subjects
Customers Suppliers

Application Independence
Separation of data and definition of data from applications
1.71

Organizational Responsibilities in Systems Development

Systems Analysts work in teams Project Based Includes IS Manager Programmers Users Other specialists Characteristics of Successful Teams Diversity of backgrounds Tolerance of diversity Clear and complete communication Trust Mutual Respect Reward structure that promotes shared responsibility

Organizational Responsibilities in Systems Development IS Manager

May have a direct role in systems development if the project is small Typically involved in allocating resources to and overseeing system development projects.

Systems Analyst
Key individuals in the systems development process

Organizational Responsibilities in Systems Development

Skills of a Successful Systems Analyst
Analytical
Understanding of organizations Problem solving skills System thinking
Ability to see organizations and information systems as systems

Technical
Understanding of potential and limitations of technology

Management
Ability to manage projects, resources, risk and change

Interpersonal
Effective written and oral communication skills

Organizational Responsibilities in Systems Development Programmers

Convert specifications into instructions that the computer understands Write documentation and testing programs

Business Managers
Have power to fund projects and allocate resources Set general requirements and constraints for projects
1.75

Organizational Responsibilities in Systems Development

Other IS Managers/Technicians
Database Administrator
Involved in design, development and maintenance of databases

Network and telecommunications experts

Develop systems involving data and/or voice communications

Human Factors Specialists

Involved in training users and writing documentation

Internal Auditors
Ensure that required controls are built into the system

Types of Information Systems and Systems Development

Transaction Processing Systems (TPS)
Automate handling of data about business activities (transactions)

Management Information Systems (MIS)

Converts raw data from transaction processing system into meaningful form

Decision Support Systems (DSS)

Designed to help decision makers Provides interactive environment for decision making

Types of Information Systems and Systems Development

Expert Systems (ES)
Replicates decision making process Knowledge representation describes the way an expert would approach the problem

1.78

Systems Development Life Cycle

System Development Methodology
Standard process followed in an organization Consists of:
Analysis Design Implementation Maintenance

1.79

Systems Development Life Cycle

Series of steps used to manage the phases of development for an information system Consists of six phases:

1.80

Project Identification and Selection Project Initiation and Planning Analysis Design Implementation Maintenance

Systems Development Life Cycle

Phases are not necessarily sequential Each phase has a specific outcome and deliverable Individual companies use customized life cycles

1.81

Phases of the Systems Development Life Cycle

Project Identification and Selection
Two Main Activities
Identification of need Prioritization and translation of need into a development schedule

Helps organization to determine whether or not resources should be dedicated to a project.

Project Initiation and Planning

Two Activities
Formal preliminary investigation of the problem at hand Presentation of reasons why system should or should not be developed by the organization
1.82

Systems Development Life Cycle

Analysis
Study of current procedures and information systems
Determine requirements
Study current system Structure requirements and eliminate redundancies

Generate alternative designs Compare alternatives Recommend best alternative

Systems Development Life Cycle

Design
Logical Design
Concentrates on business aspects of the system

Physical Design
Technical specifications

Implementation
Implementation
Hardware and software installation Programming User Training Documentation

Systems Development Life Cycle

Maintenance
System changed to reflect changing conditions System obsolescence

1.85

Approaches to Development
Prototyping
Building a scaled-down working version of the system Advantages:
Users are involved in design Captures requirements in concrete form

Rapid Application Development (RAD)

Utilizes prototyping to delay producing system design until after user requirements are clear

1.86

Approaches to Development
Joint Application Design (JAD)
Users, Managers and Analysts work together for several days System requirements are reviewed Structured meetings

1.87

Improving IS Development Productivity

Computer-aided software engineering (CASE) tools
Facilitate creation of a central repository for system descriptions and specifications

1.88

DATA FLOW DIAGRAMS

Systems Analysis
Focus is the logical view of the system, not the physical What the system is to accomplish, not how Tools: data flow diagrams data dictionary process specification entity-relationship diagrams

Data Flow Diagram:

"a network representation of a system. The system may be automated, manual, or mixed. The DFD portrays the system in terms of its component pieces, with all interfaces among the components indicated." - Tom DeMarco hence DFDs: focus on the movement of data between external entities and processes, and between processes and data stores

Example Data Flow Diagram

data store

data flow

process

external entity

Data Flow Diagrams are:

Used to perform structured analysis to determine logical requirements A graphical tool, useful for communicating with users, managers, and other IS personnel Useful for analyzing existing as well as proposed systems A relatively simple technique to learn and use

 Understand components of current logical or physical system for purpose of rebuilding in a different physical form/technology, possibly with some changed functionality Find inefficiencies in current system Re-engineer current system

Why Conduct Process Modeling?

 Any class of people, an organization, or another system which exists outside the system you are studying. Form the boundaries of the system. The system and external entities exchange data in the form of data flows. Must be named, titles preferred to names of individuals - use a noun

(external entities)

Sources/Sinks

source / sink

Data Flows
data in motion marks movement of data through the system - a pipeline to carry data connects the processes, external entities and data stores Unidirectional originate OR end at a process (or both) name as specifically as possible reflect the composition of the data - a noun do not show control flow! Control flow is easy to identify- a signal with only one byte - (on/off). HINT: if you can't name it: either it's control flow, doesn't exist or you need to get more information!

Processes
transform incoming data flows into outgoing data flows represent with a bubble or rounded square name with a strong VERB/OBJECT combination; examples: create_exception_report validate_input_characters calculate_discount

process

Data Stores
data at rest represents holding areas for collection of data, processes add or retrieve data from these stores name using a noun (do not use file) only processes are connected to data stores show net flow of data between data store and process. For instance, when access a DBMS, show only the result flow, not the request

data store

Diagramming A System
multiple DFDs are required to represent a system DFDs are created at increasing levels of detail

Different Types of DFDs

Context diagram Level-0 diagram (system diagram) Level-n diagram Primitive diagram

Context Diagram
defines the scope of the system by identifying the system boundary contains: one process (which represents the entire system) all sources/sinks (external entities) data flows linking the process to the sources and sinks (external entities)

Example Context Diagram

course selections

student

schedule

Registration System

Registration details

business office

Constructing a Context Diagram

identify and list sources/sinks (external entities) identify and list inputs to and outputs from sources/sinks (external entities) create context diagram

Level-0 Diagram
describes the overall processing of the system show one process for each major processing step or functional requirement data flows from the context appear on system diagram also (level balancing) can show a single data store to represent all data in aggregate at this level can draw duplicate sources, sinks and data stores to increase legibility

Drawing a Level-0 Diagram

list the major data stores list major business steps draw a segment for each business step assemble into single DFD re-organize until satisfied number processes

Functional Decomposition
similar to a series of more detailed maps iterative process of breaking the description of a system into finer and finer detail to create a set of charts in which one process on a given chart is explained in greater detail on another chart referred to as exploding, partitioning, or leveling must use your judgment to decide what goes on each level show error and exception handling on lower levels (if at all)

Lower Level Diagrams

explode the processes shown on the level-0 diagram each process is represented by its own DFD balance data
data flows on upper level appear on lower level, or data flows on upper level are broken into component pieces with components shown on lower level

each lower level shows greater and greater detail follow numbering convention

Balancing DFDs
conserve data from level to level inputs and outputs on the higher level must appears somewhere on the lower level

Advanced Rules
Composite data flow on one level can be split into its component data flows on the next level - but new data cannot be added and all data in the composite must be included in the sub-flows The inputs to a process must be sufficient to produce the outputs. Lowest level DFDs may add new data flows to represent exception handling, i.e., error messages May repeat data stores or sources/sink to avoid crossing lines

 the inputs to a process are different from the outputs of that process objects in a set of DFDs have unique names do not change data flow names on lower levels unless you are decomposing a data flow into component pieces. never explode a single process into another single process. If you cannot partition the process, then the lower level DFD is not needed. expect to iterate, put down the DFD and go back to it a few times to create something satisfactory.

Additional Guidelines

1. How deep? (how many levels?)

Other Questions about Lower level diagrams

if the process has only one input or one output, probably cannot partition further; can you describe the process in English in about 1/2 page?

2. How broad? (how many processes on a level?)

7 two is a reasonable heuristic may temporarily place much of the system on a single diagram then re-draw into separate levels

Quality Guidelines
Completeness
all components included & in project dictionary

Consistency
between levels: balancing, leveling

Timing considerations
assume system never starts and never stops

Iterative nature
revisions are common

Drawing primitives (lowest level)

when to stop?

Introduction to Data Flow Diagrams

Basic Constructs:
Processes Data flows Files External Entities: sources or sinks

The Interrelation Between Specification Components

Example of a Data Flow Diagram(1)

Example of a Data Flow Diagram(2)

Introduction to Data Flow Diagrams (cont.)

Constructing Data Flow Diagrams
Identify the Static Components Identify the Main Processes Expand and Refine the Diagram Review the Diagram

Introduction to Data Flow Diagrams (cont.)

Levelling Data Flow Diagrams
The Concept of Levelling Levelling Conventions
Process Referencing Functional Primitives Balancing

Hints on Data Flow Diagramming

Annotation of Diagrams Extent of Decomposition Extent of Partitioning Check for Usefuleness

The Structure of a Set of Levelled DFDs

Context Diagram Decomposition Level: 0

Diagram 0 Decomposition Level: 1

Diagram 1 Decomposition Level: 2

Diagram 2 Decomposition Level: 2

Data Dictionaries (DD)

Purpose:
to keep data about:
Data Flow and Data Item Specifications File Specifications Process Specifications

Data Specification Language:

Notational Conventions: = , + , [ ] , { } , ( ) e.g. amount due = [dollar amount, sterling amount]

Process Specifications

Process Specifications
Processing and control information omitted from a DFD belongs in a process specification Each functional primitive has one process specification Process Specifications can be represented in a variety of languages, the most popular are:
Structured English Decision Tables and Decision Trees

Structured English
A rigid subset of the English language omitting adjectives, adverbs, compound and complex sentences, all verb modes except imperative and most punctuation Result: A language containing a limited set of conditional and logic statements with nouns and strong verbs Standards vary between organisations objectives of: conciseness, preciseness and lack of ambiguity apply to all variants

Structured English (cont.)

Posesses the three standard control constructs of:
sequence selection iteration

and
primitive actions

These constructs permit the specification of any system

Structured English (cont.)

Primitive Actions expressed as imperative statements, e.g.
READ-FILE STOCK-DETAILS

should be concise
avoiding vague words (e.g. process / handle) containing a strong verb identifying the function stating explicitly the object of the statement, which is selected from the data dictionary

 Control Constructs Sequences: represent actions taking place in sequence

without interruption. They are defined by the successive appearance of a set of primitive actions

Selections: describe a series of alternative policies from

which only one is selected IF <condition> CASE <statement> WHEN <condition> <statements> ELSE WHEN <condition> <statements> <statement> .. ...

Iterations: A policy or series of actions is repeated within

some bounds. Represented by DOWHILE construct or a REPEAT UNTIL construct

Structured English (cont.)

Total_charge = 0 REPEAT get_next_room IF room_type = EXECUTIVE total_charge=total_charge+60$ ELSE total_charge=total_charge + 35$ UNTIL all_booked_rooms_processed OR total_charge > credit_limit

Structured English (cont.)

Advantages: consice and precise, allow easy reading without ambiguity & misunderstanding language notation may be tailored to suit user must exist a cross-referencing with any dfd & dd entries thus perimitting thourough verification Disadvantages: formality may be alien when first read or write Avoid assuming that anything written in SE is correct

Decision Tables
A tabular of conditions and actions and an indication under which conditions, which actions must be performed Consists of four quadrants

Condition Stub
a list of all possible conditions that can arise within the process

Rules
contains selectors which identify different combinations of the possible conditions

Action Stub
a list of all possible actions that occur within the process

Action Entries
indicators which select the actions to beperformed

 Limited Entry Decision Table Mixed Entry Decision Table

Decision Tables: 3 variants

Extended Entry Decision Table

Limited Entry Decision Table

Contains only the binary selectors Y & N and the catch all selector in the rules quadrant. In the action entries, it contains only the action selector symbol X. 1 2 3 4

Credit Satisfactory Prompt Payer Special Clearance Accept Order Return Order

Y Y X

N N X

N N Y

N N

Advantages of Decision Tables

Easily understood Alternatives are shown side by side Cause & effect relationship is shown, thus permitting easier user validation Possible to check that all combinations of conditions have been considered

Decision Trees
Alternative to Decision Tables Employ tree structures which show conditions and actions within a problem Advantage: Easy to understand, no need for special training Root of tree -> name of process Nodes -> conditions Leaves -> actions to be performed

A system is described using three modes of representation: data flow diagrams process specifications

Summary of Process Modeling

show relationships between processes, data flows, data repositories and external infulences beyond the system boundary in a graphical and structured manner

structured english, decision trees or tables: they document in a precise and consice fashion the elementary processing operations performed by each functional primitive in a set of dfds

data dictionary entries

describe the nature of data flows and hold the process specifications

Documentation In Structured Systems Analysis and Design

Data Flow Diagrams Data Dictionary

Process Specifications

Structure Chart

To Implementation

Data Structures
Introduction Self-Referential Structures Dynamic Memory Allocation Linked Lists Stacks Queues Trees

Introduction
Dynamic data structures Data structures that grow and shrink during execution Linked lists Allow insertions and removals anywhere Stacks Allow insertions and removals only at top of stack Queues Allow insertions at the back and removals from the front Binary trees High-speed searching and sorting of data and efficient elimination of duplicate data items

Self-Referential Structures
Self-referential structures Structure that contains a pointer to a structure of the same type Can be linked together to form useful data structures such as lists, queues, stacks and trees Terminated with a NULL pointer (0) Diagram of two self-referential structure objects linked together

15

10

Data member and pointer

NULL pointer (points to nothing)

Linked Lists
Linked list
Linear collection of self-referential class objects, called nodes Connected by pointer links Accessed via a pointer to the first node of the list Subsequent nodes are accessed via the link-pointer member of the current node Link pointer in the last node is set to null to mark the lists end

Use a linked list instead of an array when

You have an unpredictable number of data elements Your list needs to be sorted quickly

Linked Lists Types of linked lists:

Singly linked list Begins with a pointer to the first node Terminates with a null pointer Only traversed in one direction Circular, singly linked Pointer in the last node points back to the first node Doubly linked list Two start pointers first element and last element Each node has a forward pointer and a backward pointer Allows traversals both forwards and backwards Circular, doubly linked list Forward pointer of the last node points to the first node

Stacks
Stack
New nodes can be added and removed only at the top Similar to a pile of dishes Last-in, first-out (LIFO) Bottom of stack indicated by a link member to NULL Constrained version of a linked list

push
Adds a new node to the top of the stack

pop
Removes a node from the top Stores the popped value Returns true if pop was successful

Queues
Queue
Similar to a supermarket checkout line First-in, first-out (FIFO) Nodes are removed only from the head Nodes are inserted only at the tail

Insert and remove operations

Enqueue (insert) and dequeue (remove)

Trees
Tree nodes contain two or more links
All other data structures we have discussed only contain one

Binary trees
All nodes contain two links
None, one, or both of which may be NULL

The root node is the first node in a tree. Each link in the root node refers to a child A node with no children is called a leaf node

Trees
Diagram of a binary tree
B

A C

Trees
Binary search tree
Values in left subtree less than parent Values in right subtree greater than parent Facilitates duplicate elimination 2 Fast searches - for a balanced tree, 47 maximum of log n comparisons
25 11 7 17 43 31 44 65 68 77 93

Tree traversals:

Trees

Inorder traversal prints the node values in ascending order 1. Traverse the left subtree with an inorder traversal 2. Process the value in the node (i.e., print the node value) 3. Traverse the right subtree with an inorder traversal Preorder traversal 1. Process the value in the node 2. Traverse the left subtree with a preorder traversal 3. Traverse the right subtree with a preorder traversal Postorder traversal 1. Traverse the left subtree with a postorder traversal 2. Traverse the right subtree with a postorder traversal