28
Database Management Peter Wood Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational Database Features Why has the relational model been so successful? I Data independence I High level query language - SQL I Query optimisation I Support for integrity constraints I Well-understood database design I Transaction management and concurrency

Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

  • Upload
    others

  • View
    15

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Relational Database Features

Why has the relational model been so successful?I Data independenceI High level query language - SQLI Query optimisationI Support for integrity constraintsI Well-understood database designI Transaction management and concurrency

Page 2: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Relational Database Limitations

1. all data is value-based - all relationships areexpressed through common values

2. data must always be represented in ’flat’ (first normalform) relations

3. for some applications, performance is not fastenough

I Limitations 1 and 2 led to the development ofobject-oriented and object-relational databases

I Limitations 2 and 3 led to the development of NoSQLdatabases

Page 3: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Relational Database Limitations

1. all data is value-based - all relationships areexpressed through common values

2. data must always be represented in ’flat’ (first normalform) relations

3. for some applications, performance is not fastenough

I Limitations 1 and 2 led to the development ofobject-oriented and object-relational databases

I Limitations 2 and 3 led to the development of NoSQLdatabases

Page 4: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Why might we need Object-OrientedDatabases?

I For some applications 1NF is too strict.I Document management and web site managementI Geographic and statistical dataI Biological dataI . . .

I All these use complex (nested) objects of some form,where object identity and references help

Page 5: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Object-Oriented Databases

Support

I object identityI complex object structuresI classes and inheritanceI object encapsulation (methods for object

manipulation)I high-level query language (OQL)I . . .

Page 6: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Object-Relational Databases

Object-relational systems (and SQL:1999) add a numberof object-oriented features to relational systems,including:

I user-defined typesI type inheritanceI table inheritanceI array and multiset typesI object identityI reference typesI methods

We will consider the first four of these briefly below.

Page 7: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Creating User-Defined Types

CREATE TYPE NameType AS (firstname varchar(20),lastname varchar(20))FINAL;

CREATE TYPE AddressType AS (street varchar(20),city varchar(20)postcode varchar(8))NOT FINAL;

FINAL and NOT FINAL relate to subtyping (see later)

Page 8: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Using User-Defined Types

CREATE TABLE person (name NameType,address AddressType,dateOfBirth date);

Note that the above table definition uses the user-definedtypes NameType and AddressType, along with the built-intype date

An SQL example using the above definition is:

SELECT name.firstname, name.lastname FROM person;

Page 9: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Using User-Defined Types

CREATE TABLE person (name NameType,address AddressType,dateOfBirth date);

Note that the above table definition uses the user-definedtypes NameType and AddressType, along with the built-intype date

An SQL example using the above definition is:

SELECT name.firstname, name.lastname FROM person;

Page 10: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Type Inheritance

CREATE TYPE PersonType (name NameType,address AddressType)NOT FINAL;

CREATE TYPE StudentType UNDER PersonType (degree varchar(20),department varchar(20))FINAL;

StudentType is a subtype of PersonType.

NOT FINAL means the type can have subtypes.

FINAL means the type cannot have subtypes.

StudentType inherits the attributes of PersonType.

Page 11: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Table Inheritance

CREATE TABLE person OF PersonType;

CREATE TABLE student OF StudentType UNDER person;

Table student will have all attributes of StudentType(which includes those of PersonType).

Every tuple in student is implicitly also in person, so

SELECT * FROM person

retrieves all person tuples, including student tuples.

Page 12: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Table Inheritance

CREATE TABLE person OF PersonType;

CREATE TABLE student OF StudentType UNDER person;

Table student will have all attributes of StudentType(which includes those of PersonType).

Every tuple in student is implicitly also in person, so

SELECT * FROM person

retrieves all person tuples, including student tuples.

Page 13: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Array and Multiset TypesMultiset (a set with possibly duplicate elements) typeswere added in SQL:2003.

CREATE TYPE Book AS (title varchar(20),authors varchar(20) array [10],keywords varchar(20) multiset)NOT FINAL;

CREATE TABLE books OF Book;

INSERT INTO booksVALUES (’Database System Concepts’,

array[’Silberschatz’, ’Korth’, ’Sudarshan’],multiset[’computer’, ’database’, ’SQL’]);

SELECT authors[1] FROM booksWHERE ’database’ IN (UNNEST(keywords));

Page 14: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Array and Multiset TypesMultiset (a set with possibly duplicate elements) typeswere added in SQL:2003.

CREATE TYPE Book AS (title varchar(20),authors varchar(20) array [10],keywords varchar(20) multiset)NOT FINAL;

CREATE TABLE books OF Book;

INSERT INTO booksVALUES (’Database System Concepts’,

array[’Silberschatz’, ’Korth’, ’Sudarshan’],multiset[’computer’, ’database’, ’SQL’]);

