mis 3 dbms sad

7/30/2019 Mis 3 Dbms Sad

1/150

Management Information System(Module 3)

Database Management System

Prof. George MathewB.Sc., B.Tech, PGDCA, PGDM, MBA

Head Of Department

MSN INSTITUTE OF MANAGEMENT AND

TECHNOLOGY


2/150

File Systems and Databases

Database Systems: Design,Implementation, and Management,


3/150

Database ManagementSystems

Database

A structured set of data

Database management system (DBMS)A combination of software and data, madeup of a physical database, a database

engine, and a database schemaPhysical database

A collection of files that contain the data


4/150


Database engine

Software that supports access to and

modification of the database contentsDatabase schema

A specification of the logical structure of the

data stored in the databaseDatabase query

A request to retrieve data from a database


5/150


Figure 12.6 The elements of a database

management system


6/150


7/150

A Database Table

KeyOne or more fields of a database recordthat uniquely identifies it among all other

records in the tableWe can express the schema for this part ofthe database as follows:

Movie (MovieId:key, Title, Genre, Rating)


8/150

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


9/150

Database Management

Database is shared, integratedcomputer structure housing:

End user data

Metadata Database Management System

(DBMS)

Manages Database structure Controls access to data

Contains query language


10/150

Importance of DBMS

Makes data management more efficient andeffective

Query language allows quick answers to ad

hocqueries Provides better access to more and better-

managed data

Promotes integrated view of organizationsoperations

Reduces the probability of inconsistent data


11/150

DBMS Manages Interaction

Figure 1.2


12/150

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


13/150

View of Data

An architecture for a database system


14/150

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 customersand 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 andcomponents should be well defined so that changes in some partsdo not seriously influence others.


15/150

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


16/150

Entity-Relationship ModelExample of schema in the entity-

relationship model


17/150

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 depositorassociates customers

with accounts

Widely used for database design

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

and processing


18/150


19/150

Database Systems

Database consists of logically relateddata stored in a single repository

Provides advantages over file system

management approach Eliminates inconsistency, data anomalies,

data dependency, and structuraldependency problems

Stores data structures, relationships, andaccess paths


20/150

Database vs. File Systems


21/150


22/150

Database System Types

Single-user vs. Multiuser Database

Desktop

Workgroup

Enterprise

Centralized vs. Distributed

Use Production or transactional Decision support or data warehouse


23/150

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


24/150

Database ModelsCollection of logical constructs used torepresent data structure andrelationships within the database

Conceptual models: logical nature of datarepresentation

Implementation models: emphasis on how

the data are represented in the database


25/150

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

Database Models (cont.)


26/150

Hierarchical Database ModelLogically represented by an upside downtree

Each parent can have many children

Each child has only one parent


27/150

Hierarchical Database ModelAdvantages

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


28/150


29/150

Network Database Model

Advantages Conceptual simplicity

Handles more relationship types

Data access flexibility Promotes database integrity

Data independence

Conformance to standardsDisadvantages

System complexity

Lack of structural independence


30/150


31/150


32/150

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


33/150


34/150

The Relational Database

Model


35/150

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


36/150


37/150


38/150

Table Characteristics (cont.)

Column values all have same data format

Each column has range of values calledattribute domain

Order of the rows and columns isimmaterial to the DBMS


39/150


40/150

Example Tables

Figure 2.1


41/150

Keys (cont )


42/150

Keys (con t.) 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


43/150

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 whoseprimary key has mandatory matchingforeign key values in another table


44/150


45/150

UnionCombines all rows

Figure 2.5


46/150

Yields rows that appear in both tablesIntersect

Figure 2.6


47/150

Yields rows not found in other tablesDifference

Figure 2.7


48/150

Yields all possible pairs from twotables

Product

Figure 2.8


49/150

Yields a subset of rows based onspecified criterion

Select


50/150

Yields all values for selected attributes

Project

Figure 2.10


51/150

Information from two or more tables iscombined

Join

Figure 2.11

Figure 2.14


52/150


53/150


54/150


55/150

The Entity Relationship (E-R)Model

Represents conceptual view

Main Components

Entities Corresponds to entire table, not row

Represented by rectangle

Attributes

Relationships


56/150

Attributes

Characteristics of entities

Domain is set of possible values

Primary keys underlined

Figure 3.6


57/150

Attributes (cont.) Simple

