Introduction to Database Systems

RHS – Why databases are important Because we use databases all the time!! –Google –Youtube –Facebook –E-shopping –Banking Almost all private and official organisations use databasers, one way or another Databases!

RHS – Why databases are important What is it, actually…? –A database is just a well- structured collection of data, where data can be easily stored and retrieved Why is that useful…? –Data becomes information –Information becomes knowledge –Knowledge becomes wisdom

RHS – Types of Databases There are several types of database- systems: –Hierachical databases –Network-databases –Object-oriented databases –Relational databases Relational databases is by far the most common type, we will concentrate on that type in the following

RHS – Types of Databases Relational databases are (still) the most common type of database… …but does not fit perfectly with the object- oriented paradigm Mapping from object model to relational model is a very common task Why is this so…? Inertia, probably…

RHS – A database system is often called DBMS Data Base Management System

RHS – What is a DBMS…? A DBMS is the database itself, plus a number of programs used for interaction and maintenance of the database –Backup, restore –Performance monitoring –User interface –Interfaces to other programs –Etc.

RHS – Computer What is a DBMS…? Database Maintenance Performance User Interface Driver

RHS – Computer What is a DBMS…? Database Maintenance Performance User Interface Driver

RHS – Computer What is a DBMS…? Database Maintenance Performance User Interface Driver

RHS – What is a DBMS…? The exact physical configuration of database and programs is not as such important – it is a matter of setup No difference in functionality It is more relevant to think of such a system in terms of layers

RHS – What is a DBMS…? User Interface Maintenance Performance Driver Database Business Logic Data processing User inter- face layer Business logic layer DBMS layer

RHS – What is a DBMS…? A multi-layer (or multi-tier) structure is well suited for the Internet! Database on a central server, user interface through an Internet browser We use that every day! –Facebook –Net-banking –World of Warcraft…

RHS – DBMS – a closer look In many environments, it is absolutely critical that the DBMS functions perfectly! –Financial systems –Emergency systems –Traffic Perfectly – no persistent errors must become visible to the outside world

RHS – DBMS – a closer look Many functions in a DBMS handle error management and prevention –Transaction support –Concurrency management –Recovery services –Authorisation services –Integrity services

RHS – DBMS – Transactions A transaction is a set of changes to the state of the database Before the transaction, the database is in a valid and consistent state After the transaction, the database is in a valid and consistent state Example: Bank transfer

RHS – DBMS – Transactions Account A: Account B: Transfers history: Transfer 5000 From A to B

RHS – DBMS – Transactions Account A: Account B: Transfers history: Step 1: Deduct 5000 from A

RHS – DBMS – Transactions Account A: Account B: Transfers history: Step 2: Deposit 5000 to B

RHS – DBMS – Transactions Account A: Account B: Transfers history: Step 3: Update transfers history

RHS – DBMS – Transactions Account A: Account B: Transfers history: Transferred 5000 from A to B

RHS – DBMS – Transactions What if… –Power goes out between Step 1 and 2 –A disk error occurs –…–… In any case, the database could be left in an inconsistent state! For a transaction, either none or all of the steps must be completed

RHS – DBMS – Transactions In general, transactions must be ACID: –Atomic – either all steps or none –Consistent – leaves the database in a consistent state –Isolated – other processes cannot see a transaction ”in progress” –Durable – the change is permanent (but the affected data may of course be updated later)

RHS – DBMS – Concurrency Concurrency management is somewhat related to transaction The DBMS must be able to allow multiple clients concurrent access to the database No problem when reading data Becomes tricky when clients are writing data…

RHS – DBMS – Concurrency The DBMS must ”lock” certain parts of the data in the database, when a uses wants to update it May cause requests to queue up… Conflicting goals: –Ensure consistency (lock enough) –Ensure efficiency (lock only what is needed)

RHS – DBMS – Recovery In case of failure (of any kind), the DBMS must be able to recover the database Recover: When DBMS is back online, the database must be in a consistent state Often achieved by using duplicate databases, either online or offline Online duplicate enables immediate recovery

RHS – DBMS – Authorisation Many databases contain sensitive data We may wish to limit the actions a specific user can perform on the database Such user rights can be defined on several levels

RHS – DBMS – Authorisation User rights –Only read data, or read and write –Only work with certain parts of data –Only do certain updates to data –Only allowed to do maintenance –And so on… User rights are often defined in terms of defining user roles

RHS – DBMS – Authorisation Role Actions Admini- strator Mainte- nance Super-userManagerEmpolyee Add/delete tables YesNo Make Backup Yes No Write data YesNoYesNo Write data (predefined) YesNoYes No Read data YesNoYes

RHS – DBMS – Integrity Data can be incorrect on multiple levels Each piece of data can be correct as such, but a collection of data might be inconsistent Can be handled using constraints on data

RHS – DBMS – Integrity A constraint can specify cross-field consistency rules ”Sum of fields may not exceed value in field 1” ”Field 2 must at most be half of field 1” Updates that will break a constraint are not allowed by the DBMS