Relational Database Features

Transcription

1 Relational Features s Why has the relational model been so successful? Data independence High level query language - SQL Query optimisation Support for integrity constraints Well-understood database design Transaction management concurrency No SQL

2 Relational Limitations 1. all data is value-based - all relationships are expressed through common values 2. data must always be represented in flat (first normal form) relations 3. for some applications, performance is not fast enough s No SQL

3 Relational Limitations 1. all data is value-based - all relationships are expressed through common values 2. data must always be represented in flat (first normal form) relations 3. for some applications, performance is not fast enough s No SQL Limitations 1 2 led to the development of object-oriented Limitations 2 3 led to the development of NoSQL

4 Why might we need Object-Oriented s? For some applications 1NF is too strict. Document management web site management Geographic statistical data Biological data... s No SQL All these use complex (nested) objects of some form, where object identity references help

5 Object-Oriented s s Support object identity complex object structures classes inheritance object encapsulation (methods for object manipulation) high-level query language (OQL)... No SQL

6 Object-Relational s Object-relational systems ( SQL:1999) add a number of object-oriented features to relational systems, including: user-defined types type inheritance table inheritance array multiset types object identity reference types methods We will consider the first four of these briefly below. s No SQL

7 Creating User-Defined Types CREATE TYPE NameType AS ( firstname varchar(20), lastname varchar(20)) FINAL; s No SQL CREATE TYPE AddressType AS ( street varchar(20), city varchar(20) postcode varchar(8)) NOT FINAL; FINAL NOT FINAL relate to subtyping (see later)

8 Using User-Defined Types s CREATE TABLE person ( name NameType, address AddressType, dateofbirth date); No SQL Note that the above table definition uses the user-defined types NameType AddressType, along with the built-in type date

9 Using User-Defined Types s CREATE TABLE person ( name NameType, address AddressType, dateofbirth date); No SQL Note that the above table definition uses the user-defined types NameType AddressType, along with the built-in type date An SQL example using the above definition is: SELECT name.firstname, name.lastname FROM person;

10 Type Inheritance CREATE TYPE PersonType ( name NameType, address AddressType) NOT FINAL; CREATE TYPE StudentType UNDER PersonType ( degree varchar(20), department varchar(20)) FINAL; s No SQL 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.

11 Table Inheritance s CREATE TABLE person OF PersonType; CREATE TABLE student OF StudentType UNDER person; No SQL Table student will have all attributes of StudentType (which includes those of PersonType).

12 Table Inheritance s CREATE TABLE person OF PersonType; CREATE TABLE student OF StudentType UNDER person; No SQL 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.

13 Array Multiset Types Multiset (a set with possibly duplicate elements) types were added in SQL:2003. CREATE TYPE Book AS ( title varchar(20), authors varchar(20) array [10], keywords varchar(20) multiset) NOT FINAL; s No SQL CREATE TABLE books OF Book;

14 Array Multiset Types Multiset (a set with possibly duplicate elements) types were added in SQL:2003. CREATE TYPE Book AS ( title varchar(20), authors varchar(20) array [10], keywords varchar(20) multiset) NOT FINAL; s No SQL CREATE TABLE books OF Book; INSERT INTO books VALUES ( System Concepts, array[ Silberschatz, Korth, Sudarshan ], multiset[ computer, database, SQL ]);

15 Array Multiset Types Multiset (a set with possibly duplicate elements) types were added in SQL:2003. CREATE TYPE Book AS ( title varchar(20), authors varchar(20) array [10], keywords varchar(20) multiset) NOT FINAL; s No SQL CREATE TABLE books OF Book; INSERT INTO books VALUES ( System Concepts, array[ Silberschatz, Korth, Sudarshan ], multiset[ computer, database, SQL ]); SELECT authors[1] FROM books WHERE database IN (UNNEST(keywords));

16 NoSQL s NoSQL sts for Not only SQL Used to refer to various approaches which are non-relational These include Key-value stores XML Document stores Graph No SQL

17 NoSQL Systems s Offer scalability extensibility over loosely-coupled clusters of commodity hardware. As a result, they are often used in large-scale web-based applications. They typically do not offer the extensive transaction management (ACID) capabilities of RDBMSs. No SQL

18 Key-value Stores Used by Amazon, e.g., for high availability see the paper Dynamo: Amazon s Highly Available Key-Value Store (2007), published in ACM Symposium on Operating System Principles A key-value store enables the storage retrieval of values by key. It is essentially a big hash table. The values are simply sequences of bytes. It is up to an application to interpret any logical structure within the values. An example system is Redis ( s No SQL

19 XML s Data model is that of XML (elements attributes). XML allows for flexible, nested structures (no schema is necessary). s <friends> <person> <name>alice</name>< >alice@...</ > </person> <person> <name>bob</name><phone>012...</phone> </person> </friends> The query language is usually XQuery ( An example system is exist ( No SQL

20 Document Stores Like a key-value store, a document store enables the storage retrieval of values by key. In this case, the values do have structure (each is a document ). The syntax used for documents is usually JSON (JavaScript Object Notation). { "friends": [ { "person": s { "name": "Alice", " ": "alice@..." } }, { "person": { "name": "Bob", "phone": "012..." } } ] } An example system is MongoDB ( No SQL

21 Graph Example A graph of airports flight durations: LHR s No SQL JFK 8 MAD LIM SCL 4 14 CDG Nodes represent airports Edges represent flight connections e.g., it takes 7 hours to fly between London Heathrow JFK (New York)

22 Graph s s A graph store represents information in a graph consisting of nodes edges. Nodes edges both typically have properties associated with them. Common queries in graphs involve finding connections (paths) between nodes. An example system is Neo4J ( Neo4J uses its own query language called Cypher. No SQL

23 Summary s Performance requirements may force you to adopt a simpler data model /or do without ACID guarantees, e.g., a key-value store a document store No SQL

24 Summary s Performance requirements may force you to adopt a simpler data model /or do without ACID guarantees, e.g., a key-value store a document store Complex /or uncertain data requirements may suggest a more complex /or flexible data model is needed, e.g., object(-relational) database XML database graph database No SQL