SELECT authors[1] FROM booksWHERE ’database’ IN (UNNEST(keywords));

Page 15: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Array and Multiset TypesMultiset (a set with possibly duplicate elements) typeswere added in SQL:2003.

CREATE TYPE Book AS (title varchar(20),authors varchar(20) array [10],keywords varchar(20) multiset)NOT FINAL;

CREATE TABLE books OF Book;

INSERT INTO booksVALUES (’Database System Concepts’,

array[’Silberschatz’, ’Korth’, ’Sudarshan’],multiset[’computer’, ’database’, ’SQL’]);

SELECT authors[1] FROM booksWHERE ’database’ IN (UNNEST(keywords));

Page 16: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

NoSQL

I NoSQL stands for “Not only SQL”I Used to refer to various approaches which are

non-relationalI These include

I Key-value storesI XML databasesI Document storesI Graph databases

Page 17: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

NoSQL Systems

I Offer scalability and extensibility overloosely-coupled clusters of commodity hardware.

I As a result, they are often used in large-scaleweb-based applications.

I They typically do not offer the extensive transactionmanagement (ACID) capabilities of RDBMSs.

Page 18: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Key-value Stores

I Used by Amazon, e.g., for high availabilityI see the paper “Dynamo: Amazon’s Highly Available

Key-Value Store” (2007), published in ACMSymposium on Operating System Principles

I A key-value store enables the storage and retrieval ofvalues by key.

I It is essentially a big hash table.I The values are simply sequences of bytes.I It is up to an application to interpret any logical

structure within the values.I An example system is Redis (www.redis.io)

Page 19: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

XML Databases

I Data model is that of XML (elements and attributes).I XML allows for flexible, nested structures (no

schema is necessary).<friends><person><name>Alice</name><email>alice@...</email>

</person><person><name>Bob</name><phone>012...</phone>

</person></friends>

I The query language is usually XQuery(www.w3.org/TR/xquery-30).

I An example system is eXist (www.exist-db.org).

Page 20: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Document StoresI Like a key-value store, a document store enables the

storage and retrieval of values by key.I In this case, the values do have structure (each is a

“document”).I The syntax used for documents is usually JSON

(JavaScript Object Notation).{ "friends": [{ "person":{ "name": "Alice", "email": "alice@..." }

},{ "person":{ "name": "Bob", "phone": "012..." }

}]

}I An example system is MongoDB

(www.mongodb.org).

Page 21: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Graph Example

A graph of airports and flight durations:

LHR

CDGJFK MAD

LIM SCL

172

812 14

4

14

Nodes represent airportsEdges represent flight connectionse.g., it takes 7 hours to fly between London Heathrow andJFK (New York)

Page 22: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Graph Databases

I A graph store represents information in a graphconsisting of nodes and edges.

I Nodes and edges both typically have propertiesassociated with them.

I Common queries in graphs involve findingconnections (paths) between nodes.

I An example system is Neo4j (www.neo4j.com).I Neo4j uses its own query language called Cypher.

Page 23: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Paradise Papers Example

I Paradise Papers areI a trove of leaked documents from a law firm and trust

companyI showing people and organisations using shell

companies in tax havens and offshore jurisdictionsI to hide, move and spend huge amounts of money

I in 2017, the ICIJ (International Consortium ofInvestigative Journalists) used Neo4j to analyse them

I see https://neo4j.com/blog/analyzing-paradise-papers-neo4j/

Page 24: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Paradise Papers Data ModelThe data model for the Paradise Papers is as follows:

Page 25: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Cypher Query

I discovered that the Queen’s estate (The Duchy ofLancaster) had previously unknown investments

I the following Cypher queryMATCH p=(o:Officer

{name: "The Duchy of Lancaster"})-[*..2]-()

RETURN p

returns paths of length up to 2 from the node of typeOfficer with name “The Duchy of Lancaster”

I node patterns are specified by ()I relationship patterns are specified by []

Page 26: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Query Result

The result of the query is as follows:

Page 27: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Summary

I Performance requirements may force you to adopt asimpler data model and/or do without ACIDguarantees, e.g.,

I a key-value storeI a document store

I Complex and/or uncertain data requirements maysuggest a more complex and/or flexible data model isneeded, e.g.,

I object(-relational) databaseI XML databaseI graph database

Page 28: Relational Database Features Management Databaseptw/teaching/DBM/non-relational.pdf · Non-Relational Databases Object-oriented and object-relational databases No SQL databases Relational

DatabaseManagement

Peter Wood

Non-RelationalDatabases

Object-orientedandobject-relationaldatabases

No SQL databases

Summary

I Performance requirements may force you to adopt asimpler data model and/or do without ACIDguarantees, e.g.,

I a key-value storeI a document store

I Complex and/or uncertain data requirements maysuggest a more complex and/or flexible data model isneeded, e.g.,

I object(-relational) databaseI XML databaseI graph database