Scribd
Upload
2 views4 pages

423193_LABTASK10_4_April_2025

The document outlines the creation and management of a bank database, including transaction handling with SAVEPOINTS and ROLLBACK commands. It also describes a company database with role-based access control (RBAC) for users and the implications of granting and revoking privileges. Key points include the behavior of transactions, the effects of COMMIT and ROLLBACK, and the management of user roles and permissions.

Uploaded by

823122
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
2 views4 pages

423193_LABTASK10_4_April_2025

The document outlines the creation and management of a bank database, including transaction handling with SAVEPOINTS and ROLLBACK commands. It also describes a company database with role-based access control (RBAC) for users and the implications of granting and revoking privileges. Key points include the behavior of transactions, the effects of COMMIT and ROLLBACK, and the management of user roles and permissions.

Uploaded by

823122
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

ROLL NO: 423193

1. bank database stores customer transactions. If any transaction fails, the system should
rollback to a safe point instead of undoing everything.
BankAccounts (AccountID, Name, Balance)
i) Create a table BankAccounts
ii) Perform multiple transactions with SAVEPOINTS:
iii) What happens if COMMIT is executed before ROLLBACK?
iv) Can you create nested SAVEPOINTS?
v) What would happen if we removed SAVEPOINT sp1 before rollback?

-- BEGIN;
-- SAVEPOINT sp1;
-- -- operation A
-- SAVEPOINT sp2;
-- -- operation B
-- ROLLBACK TO sp2; -- Undo only B
-- ROLLBACK TO sp1; -- Undo A and B
-- COMMIT;

--1.
--i)
create table BankAccounts(
AccountID serial primary key,
Name varchar(100) not null,
Balance decimal(10,2) check (Balance >= 0) not null
);

create table Transactions(


TransactionID serial primary key,
AccountID int references BankAccounts(AccountID) on delete cascade,
Amount decimal(10,2) check (Amount > 0) not null,
TransactionType varchar(10) check (TransactionType in
('Deposit','Withdrawl')) not null,
Time_Stamp timestamp default current_timestamp
);

--ii)
begin;
insert into BankAccounts(Name, Balance) values ('Neo', 50000.00);
savepoint p1;

update BankAccounts
set Balance = Balance + 100
where Name = 'Neo';

insert into Transactions(AccountID, Amount, TransactionType)


values (1, 100, 'Deposit');

--iv)
savepoint p2; -- inside savepoint p1 (nested savepoint)

update BankAccounts
set Balance = Balance - 200000
where Name = 'Neo';

insert into Transactions(AccountID, Amount, TransactionType)


values (1, 200000, 'Withdrawl');

savepoint p3; -- inside savepoint p2


--(nested savepoint)
--not reached as amt not there so rollback to p2

rollback to savepoint p2;

update BankAccounts
set Balance = Balance - 1000
where Name = 'Neo';

insert into Transactions(AccountID, Amount, TransactionType)


values (1, 1000, 'Withdrawl');

commit; --means to save changes permanently to db

--iii)
rollback to savepoint p1;
--not reached as commit is done
--rollback; --not reached as commit is done

--v)
insert into BankAccounts(Name, Balance)
values ('Tianne', 35000.50);
begin;
savepoint s4;
insert into Transactions(AccountID, Amount, TransactionType)
values (2, 1000, 'Deposit');

release savepoint s4;

rollback to savepoint s4;


--error as savept released

commit;

2. A company database has Admin, Manager, and Employee roles. Grant access based on job roles.
Users (UserID , Name, Role). Apply Role-Based Access Control (RBAC)
i) Can a revoked user still access old data?
ii) What happens if a user with GRANT OPTION assigns a privilege?
iii) How can we prevent users from granting privileges to themselves?

--2.

create table _Users_(


UserID serial primary key,
Name varchar(100),
Role varchar(10) check (Role in ('Admin','Manager','Employee'))
);

create role admin;


create role manager;
create role employee;

create table Reports(


ReportID serial primary key,
Title varchar(100),
Content text
);

grant all privileges on Reports to admin;


grant select, insert on Reports to manager;
grant select on Reports to employee;

create user allie with password 'pass1';


create user ben with password 'pass2';
create user charlie with password 'pass3';

grant admin to allie;


grant manager to ben;
grant employee to charlie;

--i)
revoke employee from charlie;
-- Now charlie cannot SELECT from Reports

--ii)
create user dave with password 'pass4';
-- Grant manager with grant option to bob
grant select on Reports to ben with grant option;

-- Now ben can do:


grant select on Reports to dave;
--if ben permission revoked & to also revoke from david
revoke select on Reports from ben cascade;

--iii)
--just don't grant them with the grant option (as we granted for ben in ii)
giving him grant permission don't do that) to prevent users from granting
privileges to themselves

You might also like