Cannot be subdivided

Age, sex, marital status

Composite

Can be subdivided intoadditional attributes

Address into street, city, zip

Single-valued Can have only a single

value

Person has one socialsecurity number

Multi-valued Can have many

values

Person may haveseveral collegedegrees

Derived Can be derived with

algorithmAge can be derived

from date of birth

R l ti hi


58/150

Relationships

Association between entities

Connected entities are called participants

Operate in both directions

Connectivity describes relationshipclassification

1:1, 1:M, M:N

Cardinality

Expresses number of entity occurrencesassociated with one occurrence of related entity


59/150

Copyright 2002 Prentice-Hall, Inc.

The Systems Development

Environment

Modern Systems Analysisand Design


60/150

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


61/150

Introduction

Software engineering processes have beendeveloped to assist in analysis and design Methodologies

Comprehensive, multi-step approaches to systems

development Techniques

Processes that are followed to ensure that work is wellthought-out, complete and comprehensible to others on theproject team

Tools Computer programs to assist in application of techniques to

the analysis and design process

1.6


62/150


63/150

Introduction

Systems Analyst performs analysis anddesign based upon:

Understanding of organizations objectives,

structure and processes Knowledge of how to exploit information

technology for advantage

1.8

Systems Analysis


64/150

Systems Analysis Focus is the logicalview 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


65/150


66/150

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.


67/150

Data and Processes

Data

Understanding the source and use of data iskey to good system design

Various techniques are used to describe dataand the relationship amongst data

Data Flows

Groups of data that move and flow throughthe system

1.67


68/150

Data and Processes

Data Flows (Continued)

Include description of sources and destinationfor each data flow

Processing Logic Describe steps that transform data and events

that trigger the steps

1.68

Approaches to Systems


69/150

Approaches to SystemsDevelopment

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 specificapplications

1.69

Approaches to Systems


70/150

Approaches to SystemsDevelopment

Data-Oriented Approach Depicts ideal organization of data,

independent of where and how data are used

Data model describes kinds of data andbusiness relationships among the data

Business rules depict how organization

captures and processes the data

1.70

Databases and Application


71/150

Databases and ApplicationIndependence

Database Shared collection of logically related data

Organized to facilitate capture, storage and retrievalby 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


72/150

Organizational Responsibilities in SystemsDevelopment

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



73/150


IS Manager May have a direct role in systems

development if the project is small

Typically involved in allocating resources toand overseeing system development projects.

Systems Analyst Key individuals in the systems development

process



74/150


Skills of a Successful Systems AnalystAnalytical

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



75/150


Programmers Convert specifications into instructions that

the computer understands

Write documentation and testing programs Business Managers

Have power to fund projects and allocateresources

Set general requirements and constraints forprojects

1.75



76/150


Other IS Managers/Technicians Database Administrator

Involved in design, development and maintenance ofdatabases

Network and telecommunications experts Develop systems involving data and/or voicecommunications

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


77/150

Types of Information Systemsand 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


78/150

Types of Information Systemsand 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


79/150

Systems Development LifeCycle

System Development Methodology Standard process followed in an organization

Consists of:

Analysis Design

Implementation

Maintenance

1.79


80/150



81/150


Phases are not necessarily sequential

Each phase has a specific outcome anddeliverable

Individual companies use customized lifecycles

1.81

Phases of the Systems


82/150

Phases of the SystemsDevelopment 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 notresources 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



83/150


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



84/150


Design Logical Design

Concentrates on business aspects of the system

Physical Design

Technical specifications

Implementation Implementation

Hardware and software installation

Programming User Training

Documentation



85/150


Maintenance System changed to reflect changing conditions

System obsolescence

1.85

A h t D l t


86/150

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

A h t D l t


87/150

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


88/150

p o g S e e op e tProductivity

Computer-aided software engineering(CASE) tools

Facilitate creation of a central repository for

system descriptions and specifications

1.88


89/150


90/150

DATA FLOW DIAGRAMS

Systems Analysis


91/150

y y Focus is the logicalview of the

system, not the physicalWhat the system is to accomplish,

not how

Tools:

data flow diagrams

data dictionaryprocess specification

entity-relationship diagrams


92/150

Example Data Flow


93/150

Diagram

data store

process

external

entity

data flow

Data Flow Diagrams are:


94/150

Data Flow Diagrams are:

