Data Store Systems EEE465 1999 Lecture 5

1
Data Store SystemsEEE465 1999 Lecture 5

• Major Greg Phillips
• Royal Military College of Canada
• Electrical and Computer Engineering
• greg.phillips_at_rmc.ca
• 01-613-541-6000 ext. 6190

2
Context

• Were taking a tour of architectural styles
• Data flow
• Data store
• Event-based
• Layered
• For each, we are examining
• Intuition
• Implementations
• Examples
• Today
• introduce data store systems
• discuss database systems and the modern compiler
  architecture as examples

3
Data Store Systems

• A data store system is one in which
• all data is maintained in a central store,
  sometimes called a repository
• a collection of external, independent components
  operate on the data in the store
• In a pure data store system, all interaction
  between the independent components is through the
  data store

4
Data Store
computation
data access
external component
external component
external component
external component
external component
external component
external component
external component
memory
5
Data Flow versus Data Store

• Data Flow (review)
• dominant question is how data moves through a
  collection of (atomic) computations
• as data moves, control is activated
• reasoning is about data availability,
  transformation, latency
• data flow is often analysed between processes,
  but the participants need not be processes
• Data Store
• dominant questions are how data is stored and how
  access to it is mediated
• control may be internal or external to the data
  store
• reasoning is about data representation,
  concurrency control, and process activation

6
Kinds of Data Store Systems

• Key distinction is made on the basis of locale of
  control
• if the independent components control the
  manipulations of the data store, we have
  something similar to a classic database
• if the current state of the data store triggers
  computations in the independent components, we
  have something similar to a blackboard model
• We will look at databases, blackboard systems and
  other examples over the next three lectures.

7
Classic Multiuser Database
Application
DBMS
Comms
Database
Application
Application

• Applications are external processes which read
  and modify data in a database.
• A database management system (DBMS) is a software
  system design to efficiently manage large
  quantities of structured data in secondary
  storage, retrieve that data on demand, and
  control how the data are accessed and shared by
  possibly many concurrently executing user
  processes.
• A database is a collection of data managed by a
  DBMS.
• A communications module connects applications to
  the DBMS
• Applications are clients, DBMS is server

8
Database seen as a Data Store
External Components
Data Store
Application
DBMS
Comms
Database
Application
Application

• Fairly direct mapping not surprising seeing as
  the role of a database is to act as exactly a
  data store.
• Note that the communications module does not form
  part of the data store abstraction.

9
Issue Concurrent Access
Incorrect Summary
User 2
User 1
User 1
User 2
read(x) x x1
Lost Update
sum0 read(x) sumsumx
read(x) x x1
time
read(y) y y-1000 write(y)
write(x)
write(x)
time
read(y) sumsumy read(z) sumsumz
User 2
User 1
read(x) x x1 write(x)
read(z) z z1000 write(z)
Dirty Read
time
read(x)
abort
10
Key Definitions

• Concurrency control. Activity of coordinating the
  actions of processes that operate in parallel and
  access shared data.
• Recovery. Ensuring that hardware and software
  errors do not corrupt persistent data.
• Transaction. Set of operations on a database to
  perform some logically complete task.
• transactions must be prevented from interfering
  with one another
• if a transaction terminates normally, its effects
  are permanent, otherwise it has no effect
• transactions are composed of the operations
  read(x), write(x), commit, and abort (rollback)

11
Transaction ACID Properties

• Atomicity. A transaction is performed in its
  entirety or not at all.
• Consistency preservation. A transaction must
  take the database from one consistent state to
  another.
• Isolation. A transaction must not make its
  updates visible to other transactions until it
  commits.
• Durability. Once a transaction commits, its
  updates must never be lost.

12
Serializability

• The operations of multiple transactions must be
  interleaved in such a way that the transactions
  do not interfere with one another.
• The results of the execution of the transactions
  must be as if they were run one after the other
  in serial fashion.
• this is called serializability
• The database system must find serializable
  executions of the transactions it receives.

13
Variations on a ThemeDistributed Databases
14
Partitioned Database
Database
App
Comms
W
DBMS
X
App
App
Comms
Y
DBMS
Z
App
Issues latency, throughput
15
Replicated Database
Database
App
W
DBMS
Comms
X
Y
App
Z
W
App
DBMS
Comms
X
Y
Z
App
Issues consistency, replication interval
16
Partitioned, Replicated Database
Database
App
W
DBMS
Comms
X
Y
App
App
DBMS
Comms
Y
Z
App
Issues as previous two slides
17
Recall Modern Compiler Architecture

• enhanced pipe and filter
• relies on persistent data structures (symbol
  table, parse tree) which are used and modified
  through compilation

Parse tree
Lex
Syn
Sem
Opt
Code
program text
object code
Symbol table
18
Modern Compiler ArchitectureViewed as a Data
Store

• all data communication via the repository
• control flow communicated directly between
  components
• allows other tools to be easily added to the
  system

Syn
Sem
Opt
Lex
Parse tree
program text
Code
object code
Symbol table
19
Next ClassBlackboardSystems