Nontraditional Databases LFTSP 1998 IS 5.5

1
Non-traditional DatabasesLFTSP 1998 IS 5.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
Non-traditional Databases

• Traditional Databases
• centralised and relational
• Distributed Databases
• information distributed across many computers
• Multimedia Databases
• store complex multimedia information, including
  time-based information (e.g., video)
• Object-oriented Databases
• provide persistent storage for objects accessed
  by object-oriented programs

3
Traditional Databases
4
Centralised
App
DBMS
Comms
Database
App
App
App
App
5
Relational
Defined based on relations in the data which are
encoded as common keys appearing in
particular rows of the tables. All manipulations
are done at the table level (not row or column).
6
Distributed Databases
7
Centralised Database
App
DBMS
Comms
Database
App
App
App
App
8
Distributed Database
Database
App
DBMS
Comms
Part of Database
App
App
App
DBMS
Comms
Part of Database
App
App
9
Partitioned Database
Database
App
DBMS
Comms
W
X
App
App
App
DBMS
Comms
Y
Z
App
App
10
Replicated Database
Database
App
W
X
DBMS
Comms
Y
App
App
Z
App
W
DBMS
Comms
X
Y
App
App
Z
11
Partitioned, Replicated Database
Database
App
W
DBMS
Comms
X
App
Y
App
App
DBMS
Comms
Y
Z
App
App
12
Comparison of Alternatives
Centralised
Replicated
Unified
Distributed
Partitioned
Partitioned, Replicated
Parallelism Independence Flexibility Availability
Cost Difficulty of Control Security Risk
13
Multimedia Databases
14
Multimedia Databases

• relational databases store information using a
  limited set of types (characters, integers,
  floating-point numbers, etc.)
• information which doesnt fit these types can be
  problematic
• most modern relational databases also offer a
  type called BLOB (Binary Large OBject) which
  can be potentially any data type (including
  multimedia)

15
Issues

• semantics
• relational databases dont understand the
  contents of BLOBs
• limited ability to manipulate
• performance
• most databases are tuned for small record sizes
• large BLOBs break this model
• if a table contains many BLOBs, table
  manipulations become expensive
• time-base
• time-based multimedia (e.g., video) needs to be
  extracted from the database at predictable rates
  (e.g., one frame every 1/30th second)
• traditional databases are tuned for high
  transaction throughput, not real-time performance

16
Solutions

• give up on databases
• have to recreate the facilities a database
  provides
• retune relational databases for multimedia
  performance
• typical DBMS only allow global performance tuning
• other applications will suffer, or must be
  managed separately
• use data-blades
• pre-processors which understand the datas
  semantics and can restructure it to fit better in
  a relational table
• technology relatively new, unproven
• use specialised multimedia databases
• communications issues with other databases

17
Another Issue

• SELECT versus browsing
• select rank, famnam from member
• where givnams like M
• works fine for strings of text and other fixed
  data types
• what if we want
• select image from image-catalogue
• where image like (a sunset)
• possible solutions
• index by terms
• image (and sound, and video, and ....)
  specification mechanisms and recognition
  algorithms
• high-speed browsing

18
Object-oriented Databases
19
Object-oriented Databases

• provide persistent storage for objects
• closely linked to the object-oriented programming
  style

class
Point
methods
attributes
move(aInt, bInt)
Int
x
draw()
Int
y
equals(pPoint)Bool
20
Pointers

• objects are usually referenced by handles or
  pointers which are only valid during a single
  execution of a program
• to make objects persistent, pointers must be
  swizzled (transformed to a permanent value)

Point
move(aInt, bInt)
Int
x
draw()
y
pointers
equals(pPoint)Bool
Int
21
Persistent Objects

• stored as files
• must manage files
• must define storage format
• must write code to store both methods and
  attributes and keep definitions in sync
• must swizzle pointers manually
• stored using relational database
• must define database schemas mapping to methods
  and attributes
• must write access code (SQL) for the database
• must create object identifiers for pointer
  swizzling
• stored using object-oriented databases
• typically, just save

22
SQL 3

• standards effort from ANSI and ISO
• comes from the relational database community aim
  is to extend the relational model to handle
  objects better
• defines abstract data types as object
  representations
• uses an Object ID as the swizzled pointer
  representation
• adds method invocation to SQL
• adds implicit row identifiers (so keys are not
  required)
• adds subtables

23
ODMG 93

• standards effort by OMG
• comes from the object-oriented programming
  community aim is to enable persistent objects
• objects (not tables) are fundamental
• every object has a lifelong, permanent, unique
  identifier
• objects can be arranged into types and subtypes
• state is defined by data values and relationships
• behaviour is defined by object operations

24
Object-oriented Databases

• Advantages
• integrated with programming language
• automatic method storage
• user-defined types
• complex data readily processed
• automatic persistent object Ids
• single-level memory

• Disadvantages
• requires object-oriented programming
• little existing data in object form
• non-existent or poor query and reporting tools
• limited concurrency control and transaction
  management
• unproven performance
• substantial change and learning required

25
Non-traditional DatabasesLFTSP 1998 IS 5.5

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