Representation
System
prescription
Conceptual
model
Description
of reality
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
User
interface
(visualization)
Prescription
Description
Reality
The purpose of the model
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Most foils are produced by Gerhard Skagestein
INF4180 Ð 3 September 2003
Ragnar Normann <ragnarn@ifi.uio.no>
INF4180-beyondrel-3
INF4180-beyondrel-1
Beyond Relational Databases
Relational
technology
Organization
Users
INF4180-beyondrel-2
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
INF4180-beyondrel-4
q Extendable Mark-up Language
è Document databases
q Relational databases with
extensions
q Object-oriented languages
è Object-oriented databases
The Successors
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Information
System
GIS
CAD/CAM
Multimedia
Documents
É
influence
Perception of reality
= Universe of Discourse
(UoD)
register
Reality
Information models
The topics
INF4180-beyondrel-7
INF4180-beyondrel-5
q General principles for obtaining persistence
q Object oriented databases
q Extended relational databases
q Persistent distributed objects
q Semi-structured databases
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Persistence
q The interesting questions
o Objects, data, text, É in the ÓdatabaseÓ?
o How do we make those things persistent?
q We will look into
o Object oriented databases
o Extensions to relational databases
o XML databases
o CORBA persistent service
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Relational
Relational
databases
databases
SIMULA (62 - )
GML
General
Markup
Language
1970
- ODL
- OQL
- OML
SQL-3 (99)
INF4180-beyondrel-6
2000
XML (96 - )
SemiSemistructured
structured
databases
databases
CORBA 3.x (00)
Object/Datastandards
fusion ?
ODMG V1.0 (93) ODMG V3.0 (00)
Object
Object
relational
relational
databases
databases
SQL-2 (92)
The History
Extended relational
databases
SMALLTALK
C++
EIFFEL
Object
Object
oriented
oriented
databases
databases
OMG V.1 (91)
- OMA
- CORBA
- IDL
HTML (89 - 92)
Object oriented
distributed systems
SGML (83 - 86)
1990
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
1980
Life span of objects and data
q The Program perspective:
Objects die at the latest by program termination
(they are transient)
q The Database perspective:
Objects exist until explicitly removed
(they are persistent)
INF4180-beyondrel-8
Is it possible to combine
those two perspectives?
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Compiler
Application
Program
Schema
Preprocessor
Application
Programming
Interface
Query
Processor
Program
text
Schema
text
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Database Management System
DDL
Schemas and programs
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
o Database integrated with the program
(The Single Storage Illusion)
q Make ÒobjectsÓ persistent by the program
(SQL Create, bind object to database)
o Database separated from the program
q Explicitly transfer ÒobjectsÓ to and from
a permanent storage by read/write commands
INF4180-beyondrel-11
Users
Developer
INF4180-beyondrel-9
Òvirtual
permanent
storageÓ
hidden from
the program
read/write
DML
How to achieve persistence
INF4180-beyondrel-10
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Why do OO-databases have a
separate ODL language?
o ODL = Object Definition Language (ODMG)
o IDL = Interface Definition Language (OMG)
INF4180-beyondrel-12
q OO-databases:
The schema language (IDL, ODL) is a separate language
q Relational databases:
The schema language (DDL) and the manipulation language
(DML) are integrated in the same language (SQL)
Schema and manipulation languages
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q All types of objects should be able to be persistent
(Type and persistence are orthogonal)
q Transient and persistent objects should be handled the same way
Ð simple programming
q The usual programming language (Java, C++, Smalltalk)
should also be a Object Manipulation Language
Database integrated with the program
INF4180-beyondrel-13
The Óimpedance mismatchÓ
problem shows up when the
DBMS and the application
program are working with
different types of operands
(elements/sets/containers)
Application
Program
Compiler
Program
text
ÓThe impedance mismatchÓ
Schema
text
Schema
Preprocessor
Application
Programming
Interface
Query
Processor
Database Management System
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
INF4180-beyondrel-14
Solving the Óimpedance mismatchÓ-problem
q Let the API mimic a navigational view into the database
(the SQL-solution Ð ÓcursorsÓ)
q Give the database navigational capabilities
q Give the application programming languages container
capabilities
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
The Basic Principle of Object-orientation
Model the miniworld (Universe of Discourse, UoD) as
Object-oriented Databases
I contain objects,
message
a collection of cooperating, related units, called objects
System
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
INF4180-beyondrel-16
not data!
INF4180-beyondrel-15
We will talk about models and concepts,
but not so much about how to model
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
messages
interface
OID
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q Objects have a behaviour (they have methods)
q Objects remember (they have a state)
INF4180-beyondrel-19
INF4180-beyondrel-20
ÒgenericÓ object operators:
¥ object comparison
¥ object retrieval
¥ ...
based on OID
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
Vera Goebel
o generally system-managed
o not reused after object deletion
o unchanged during object lifetime
o (system-wide) unique
q Object identity cannot (reliably) be based on ordinary values
provided by application (value orientation)
... but on surrogates: object identifiers being
o ÒidentityÓ ! ÒequalityÓ (both need to be expressible)
o no misleading references to objects
o modifications of any kind result in ÒsameÓ object
state
(attributes
with values)
methods
INF4180-beyondrel-18
Object Identity _ Object Identifier (OID)
Vera Goebel
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
What are the
most important
concepts from
a database
point of view?
q Objects exist independently of their (current) values
INF4180-beyondrel-17
o polymorphism
o inheritance of properties
o super-/sub-classes
q Taxonomy
o collection of similar objects (extension)
o common description (intension)
q Classification
o request of performance from other objects
o encapsulation (information hiding)
o value: data structure
o object: <value,{operators}>
q Abstraction and autonomy
Object-Oriented Concepts (General)
Object-name
Characteristics of objects
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Thou shalt remember thy data
Thou shalt manage very large databases
Thou shalt accept concurrent users
Thou shalt recover from hardware and software failures
Thou shalt have a simple way of querying data
q Objects have a permanent, immutable, not reusable identity
Ð the Object identifier (OID)
o
o
o
o
o
Atkinson et al.:
The Object Oriented
Database System Manifesto
(1990)
Thou shalt support complex objects
Thou shalt support object identity
Thou shalt encapsulate thine objects
Thou shalt support types or classes
Thine classes or types shalt inherit from their ancestors
Thou shalt not bind prematurely
Thou shalt be computationally complete
Thou shalt be extensible
q Rules that make it a DBMS
o
o
o
o
o
o
o
o
q Rules that make it an OO system:
The thirteen OODBMS Commandments
Literal
q A literal has no object identifier
q A literal is normally the value of an object attribute,
hence it is embedded in an object
q Atomic literal
Value of basic data type
(long, short, char, string, É)
and enumeration
(enum Class {first, business, tourist} class)
q Non-atomic literals, see laterÉ
Non-atomic objects
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q A literal is immutable
Collections
q Bag<T>
q Set<T>
ordered collection of objects of type T
unordered collection of objects of type T,
duplicates allowed
unordered set of (different) objects of type T
INF4180-beyondrel-21
q List<T>
ordered, indexed collection of objects of type T
An iterator can be created to traverse a collection
q Array<T>
INF4180-beyondrel-23
q Dictionary<T> set of object pairs of type T
(struct Association {Object key, Object value; } ;)
Structured (predefined)
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q Date, Time, Timestamp, Interval
Object Ñ literal
string seat;
INF4180-beyondrel-24
INF4180-beyondrel-22
object
Person
enum Class {first, business, tourist} class;
Passenger passenger;
struct Seat {
}
Passenger
attribute Person nextOfKin;
attribute string name;
class Passenger {
}
nextOfKin
literal
Non-atomic literals
Dag Belsnes
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
object value
name Jensen
Name of
q structured literal type
q structured literal element
q enumeration atomic literal type
q enumeration literal
q basic atomic literal type
23F
tourist
Seat
Name of
q atomic object type
q object attribute
passenger
class
seat
structured literal
q Collections
o as for objects:
set<t>, bag<t>, list<t>, array<t>, dictionary<t>
q Structured
o predefined: date, time, timestamp, interval
o user defined: struct { É }
struct Address {
string street;
unsigned short number;
unsigned short postNo;
string postArea;
}
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
Vera Goebel
COMPLEX VALUE
CONSTRUCTORS
Lists
Sets
Arrays
Tuples
É.
OBJECT
INF4180-beyondrel-25
Value
construction
Object
construction
basics
ref
salary: 4000)
salary: 2000)
salary: 1000)
O1 = < ¥, V1, ¥>
O2 = < ¥, V2, ¥>
O3 = < ¥, V3, ¥>
O5 = < ¥, V7, ¥>
© Institutt for informatikk 2003Ð Gerhard
15. Aug. 2001
Vera Skagestein
Goebel
INF4180-beyondrel-27
V7 = tuple of (depname: ÓfinanceÓ, employees: set of (ref O1, ref O2, ref O3)
O4 = < ¥, V6, ¥>
V6 = tuple of (depname: ÓfinanceÓ, employees: set of (O1, O2, O3)
V5 = tuple of (depname: ÓfinanceÓ, employees: set of (V1, V2, V3)
V4 = tuple of (name: ÓHermansenÓ,
address: tuple of (zipcode: N-0157,
city: ÓOsloÓ,
street: ÓTollbodgataÓ,
phone: set of (22 93 54 32, 977 54 36)),
salary: 2000)
V1 = tuple of (name: ÓSolskj¾rÓ,
V2 = tuple of (name: ÓBergÓ,
V3 = tuple of (name: ÓD¾hliÓ,
Construction of Complex Values / Objects
© Prof. Dr. Klaus R. Dittrich
q References,
subobjects,
explicit
relationships
q Which base
types?
q Which
constructors?
Degrees of freedom:
Construction of Complex Objects
retrieve/delete/copy object
retrieve/delete/copy object (parts)
modify values
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
Vera Goebel
(also) included: value-based selection of desired objects
INF4180-beyondrel-28
Structure related operators (insert/remove subobjects; navigation in object structures
Processing of individual object levels
(nontransitively; structure irrelevant)
Generic object operators
Processing of entire objects
(transitively; depending on actual structure)
Value operators
Object := <OID, value, {operators}>
For composite objects:
¥ one-level operators
affect topmost level only, NOT subobjects
¥ multilevel (ÓtransitiveÓ) operators
potentially affect ALL direct and indirect subobjects
(Ópropagation effectÓ)
INF4180-beyondrel-26
e.g. path in design of
VLSI cell
e.g. chapter
in book
Vera Goebel
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
e.g. disk drive
in PC
e.g. module in
software system
Dependent
subobjects
(no own existence)
Operators for Complex Objects
© Prof. Dr. Klaus R. Dittrich
Not sharable
subobjects
(physical)
Sharable
subobjects
(logical)
Independent
subobjects
(own existence)
Subobjects versus References to Objects
Notions of equality
q Shallow equality
o Two objects have shallow equality if their visible attributes
pairwise have the same values
q Deep equality
o Two objects have deep equality if they in addition to shallow
equality have the same values for all attributes recursively
reachable through their pointers (i.e. ODL-relations)
q Equivalence
classification
Person
UML
INF4180-beyondrel-29
INF4180-beyondrel-31
Anne:Person
Per:Person
Person
Intension and extension
Ragnar
Normann15.
4. Aug.
Sept. 2001
2002
© Institutt for informatikk 2003Ð Gerhard
Skagestein
o Two objects are equivalent (identical) if their references are
equal (they have the same OID)
intension
extension
Gro:Person
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Classification
q Identification and description of a concept as a type
q A type has an external specification
and one or more implementations
q The specification defines the external aspect, visible to the
user of the type:
o operations that can be invoked on the instances
INF4180-beyondrel-30
o properties (or state variables), whose values can be accessed
o exceptions that can be raised by the operations
Dag Belsnes
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
Specifications
q Interface definition
Specification of the abstract behaviour of an object type
Literal
INF4180-beyondrel-32
Cattell et al.:
The Object Data Standard:
ODMG 3.0
Figure 2-1
q Class *) definition
Specification of the abstract behaviour and abstract state of an
object type
Abstract class
*)
Class
q Literal definition
specification of the abstract state of a literal type
Interface
Abstract behavior
(operations)
Abstract state
(properties)
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
copy( );
delete( );
Object
void
boolean same_as(in Object anObject);
}
street;
Dag Belsnes
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
string postArea;
unsigned short postNo;
unsigned short number;
string
struct Address {
Literal definition, example
INF4180-beyondrel-35
INF4180-beyondrel-33
All user-defined
objects inherit this
Object interface
automatically
Dag Belsnes
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
If there is an attribute in the interface definition,
this just says that it should be possible to
read/write that attribute
Ð it does not belong to the state
(an interface can not be instanciated ! )
}
lock(in Lock_Type mode) raises (LockNotGranted);
void
boolean try_lock(in Lock_Type mode);
Lock_Type{read, write, upgrade};
Enum
interface Object {
Interface definition, example
Vera Goebel
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
Advantages of the inheritance principle:
o code reusability (when operators are inherited)
o representation of additional semantics
o design discipline (stepwise refinement)
Instances of subtypes inherit properties from supertypes
INF4180-beyondrel-36
o extension hierarchy (with regard to membership of instances)
o implementation hierarchy (with regard to operators, representation)
o interface hierarchy (with regard to operators)
considerable variation in details:
TAXONOMY: generalization/specification
Þ subtypes/supertypes, IS_A-relationship
q
INF4180-beyondrel-34
Type/Class Hierarchies, Inheritance
Dag Belsnes
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
unsigned short descendants(out set<Person> inheritors);
void marriage (in string ssn) raises(NoSuchPerson);
relationship set<Person>parents inverse Person::children;
relationship list<Person> children inverse Person::parents;
Object types are not always independent of each other
}
Objects will automatically
be members of this
collection
Ð very useful for queries!
relationship <Person> spouse inverse Person::spouse;
attribute Address address;
readonly attribute string ssn;
attribute string name;
exception NoSuchPerson { } ;
(extent persons key ssn) {
class Person {
Class definition, example
Variations in interpretation of subtypes
B is_a A
q Taxonomy
o where an A-object is required, a B-object may be used
o implementation of B uses implementation of A
o sets (extensions) of instances: {B} Í {A}
q Inheritance of
o value types
o external interfaces (signatures of operator set)
o code
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
INF4180-beyondrel-37
o simple polymorphism (concrete operation inherits definition)
List
Collection
Object
Date
Bag
Array
Time
Dictionary
structured objects
Timestamp
Interval
Built-in interfaces of the object model
Iterator
Bidirectional
Iterator
Set
INF4180-beyondrel-39
Elmasri & Navathe Figure 12.2 (page 394)
For an overview of the definition of the interfaces,
see Elmasri & Navathe Figure 12.1a & 12.1b
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q
q
Simple or multiple inheritance?
Rules for inheritance
o simple inheritance (type hierarchy)
o multiple inheritance (type lattice)
The ODMG object model:
o interfaces and classes may inherit from multiple interfaces
(denoted by : )
o classes can inherit only from a single class
(denoted by extends)
A pragmatic decision!
INF4180-beyondrel-40
INF4180-beyondrel-38
Example:
class TeacherAssistant extends Employee:StudentIF {É}
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Properties of objects
q State-properties
o Attributes
o Relationships
q Operator-properties
o Operations with exceptions
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
methods
state
(attributes
with values,
relationships)
Object-name
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
INF4180-beyondrel-41
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
INF4180-beyondrel-43
o Operator name may be reused under the condition that the
parameter list is different
q Overloading
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
o appropriate mechanism needed
o building upon predefined or other user-defined operators
q User-defined
INF4180-beyondrel-44
§ uniform applicability for all values built by a given constructor
§ for composite values only
o Generic
§ overloading possible
o Type of result
o Exceptions that may be raised
§ (at least) for atomic values
o Type-specific
q System defined (predefined)
Operators
INF4180-beyondrel-42
Why do we have
relationships?
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
class Professor {
É
relationship set<Course> teaches
inverse Course::is_taught_by;
}
class Course
É
relationship Professor is_taught_by
inverse Professor::teaches;
}
defines relationships between two types
q Relationships
class Person{
attribute short age;
attribute string name
attribute enum gender {male, female};
attribute Address home_address;
attribute set<Phone_no> phones;
attribute Department dept;
}
defines the abstract state of the instances of the class
q Attributes
Modeling state-properties
o List of parameters (including each parameterÕs type)
o Name of operator
q Operation signatures Ð the interface of an operation
Modeling behaviour Ð Operations
q relationships
q attributes - literals, ÒcollectionsÓ and OIDs
The state of an object is the union of the current values of its
messages
interface
OID
The State
interface
methods
state
(attributes
with values)
Object-name
Encapsulation
OID
messages
q The state is not directly accessible from outside Ð
it can only be inspected or changed by calling methods
(i.e. sending messages)
q The implementation of the operator bodies is hidden Ð
only the signatures are visible from outside
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Polymorphism
INF4180-beyondrel-45
q Overloading: use of same name for different operators (in different types)
q Overriding: reimplementation of operator bodies on lower level of type
hierarchy
print_circle(x);
print_rectangle(x);
print_triangle(x);
(exception handling);
print_geometric_object (o: g_obj)
(implemented for circles, rectangels, triangles etc)
for all x in M do print_geometric_object(x);
vs.
for all x in M do case
x is circle:
x is rectangle:
x is triangle:
otherwise
¥
Requires ÓlateÓ binding
É.. of an operator name to an associated implementation (É to a type)
generic « overloaded « individual
Operators:
INF4180-beyondrel-47
¥
Vera Goebel
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
b) write-encapsulation
(ÓdirectÓ read-access
allowed)
INF4180-beyondrel-46
c) partial encapsulation
(arbitrary ÓdirectÓ
access to public
data allowed)
Degrees of Encapsulation
a) complete encapsulation
(all accesses exclusively
by calling defined
operations)
Vera Goebel
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
INF4180-beyondrel-48
(Integrity) Constraints on Objects
q mostly implemented in methods (per type/class)
q inherited along type/class hierarchy
q explicit relationships / consistency constraints
q key constraints
Vera Goebel
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
Users
Developers
Vera Goebel
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
INF4180-beyondrel-51
q via entry points into the database
(1) persistent collections, or
(2) root of network of connected objects (by references)
q Persistence specified explicitly by
(1) naming, or
(2) reachability
q Seamless integration of DBS and programming language
=> two types of objects: transient and persistent objects
INF4180-beyondrel-49
What are the metaclasses/interfaces,
and how are the
semantics ?
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
User
Programs
Compiler/
Schema
processor
Schema
text
How to make objects persistent
Object Database
Management System
ODL
The meta level
Dictionary
Collection
Type
o object, each object has a unique identifier (OID)
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
INF4180-beyondrel-52
q An object has a set of operation-properties.
These operations can be executed by the object and make up
the behaviour of the object
q The state of an object is the value of its state-properties
o the relationships between the object and other objects
o the attributes of the object
q An object has a set of state-properties
q Objects and literals are classified by their types
INF4180-beyondrel-50
jf. Cattell et. al:
The Object Data Standard
ODMG 3.0
page 42-53
ODMG Object Model
o literal, no oid, represents a value
(possible with a complex structure)
Constant
Relationship
Property
Operand
Attribute
Exception
MetaObject
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Operation
q Basic building blocks:
Class
Interface
DefiningScope
Scope
RepositoryObject
Some interfaces on the meta-level
The choices made in the ODMG object model
Types, instances, interfaces, and implementations
q Objects are instances of types
q A type defines the behaviour and state of its instances
q Behaviour is specified as a set of operations
q An object can be an immediate instance of only one type
q The type of an object is determined statically at the time the object is
created; objects do not dynamically acquire and lose types
q Types are organized into a subtype-supertype graph
q A type may have multiple supertypes
q Supertypes are explicitly specified; subtype-supertype relationships
between types are not deduced from signature compatibility of the types
INF4180-beyondrel-55
INF4180-beyondrel-53
Cattell & al.: The Object Data Standard ODMG 3.0, page 265
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Properties of OODM
q object identity
q complex (composite) objects
q types / classes
q user-definable types
q language completeness
q encapsulation
q type/class hierarchies
q overloading / overriding / late binding (polymorphisms)
... all orthogonal !
Vera Goebel
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
The choices made in the ODMG object model
Operations
q Operations have signatures that specify the operation name,
arguments, and return values
q Operations are defined on a single type Ð the type of their
distinguished first argument Ð rather than on two types
q Operations may take either literals or objects as their arguments.
Semantics of argument passing is pass by reference
q Operations are invoked
q Operations may have side effects
q Operations are implemented by methods in the implementation
portion of the type definition
INF4180-beyondrel-54
Cattell & al.: The Object Data Standard ODMG 3.0, page 265
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
(Purposely) Not Part of OODM Definition
... but also needed/provided in ÒnewÓ DBS
q object versions
q specific realization (implementation) of concepts
q distribution (client/server architectures)
INF4180-beyondrel-56
q specific processing aspects, e.g., new transaction mechanisms
q rule-based mechanisms (active / deductive features)
q ... and many more
© Institutt for informatikk 2003Ð Gerhard
Skagestein 15. Aug. 2001
Vera Goebel
Object
Object
oriented
oriented
databases
databases
1990
HTML (89 - 92)
- OMA
- CORBA
- IDL
OMG V.1 (91)
- ODL
- OQL
- OML
INF4180-beyondrel-57
2000
XML (96 - )
SemiSemistructured
structured
databases
databases
CORBA 3.x (00)
Object/Datastandards
fusion ?
ODMG V1.0 (93) ODMG V3.0 (00)
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
1980
SGML (83 - 86)
Object oriented
distributed systems
SMALLTALK
C++
EIFFEL
SQL:1999 (SQL 3)
Object
Object
relational
relational
databases
databases
SQL-2 (92)
Functions, including database procedures and encapsulation, is a good idea
Unique identifiers for records should be assigned by the DBMS only if a user-defined primary key is
not available
Rules (triggers, constraints) will become a major feature in future systems. They should not be
associated with a specific function or collection
Essentially all programmatic access to a database should be through a non-procedural, high-level
access language
There should be at least two ways to specify collections, one using enumeration of members, and one
using the query language to specify membership
Updateable views are essential
Performance indicators have almost nothing to do with data models and must not appear in them
Third-generation DBMS must be accessible from multiple high-level languages
Persistent forms of a high-level language, for a variety of high-level languages, are a good idea. They
will all be supported on top of a single DBMS by compile extensions and a complex runtime system
For better or worse, SQL is Óintergalactic dataspeakÓ
Queries and their resulting answers should be the lowest level of communication between a client and
a server
q
q
q
q
q
q
q
q
q
q
q
INF4180-beyondrel-59
Stonebraker et.al. 1990
Inheritance is a good idea
q
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
A third generation DBMS must have a rich type system
q
The Third-Generation Database System Manifesto
1970
GML
General
Markup
Language
SIMULA (62 - )
Extended relational
databases
Extended/Object relational databases
Relational
Relational
databases
databases
INF4180-beyondrel-58
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
OK Ð so what is wrong
with BLOBs?
q Hence, the DBMS can only do store/retrieve and test on
equality
INF4180-beyondrel-60
q The Database Management System has no knowledge of the
internals of the BLOB
q May be used for representing almost anything: Pictures,
sounds, texts, complex values, É.
q A value consisting of a bit pattern of (almost) arbitrary length
BLOB: Binary Large Object
The first extension: The BLOB
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q A Relation r of the relation schema R(A1, A2, ..., An):
A set of n-tuples, r (R) = { t1, t2, ... , tk },
where t is an ordered set of values = < v1, v2, ..., vn >
and where "i, vi Î dom(Ai) È null
q Relation schema R(A1, A2, ..., An):
A set of attributes R = {A1, A2, ..., An},
q Attribute: A role played by a domain, D = dom(Ai)
q Domain: A set of atomic values
Classical
Classical relation
relation ÐÐ formal
formal definition
definition
Nested relations
Augmenting the formal definition:
string(20),
]>
...
INF4180-beyondrel-61
INF4180-beyondrel-63
Nested relation schema for VLSI
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Also called NonFirst Normal Form
(NF2-) relations
q A Relation r of the relation schema R(A1, A2, ..., An):
A set of n-tuples, r (R) = { t1, t2, ... , tk },
where each t is an ordered set of values or relations = < v1, v2, ..., vn >
and where "i, vi Î dom(Ai) È null
CELL
{ [cell_id: string(20),
cell_name: string(20),
...
pdata:
] },
SEGMENT: < [
seg_id: string(20),
sdata: . . .
{ [ path_id:
INSTANCE: { [inst_id: string(20),
m_cell:
string(20),
idata:
...
] },
PATH:
cdata:
]}
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Lie
Dal
Nested relation - example
Gro
Per
INF102
INF101
Subject
2.4
2.3
1.5
Grade
2001/12/15
2001/06/15
2000/12/15
Date
{PATH}
.....
.....
C1
C1
C1
C1
C2
aaaa
bbbb
cccc
dddd
eeee
P1
P2
P3
P4
P5
P6
.....
.....
.....
.....
uuuu
s1
vvvv
s2
gggg
s3
.....
.....
.....
.....
kkkk
nnnn
oooo
pppp
qqqq
ssss
.....
zzzz
yyyy
xxxx
cdata
INF4180-beyondrel-62
Disadvantages?
Advantages?
INF101
Studentno FamilyName GivenName Exams
0864832
0343811
We need SQL-commands for
q Querying
q Flattening
I1
I2
I3
I4
I5
.....
INF4180-beyondrel-64
inst_id m_cell idata path_id <SEGMENT> pdata
seg_id sdata
{INSTANCE}
{CELL}
VLSI in nested relations
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q Deflattening (a kind of GROUP BY)
cell_id cell_name
CELL1
CELL2
C1
C2
CELL3
.....
C3
.....
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q LOBs can not be included in primary keys,
GROUP BY, ORDER BY
q LOBs can be compared using equality, inequality and
substring operations
q A LOB has a locator (similar to an OID)
o CLOB (character large object)
o BLOB (binary large object)
q Datatype LARGE OBJECT (LOB) with the two variants
Large object
INF4180-beyondrel-67
Part 1. SQL/Framework Introduction, 75 pages
Part 2. SQL/Foundation Core SQL, 1100 pages
Part 3. SQL/CLI Call-level interface (ODBC 3), 400 pages
Part 4. SQL/PSM Stored procedures, like Oracle PL/SQL, 160 pages
Part 5. SQL/Bindings Enbedded SQL and dynamic SQL, 250 pages
Part 6.
Part 7. SQL/Temporal Temporal data, ? pages
Part 8.
Part 9. SQL/MED Management of external data, ? pages
Part 10. SQL/OLB Object language bindings, ? pages, see ANSI
X3.135.10:1998
Part 11. SQL/Schemata - Part 5 SQL/Bindings and Part 2 SQL/Foundation
merged
AM1. SQL/OLAP - On-line transaction processing
SQL/MM - Multimedia
SQL/RDA - Remote data access, extension to Part 9
SQLJ - SQL and Java, see ANSI NCITS 331.n
Replication
SQL and XML
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
INF4180-beyondrel-65
Overview of SQL:1999 (SQL-3) standard ISO/IEC 9075-n:1999
The SQL:1999 Standard
IQ
IQ_t,
IQ = IQ * 2
set
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
IQ = IQ * cast(2 as IQ)
where shoesize > cast (IQ as shoesize)
If you really want to do such things, use explicit casting
set
where shoesize > IQ
makes calculations like this illegal:
);
shoesize shoesize_t,
create table person (
create distinct type IQ_t as integer;
create distinct type shoesize_t as integer;
Introduces (finally) NIAM-like LOTs into SQL
Distinct
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q Reference types
q Inheritance
q Structured types
q User defined abstract data types
o Distinct type
o Boolean
o Large object
q New basic types
A richer datatype system
INF4180-beyondrel-68
INF4180-beyondrel-66
A richer datatype system
q New basic types
q User defined abstract data types
o Atomic datatype inclusive type-specific operations
q Structured types
ADT-methods
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q Reference types
q Inheritance
q Required methods
o A method which enables the DBMS to read objects of this type
INF4180-beyondrel-69
or
FROM student
WHERE image.hasBrownHair;
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
INF4180-beyondrel-72
INF4180-beyondrel-70
Definition of an abstract data type - Example
CREATE ABSTRACT DATA TYPE jpg_image (
internalLength = VARIABLE,
input = in_jpg_image, // method to read objects
output = out_jpg_image, // method to write objects
);
CREATE TABLE Student (
name VARCHAR(30),
image jpg_image,
);
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Querying an ADT
Find all students with brown hair
SELECT *
WHERE hasBrownHair(image);
CREATE FUNCTION in_jpg_image( ) RETURNS jpg_image
AS EXTERNAL NAME Ô..../jpg.classÕ LANGUAGE Ô javaÕ ;
o A method which enables the DBMS to output objects of this type
CREATE FUNCTION out_jpg_image (jpg_image)
AS EXTERNAL NAME Ô..../jpg.classÕ LANGUAGE Ô javaÕ ;
SELECT *
FROM student
o A method which computes the amount of storage required to hold the object
CREATE FUNCTION size(jpg_image) RETURNS INTEGER
AS EXTERNAL NAME Ô..../jpg.classÕ LANGUAGE Ô javaÕ ;
q Optional metods
o All other useful metods for this datatype
INF4180-beyondrel-71
CREATE FUNCTION hasBrownHair(jpg_image) RETURNS BOOLEAN
AS EXTERNAL NAME Ô..../jpg.classÕ LANGUAGE Ô javaÕ ;
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
CREATE FUNCTION sameHairStyle(jpg_image, jpg_image)
RETURNS BOOLEAN
AS EXTERNAL NAME Ô..../jpg.classÕ LANGUAGE Ô javaÕ ;
INF4180-beyondrel-75
Encapsulation:
hiding of ADT
internals
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q How the methods work
q How an ADTÕs data are stored
What does the DBMS not know?
q Structured types (Collections)
q Input and output data types for the methods
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q Reference types
q Inheritance
q User defined abstract data types
q What methods are available
A richer datatype system
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q Distinct types
INF4180-beyondrel-73
o Transparent to user
INF4180-beyondrel-76
INF4180-beyondrel-74
o Use interprocess communication (IPC) to invoke methods
and receive data
o Run methods in a different address space that the DBMS
q Compiled methods
o Ensure safety of each step before executing
o Restrict the power of the interpreted language
q Interpreted methods
Buggy or malicious code must be prevented from causing
problems!
Method security
What does the DBMS know?
ADT Encapsulation
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q Methods are dynamically linked by the ORDBMS
q The method is written in some programming language, e.g.
Java
3) Inform the ORDBMS about its location, return data type, and
input data types
2) Compile the code into object code
1) Write the code for the method
How to register a new method
Definition of a collection - Example
CREATE TABLE Student (
name VARCHAR(30),
image jpg_image,
image
phone
phone CHAR(12) ARRAY [3] ;
);
name
INF4180-beyondrel-79
INF4180-beyondrel-77
Deviation from 1NF
(First Normal Form)?
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
ROW
CREATE TYPE student_t AS
ROW (
name VARCHAR(30),
image jpg_image,
phone CHAR(12) ARRAY [3] ;
);
CREATE TABLE Student of Student_t;
A traditional relation
is a setof(ROW)
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Not in SQL:1999
Available type constructors
q setof(<type>)
q bagof(<type>)
q listof(<type>)
q arrayof(<type>) / <type> ARRAY [size]
q ROW(<list of <field name> <type> >)
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Operators for collection types
q Sets and bags: intersection, union, difference, etc.
q Lists: head, tail, append, concatenate
q Arrays: [array_index]
q Rows: .nk the value tk of row(n1 t1, É, nn tn)
q All collection types
o aggregate operations like COUNT, SUM, MAX, MIN etc.
INF4180-beyondrel-78
o generator operations Ð
a 'looping construct' that generates each item in a collection Ð
typically used with GROUP BY
INF4180-beyondrel-80
The usual operators
are supported on
collection types.
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Redefinition of the supertypeÕs methods is possible (overloading)
Queries over students are also evaluated over graduatestudents
CREATE TABLE graduatestudents
OF TYPE graduatestudent_t UNDER students
INF4180-beyondrel-83
CREATE TYPE graduatestudent_t UNDER student_t (supervisor text)
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q Reference types
q Inheritance
q Structured types
q To create hierarchies of collections with similar but not identical
objects
Example
q User defined abstract data types
q To reuse and refine type definitions
A richer datatype system
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
q Distinct types
INF4180-beyondrel-81
q Reference types
q Inheritance
q Structured types
q User defined abstract data types
q Distinct types
A richer datatype system
Usages of inheritance
Inheritance
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
WHERE COUNT(phone) > 2;
FROM student
SELECT *
Retrieve students that have more than two phone numbers:
WHERE A.phone INTERSECT B.phone AND A.name < B.name;
FROM student AS A, student AS B
SELECT A.name, B.name, A.phone INTERSECT B.phone
Which students share a phone number?
Querying collections
INF4180-beyondrel-84
INF4180-beyondrel-82
Reference Types
q ÓObjectsÓ may have an OID
o Every tuple in a table gets an OID when defining the table in terms of a
structured type
o Large ÓobjectsÓ also have an OID (the locator)
o The OID is obtained by the special type constructor ref
o To get hold of the referenced ÓobjectÓ
deref
deref(A).f can be written as A->f
q SQL:1999 requires that
INF4180-beyondrel-85
o A given ref type must be associated with a specific structure type
o The table it refers to must be known at compilation time
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
The Ramakrishnan/Gehrke example
CREATE TABLE Frames (frameno integer, image jpeg_image,
category integer)
CREATE TABLE Categories (cid integer, name text, lease_price
float, comments text)
CREATE TYPE theater_t AS ROW (tno integer, name text, address
text, phone text)
CREATE TABLE Theaters OF TYPE theater_t WITH IDENTITY;
INF4180-beyondrel-87
CREATE TABLE Nowshowing (film integer, theater
ref(theater_t)with scope Theaters, start date, end date)
CREATE TABLE Films (filmno integer, title text, stars
setof(text), director text, budget float)
CREATE TABLE Countries (name text, boundary polygon,
population integer, language text);
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Reference type - example
CREATE TABLE students OF TYPE student_t WITH IDENTITY;
here, each row has a unique identity (an OID)
We may now create another table with references to some of the
rows:
CREATE TABLE xxx
ÉÉ.
fulltime_student ref(student_t) with scope students
ÉÉÉ
INF4180-beyondrel-86
A flavour of
Óobject oriented objectsÓ
Ð but É
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
SQL:1999 Ð not only new datatypes
q New predicates
o SIMILAR (cousin of LIKE),
INF4180-beyondrel-88
o UNIQUE (cousin of DISTINCT, handles null-values differently)
q Recursive queries
q Standardization of triggers
q Standardization of improved access control (DCL)
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
1970
GML
General
Markup
Language
1990
HTML (89 - 92)
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
1980
SGML (83 - 86)
- OMA
- CORBA
- IDL
OMG V.1 (91)
- ODL
- OQL
- OML
Apparent connection
INF4180-beyondrel-89
INF4180-beyondrel-91
Object Adapter
Data net
2000
XML (96 - )
SemiSemistructured
structured
databases
databases
CORBA 3.x (00)
Object/Datastandards
fusion ?
Server object
(callee)
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Real connection
SQL-3 (99)
ODMG V1.0 (93) ODMG V3.0 (00)
Object
Object
relational
relational
databases
databases
SQL-2 (92)
Hiding the distribution
Server object
surrogate
Data net
Object
Object
oriented
oriented
databases
databases
Object oriented
distributed systems
SMALLTALK
C++
EIFFEL
Client object
(caller)
SIMULA (62 - )
Extended relational
databases
Persistent distributed objects
Relational
Relational
databases
databases
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
INF4180-beyondrel-90
The key to the architecture of
distributed object-oriented
systems!
methods
state
(attributes
with values,
relationships)
Object-name
Common Facilities
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
Object Services
Object Request Broker
Application Objects
INF4180-beyondrel-92
OMGÕs Object Management Architecture
messages
interface
OID
Separating interface from object
INF4180-beyondrel-93
More about this in a later
lecture!
Object services Ð Persistent state service
q Life Cycle service
q Persistent state service
q Naming service
q Event service
q Concurrency Control service
q Transaction service
q Relationship service
q Externalisation service
q Query service
q Licensing service
q Properties service
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
INF4180-beyondrel-95
Extensible Markup
Language
XML Ð an example
<?xml version="1.0"?>
<purchaseOrder orderDate="1999-10-20">
<shipTo country="US">
<name>Alice Smith</name>
<street>123 Maple Street</street>
<city>Mill Valley</city>
<state>CA</state>
<zip>90952</zip>
</shipTo>
<billTo country="US">
<name>Robert Smith</name>
<street>8 Oak Avenue</street>
<city>Old Town</city>
<state>PA</state>
<zip>95819</zip>
</billTo>
<comment>Hurry, my lawn is going wild!</comment>
<items>
<item partNum="872-AA">
<productName>Lawnmower</productName>
<quantity>1</quantity>
<USPrice>148.95</USPrice>
<comment>Confirm this is electric</comment>
</item>
<item partNum="926-AA">
<productName>Baby Monitor</productName>
From:
<quantity>1</quantity>
XML Schema Part 0: Primer
<USPrice>39.98</USPrice>
W3C Recommendation, 2 May 2001
<shipDate>1999-05-21</shipDate>
</item>
http://www.w3.org/TR/2001/
</items>
REC-xmlschema-0-20010502/primer.html
</purchaseOrder>
SMALLTALK
C++
EIFFEL
SQL-2 (92)
Object
Object
relational
relational
databases
databases
SQL-3 (99)
INF4180-beyondrel-94
2000
XML (96 - )
SemiSemistructured
structured
databases
databases
CORBA 3.x (00)
Object/Datastandards
fusion ?
ODMG V1.0 (93) ODMG V3.0 (00)
- ODL
- OQL
- OML
OMG V.1 (91)
- OMA
- CORBA
- IDL
HTML (89 - 92)
1990
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
1980
SGML (83 - 86)
Object oriented
distributed systems
Object
Object
oriented
oriented
databases
databases
Extended relational
databases
Semistructured (text)-databases
Relational
Relational
databases
databases
SIMULA (62 - )
GML
General
Markup
Language
1970
INF4180-beyondrel-96
Well-formed and valid XML-documents
q An XML-document is well-formed if it satisfies simple
syntactic constraints,
i. e. proper nesting of start and end tags
q Stronger constraints may be imposed by
a Document Type Definition (DTD) or
an XML Schema
q An XML-document is then valid with regard to a certain
DTD or a certain XML Schema
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
INF4180-beyondrel-97
</xsd:schema>
</xsd:simpleType>
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
INF4180-beyondrel-99
http://www.w3.org/TR/2001/
REC-xmlschema-0-20010502/primer.html
<!-- Stock Keeping Unit, a code for identifying products -->
<xsd:simpleType name="SKU">
From:
<xsd:restriction base="xsd:string">
XML Schema Part 0: Primer
<xsd:pattern value="\d{3}-[A-Z]{2}"/>
W3C Recommendation, 2 May 2001
</xsd:restriction>
<xsd:complexType name="Items">
<xsd:sequence>
<xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="productName" type="xsd:string"/>
<xsd:element name="quantity">
<xsd:simpleType>
<xsd:restriction base="xsd:positiveInteger">
<xsd:maxExclusive value="100"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="USPrice" type="xsd:decimal"/>
<xsd:element ref="comment" minOccurs="0"/>
<xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="partNum" type="SKU" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
XML-Schema(Part 2)
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
<!-- ========= purchaseOrder ========== -->
<!ELEMENT purchaseOrder (shipTo, billTo, items)>
<!ATTLIST purchaseOrder orderDate #REQUIRED>
<!ELEMENT shipTo (name, street, city, state, zip)>
<!ATTLIST shipTo country #REQUIRED>
<!ELEMENT name (#PCDATA)>
<!ELEMENT street (#PCDATA)>
<!ELEMENT city (#PCDATA)>
<!ELEMENT state (#PCDATA)>
<!ELEMENT zip (#PCDATA)>
ÉÉÉ
Document Type Definition Ð DTD
XPointer & XFragments (also still being developed) are syntaxes for pointing to parts of an XML
document. (An XPointer is a bit like a URL, but instead of pointing to documents on the Web, it
points to pieces of data inside an XML file.)
CSS, the style sheet language, is applicable to XML as it is to HTML. XSL (autumn 1999) is the
advanced language for expressing style sheets. It is based on XSLT, a transformation language
that is often useful outside XSL as well, for rearranging, adding or deleting tags & attributes.
The DOM is a standard set of function calls for manipulating XML (and HTML) files from a
programming language.
XML Namespaces is a specification that describes how you can associate a URL with every
single tag and attribute in an XML document. What that URL is used for is up to the application
that reads the URL, though. (RDF, W3C's standard for metadata, uses it to link every piece of
metadata to a file defining the type of that data.)
XML Schemas 1 and 2 help developers to precisely define their own XML-based formats.
q
q
q
q
q
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
INF4180-beyondrel-100
From: XML in 10 points
http://www.w3.org/XML/1999/XML-in-10-points
There is, e.g., Xlink (still in development as of November 1999), which describes a standard way
to add hyperlinks to an XML file.
q
XML in short
There is XML 1.0, the specification that defines what "tags" and "attributes" are, but around XML
1.0, there is a growing set of optional modules that provide sets of tags & attributes, or
guidelines for specific tasks.
q
<xsd:complexType name="USAddress">
From:
<xsd:sequence>
XML Schema Part 0: Primer
<xsd:element name="name" type="xsd:string"/>
W3C Recommendation, 2 May 2001
<xsd:element name="street" type="xsd:string"/>
<xsd:element name="city" type="xsd:string"/>
http://www.w3.org/TR/2001/
<xsd:element name="state" type="xsd:string"/>
REC-xmlschema-0-20010502/primer.html
<xsd:element name="zip" type="xsd:decimal"/>
</xsd:sequence>
<xsd:attribute name="country" type="xsd:NMTOKEN"
fixed="US"/>
</xsd:complexType>
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
INF4180-beyondrel-98
<xsd:complexType name="PurchaseOrderType">
<xsd:sequence>
<xsd:element name="shipTo" type="USAddress"/>
<xsd:element name="billTo" type="USAddress"/>
<xsd:element ref="comment" minOccurs="0"/>
<xsd:element name="items" type="Items"/>
</xsd:sequence>
<xsd:attribute name="orderDate" type="xsd:date"/>
</xsd:complexType>
<xsd:element name="purchaseOrder" type="PurchaseOrderType"/>
<xsd:element name="comment" type="xsd:string"/>
<xsd:annotation>
<xsd:documentation xml:lang="en">
Purchase order schema for Example.com.
Copyright 2000 Example.com. All rights reserved.
</xsd:documentation>
</xsd:annotation>
XML Schema (Part 1)
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
Two uses of XML with databases
Is a native XML database a ÒdatabaseÓ ?
q Storage of data (XML-documents)
We have
o Finally a ÒstandardÓ
q Schemas (DTD, XML schema)
q As a Òlangua francaÓ between databases
o But subject-oriented tags must be defined
q Query languages (Xquery, Xpath, XQL, XML-QL, QUILT, É )
We donÕt have
q Queries across multiple documents
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
INF4180-beyondrel-102
XML is hierarchical Ð isnÕt this a step
back to the 60ties?
XML-documents without
schema or DTD is OK ?
Too much knowledge in the application?
q Programming interfaces (SAX, DOM, JDOM, É)
o Native XML-database
q Transactions
q Data integrity
§ schema language
q Multi-user access
CORBA 3.x (00)
SemiSemistructured
structured
databases
databases
XML (96 - )
?
2000
INF4180-beyondrel-103
q Indexing
§ query language
o Do we need still another type of database?
q Storing XML-documents in the database
o Is text-format a good idea (binaries in MIME *) ) ?
INF4180-beyondrel-101
q Security
SQL-2 (92)
Object
Object
relational
relational
databases
databases
- ODL
- OQL
- OML
OMG V.1 (91)
- OMA
- CORBA
- IDL
HTML (89 - 92)
1990
Object/Datastandards
fusion ?
ODMG V1.0 (93) ODMG V3.0 (00)
SQL-3 (99)
§ API
SMALLTALK
C++
EIFFEL
1980
SGML (83 - 86)
Object oriented
distributed systems
Object
Object
oriented
oriented
databases
databases
Extended relational
databases
The story goes onÉ
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001
*) Multipurpose Internet Mail Extension
Relational
Relational
databases
databases
SIMULA (62 - )
GML
General
Markup
Language
1970
© Institutt for informatikk 2003Ð Gerhard Skagestein 15. Aug. 2001