Information Systems Engineering Other Database Concepts 1
Views In a database it is possible to create virtual tables called views Views are not stored in the database They are defined and computed from the tables in the database schema through a SELECT statement They can be referenced and queried as normal tables They are computed at the time of use Under certain restrictions they support modification statements (INSERT, UPDATE, DELETE) transmitting the modifications to the underlying real tables The modified attributes should be linked to only one base table Columns resulting from any computation, aggregation, grouping, having condition or distinct are not allowed to be modified MIB - ESIN apm@feup 2
Views (2) Views are defined by a CREATE VIEW SQL statement Views have a name that should be different from any table The database stores only the view definition The CREATE VIEW statement is defined as CREATE VIEW <view-name> [(<col-name> n )] AS <select-statement> If the list of <col-name> is present, the attributes are renamed for those names The number must match the attributes produced by the <select-statement> MIB - ESIN apm@feup 3
Example Consider the Movies table already seen Movies(title, year, length, genre, studio, producer_id) We can define a view representing the movies made by Paramount CREATE VIEW ParamountMovies AS SELECT title, year FROM Movies WHERE studio = Paramount If we want the Movies made by Paramount in 1979 we can emit the following statement SELECT title FROM ParamountMovies WHERE year = 1979 MIB - ESIN apm@feup 4
Other examples Considering Movies(title, year, length, genre, studio, producer_id) MovieExec(id, name, address, netsalary) We can have a virtual table with renaming CREATE VIEW MovieProd(movie, producer) AS SELECT title, name FROM Movies, MovieExec WHERE producer_id = id If we want the actors from Paramount movies Make a query involving ParamountMovies SELECT DISTINCT starname FROM ParamountMovies, StarsIn WHERE title = movie AND year = movieyear Using a view with other tables is the same as using a subquery MIB - ESIN apm@feup 5
Triggers A trigger is a sequence of SQL statements (the action) that is automatically executed whenever another INSERT, UPDATE or DELETE statement (the event), affecting a table or view, is executed Triggers have names and are stored in the database The action can be executed after the event (only if it is successful) or instead of it The action can contain a condition It is possible to access the values that have disappeared in the event (deleted virtual table) or the newly created (inserted virtual table) MIB - ESIN apm@feup 6
Trigger definition A trigger is created in SQL as CREATE TRIGGER <name> ON { <table> <view> } { AFTER INSTEAD OF } { [INSERT][,][UPDATE][,][DELETE] } AS <sql_statement> The <sql_statement> can be a composed statement, i.e. a list of statements between BEGIN and END It can also be a IF <condition> statement or any other allowed in SQL Server Triggers can help in the verification and correction of constraints In the case of views, they can promote not allowed modifications, replacing simple statements with other more complex but accomplishing the modifications MIB - ESIN apm@feup 7
Example In the SkyClub database we want to automatically promote the skill level of a member to Advanced, whenever they complete 18 jumps We can define a trigger for that, executing on UPDATE statements Such a trigger could be CREATE TRIGGER AdvancedSkill ON SkyMember AFTER UPDATE AS BEGIN UPDATE SkyMember SET skill = A WHERE email IN (SELECT email FROM inserted WHERE jumps >= 18) PRINT Possible promotions done END MIB - ESIN apm@feup 8
Transactions A transaction allows to execute a set of SQL statements as if it were a single and indivisible statement If any of the composing statements fails nothing is changed in the database (all intermediate modifications are rolled back) A transaction must verify the so called ACID properties A (Atomicity) All statements inside a transaction act as a single and indivisible one C (Consistency) Before and after the transaction the database is in a consistent state I (Isolation) Possible temporary inconsistences are not seen by other statements D (Durability) After a successful transaction data is already persisted MIB - ESIN apm@feup 9
Transactions in SQL A transaction begins with BEGIN TRANSACTION [<name>] It ends with COMMIT TRANSACTION [<name>] Transaction successful and modifications persisted ROLLBACK TRANSACTION [<name>] Transaction failed and all modifications are undone The programmer must know the conditions for success or failure and write one of the endings Immediately after the execution of a statement Consult variables @@rowcount or @@error Use the constructions BEGIN TRY END TRY and BEGIN CATCH END CATCH MIB - ESIN apm@feup 10
Transactions in SQL (2) Generic constructions BEGIN TRANSACTION BEGIN TRY /* SQL statements */ COMMIT TRANSACTION END TRY BEGIN CATCH ROLLBACK TRANSACTION END CATCH BEGIN TRANSACTION /* SQL statement */ IF @@rowcount = 0 BEGIN ROLLBACK TRANSACTION RETURN END /* SQL statement */ IF @@error <> 0 BEGIN ROLLBACK TRANSACTION RETURN END COMMIT TRANSACTION MIB - ESIN apm@feup 11
Example From a bank database we have the following relation representing accounts: Accounts(acctNo, balance) A transfer of money from one account to another should be in a transaction DECLARE @amount money = 100.00; BEGIN TRANSACTION UPDATE Accounts SET balance = balance + @amount WHERE acctno = 456; IF @@rowcount = 0 BEGIN ROLLBACK TRANSACTION RETURN END UPDATE Accounts SET balance = balance - @amount WHERE acctno = 123; IF @@rowcount = 0 BEGIN ROLLBACK TRANSACTION RETURN END COMMIT TRANSATION MIB - ESIN apm@feup 12