Used to perform structured analysisto determine logical requirements

A graphical tool, useful for

communicating with users,managers, and other IS personnel

Useful for analyzing existing as wellas proposed systems

A relatively simple technique to learnand use

Why Conduct Process


95/150

Why Conduct Process

Modeling? Understand components ofcurrent logical or physicalsystem for purpose of rebuilding

in a different physicalform/technology, possibly withsome changed functionality

Find inefficiencies in currentsystem

Re-engineer current system


96/150

Data Flows


97/150

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 - anoun

do not show control flow! Control flow

is easy to identify- a signal with onlyone byte - (on/off).

HINT: if you can't name it: either it'scontrol flow, doesn't exist or you needto get more information!

Processes


98/150

Processes transform incoming data

flows into outgoing dataflows

represent with a bubble orrounded square

name with a strongVERB/OBJECTcombination; examples:

create_exception_report

validate_input_characters

calculate_discount

process

Data Stores


99/150

data at rest

represents holding areas forcollection of data, processesadd or retrieve data fromthese stores

name using a noun (do notuse file)

only processes are connectedto data stores

show net flow of data

between data store andprocess. For instance, whenaccess a DBMS, show onlythe result flow, not the

request

data store

Diagramming A System


100/150

g g y

multiple DFDs are required torepresent a system

DFDs are created at increasing

levels of detail

Different Types of DFDs


101/150

yp

Context diagram

Level-0 diagram (system diagram)

Level-n diagram

Primitive diagram

Context Diagram


102/150

g

defines the scope of the system byidentifying the system boundary

contains:

one process (which represents theentire system)

all sources/sinks (externalentities)

data flows linking the process tothe sources and sinks (externalentities)

Example Context Diagram


103/150

Example Context Diagram

RegistrationSystem

studentcourseselections

businessoffice

Registration detailsschedule

Constructing a Context


104/150

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


105/150

g

describes the overall processing of thesystem

show one process for each majorprocessing 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 thislevel

can draw duplicate sources, sinks and

data stores to increase legibility

Drawing a Level-0 Diagram


106/150

a g a 0 ag a

list the major data stores

list major business steps

draw a segment for each businessstep

assemble into single DFD

re-organize until satisfied number processes

Functional Decomposition


107/150

similar to a series of more detailed maps

iterative process of breaking thedescription of a system into finer andfiner detail to create a set of charts inwhich one process on a given chart is

explained in greater detail on anotherchart

referred to as exploding, partitioning, orleveling

must use your judgment to decide whatgoes on each level

show error and exception handling on

lower levels (if at all)

Lower Level Diagrams


108/150

explode the processes shown on thelevel-0 diagram

each process is represented by its ownDFD

balance data

data flows on upper level appear onlower level, or

data flows on upper level are broken intocomponent pieces with components

shown on lower level each lower level shows greater and

greater detail

follow numbering convention

Balancing DFDs


109/150

Balancing DFDs

conserve data from level to level -inputs and outputs on the higherlevel must appears somewhere on

the lower level

Advanced Rules


110/150

d a ced u es

Composite data flow on one level can be

split into its component data flows onthe next level - but new data cannot beadded and all data in the compositemust be included in the sub-flows

The inputs to a process must besufficient 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/sinkto avoid crossing lines

Additional Guidelines


111/150

the inputs to a process are differentfrom the outputs of that process

objects in a set of DFDs have uniquenames

do not change data flow names on lowerlevels unless you are decomposing adata flow into component pieces.

never explode a single process intoanother single process. If you cannotpartition 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 createsomething satisfactory.


112/150

Quality Guidelines


113/150

Completeness

all components included & in projectdictionary

Consistency

between levels: balancing, leveling

Timing considerationsassume system never starts and never

stops

Iterative nature revisions are common

Drawing primitives (lowest level)

when to stop?

Introduction to Data Flow


114/150

Diagrams

Basic Constructs:

Processes

Data flows

Files

External Entities: sources or sinks

The Interrelation Between


115/150

The Interrelation BetweenSpecification Components

Example of a Data Flow


116/150


Diagram(1)



117/150

Diagram(2)

Introduction to Data Flow


118/150

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 FlowDiagrams (cont )


119/150

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


120/150

Levelled DFDs

Context Diagram


121/150

gDecomposition Level: 0

Diagram 0Decomposition Level: 1


122/150

Decomposition Level: 1

Diagram 1


123/150


Diagram 2


124/150


Data Dictionaries (DD)


125/150

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



126/150

Processing and control information omitted

from a DFD belongs in a processspecification

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


127/150

g

A rigid subset of the English languageomitting adjectives, adverbs, compoundand complex sentences, all verb modesexcept imperative and most punctuation

Result: A language containing a limited setof conditional and logic statements withnouns and strong verbs

Standards vary between organisations -objectives of: conciseness, precisenessand lack of ambiguityapply to all variants

Structured English (cont )


128/150

Structured English (cont.)

Posesses the three standard controlconstructs of:

sequence

selection iteration

and

primitive actions

These constructs permit the specificationof any system

Structured English (cont )


129/150

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

S i ki l i


130/150

Sequences:represent actions taking place in sequencewithout interruption. They are defined by the successive

appearance of a set of primitive actions

Selections: describe a series of alternative policies fromwhich only one is selected

IF CASE WHEN

ELSE WHEN

.. ... Iterations: A policy or series of actions is repeated within

some bounds. Represented by DOWHILEconstruct or aREPEAT UNTIL construct

T t l h 0



131/150

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

Advantages:



132/150

Advantages:

consice and precise, allow easy readingwithout ambiguity & misunderstanding

language notation may be tailored to suit user

must exist a cross-referencing with any dfd &dd entries thus perimitting thouroughverification

Disadvantages: formality may be alien when first read or write

Avoid assuming that anything written in SE is

correct

Decision Tables


133/150

A tabular of conditions and actions and an indication under whichconditions, which actions must be performed

Consists of four quadrants

Condition Stub Rulesa list of all possible conditions contains selectors which identify

that can arise within the process different combinations of the possible conditions

Action Stub Action Entriesa list of all possible actions that indicators which select the actions to beperformed

occur within the process

Decision Tables: 3


134/150

variants Limited Entry Decision Table

Mixed Entry Decision Table

Extended Entry Decision Table

Limited Entry Decision Table


135/150

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 Y N N N

Prompt Payer - Y N N

Special Clearance - - Y N

Accept Order X X X

Return Order X

Advantages of DecisionT bl


136/150

Tables Easily understood

Alternatives are shown side by side

Cause & effect relationship is shown, thuspermitting easier user validation

Possible to check that all combinations ofconditions have been considered

Decision Trees


137/150

Decision Trees

Alternative to Decision Tables Employ tree structures which show

conditions and actions within a problem

Advantage: Easy to understand, no needfor special training

Root of tree -> name of process

Nodes -> conditions

Leaves -> actions to be performed

Summary of ProcessModeling


138/150

ModelingA system is described using three

modes of representation:

data flow diagrams show relationships between processes, data flows, data

repositories and external infulences beyond the system boundaryin a graphical and structured manner

process specifications 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 StructuredSystems Analysis and Design


139/150

Syste s a ys s a d es g


Data Dictionary

Structure Chart

Data Flow Diagrams

To Implementation

Data Structures


140/150

Data Structures

IntroductionSelf-Referential Structures

Dynamic Memory AllocationLinked ListsStacksQueues

Trees

Introduction


141/150

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 efficientelimination of duplicate data items

Self-Referential StructuresS lf f ti l t t


142/150

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

1015

NULL pointer (points to nothing)Data member

and pointer

Linked Lists Linked list


143/150

ed st 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-pointermember of the current node

Link pointer in the last node is set to null to mark thelists 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:


144/150

yp 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

S k


145/150

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

QueuesQ


146/150

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)

TreesT d t i t li k


147/150

Tree nodes contain two or more links

All other data structures we havediscussed 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 childA node with no children is called a leafnode

TreesDi f bi t


148/150

Diagram of a binary tree

A D

C

TreesBi h t


149/150

Binary search tree

Values in left subtree less than parent Values in right subtree greater than parent

Facilitates duplicate elimination

Fast searches - for a balanced tree,maximum of log n comparisons

47

25 77

11 43 65 93

687 17 31 44

2

TreesTree traversals:

Inorder traversal prints the node values in ascending


150/150

Inorder traversal prints the node values in ascendingorder

1. Traverse the left subtree with an inorder traversal

2. Process the value in the node (i.e., print the nodevalue)

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

mis 3 dbms sad

Documents