boris/G4G0-1
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

vault backup: 2024-03-21 22:58:58

Browse Source
This commit is contained in:
George Wilkinson
2024-03-21 22:58:58 +00:00
parent 68fa81d02f
commit e241fe8bd6
49 changed files with 1950 additions and 210 deletions
Download Patch File Download Diff File Expand all files Collapse all files

77
Semester 2/Database Systems/Week 10/Week 10 Database Systems.md Normal file
View File

@@ -0,0 +1,77 @@
# Query Optimisation Revision
1. Obtaining the desired information from a database system in a predictable and reliable fashion is Query Processing. Getting these results back in a timely manner deals with the technique of Query Optimization.
2. r(rID, rName, rDescription), 5000 tuples.
tuple header(24b)
rID(6b)
rName(10b)
rDescription(100b)
Disc Block(1024b)
Disc Block Header(24b)
Block Space 1000b
1. (24+6+10+100)=140b
We can fit 7 tuples in 1 block.
5000/7 = 715 blocks required.
2. (24+6+10) = 40b
25 tuples per block
5000/25 = 200 blocks required.
3. Since the projection uses significantly less blocks, we access the disc less in queries compared to using every attribute. 715/200 = 3.6x less disc block accesses.
3. Write relational algebra expressions for the following SQL query.
SELECT lecturers.name, students.name, courses.name
FROM lecturers, students, assessors, courses
WHERE lecturers.lid=assessors.lid
AND students.sid=assessors.sid
AND students.cid=courses.cid
AND courses.cid=“CS”;
π lecturers.name, students.name, courses.name (
σ courses.cid = "CS" (
lecturers ⨝ (
assessors ⨝ (
students ⨝ courses))))
Or,
π lecturers.name, students.name, courses.name
(σ lecturers.lid=assessors.lid
(σ students.sid=accessors.sid
(σ courses.cid=students.did
(σ courses.cid='CS'(courses\*students)
)\* assessors
)\* lecturers
)
1. Draw query tree
4. List heuristics that optimisers apply to reduce cost of optimisation.
- Begin with initial query tree for SQL
- Move SELECT operations down the tree
- Apply more restrictive SELECT operations first ( eg. equalities before range queries )
- Replace Cartesian products followed by selection with theta joins ( eg. *sigma(f) ( RxS )* -> *R theta(f) S* )
- Move PROJECT operations down the query tree ( add project operations as inputs to theta joins ).
5. Draw a near optimal query tree for the following:
SELECT hotels.name
FROM hotels, ratings
WHERE hotels.rid=ratings.rid
AND hotels.hid=10
AND ratings.rating>7;
1. Write relational algebra expressions for this tree
# Precedence Graphs Revision
1. State True / False
1. A transaction in which all steps must be completed successfully or none of them will be completed is called a durable transaction.
False, this is the definition of an atomic transaction
2. Two-phased locking can be used to ensure that transactions are serializable
True
3. Although two transactions may be correct in themselves, interleaving of operations may produce an incorrect result.
True
4. Transactions should be written to the log before they are applied to the database itself.
True
2. Consider the following precedence graph for a non-serial schedule consisting of four transactions. Is the corresponding schedule conflict serializable? Justify your answer. If it is conflict-serializable give a corresponding serial schedule.
![](Pasted%20image%2020240319160609.png)
The following is serialisable, since there are no cycles in the precedence graph. T1, T2, T3, T4.
3. For each of the schedules shown in Table 36.1, draw a precedence graph, determine whether it is conflict serializable and justify your answer.
![](Pasted%20image%2020240319161202.png)
![](Pasted%20image%2020240319162824.png)
Not serialisable, directed cycle in graph.
![](Pasted%20image%2020240319163053.png)
Not serialisable, directed cycle in graph

266
Semester 2/Database Systems/Week 9/Week 9 Database Systems.md Normal file
View File

@@ -0,0 +1,266 @@
# Data Security
## Threats
- Accidental Loss
- Human Error
- Software Failure
- Hardware Failure
- Theft, Fraud, Sabotage
- Improper Data Access
- Loss of privacy ( personal data )
- Loss of confidentiality ( corporate data )
- Loss of data integrity
- Loss of availability
## Non Computer-Based Controls
- Policies, agreements, administrative controls
- Security policies
- Contingency plans
- Personnel Controls
- Secure positioning of equipment
- Maintenance agreements
- Physical access controls
## Computer-Based Controls
- Backup
- Periodical copies of database & journal to offline media.
- Journaling
- Keeping and maintaining a log file / journal of all changes made to database to enable recovery.
- Checkpointing
- Syncro between database and transaction log. Buffers are force-written to storage.
- Integrity
- Prevents data invalidity.
- Encryption
- Encoding of data by algorithm; renders data unreadable without decryption key.
- Authorisation
- Granting of right or privilege, enabling subject legitimate access to a system / object.
- Authentication
- Determines the authenticity of a user.
- Views
- Dynamic result of one or more relational operations on the base relations to produce another relation.
## Authorisation
### Authorisation Types for Schemas
- Resources: allows creation of new relations
- Alteration: allows the addition / deletion of attributes
- Index: allows creation / deletion of indices
- Drop: allows deletion of relations
### Authorisation Types for Data
- Read: allows read only access
- Insert: allows insertion ( not modification ) of new data
- Update: allows modification ( not deletion ) of existing data
- Delete: allows deletion of data.
### Authorisation Grant Graph
- Passage of auth from one user to another may be represented in a grant graph.
- Nodes = users
- Root = db admin
- Edge indicates user granted authorisation for a specific transaction to another user.
- All edges must be part of some path connecting to the db admin.
- ![](Pasted%20image%2020240312131440.png)
If DBA revokes auth from U1:
- Auth must be revoked from U4, since U1 no longer has authorisation.
- Auth must not be revoked from U5, since another auth path exists.
## View
- Alike to a window, through which data is seen.
- Creation of a view does not require significant memory, not a new relation.
- Extremely useful in restricting access to data.
- Users can be given authorisation on views, without being given any authorisation on the relations themselves.
- Ability of views to hide data serves to simplify usage of system, and enhance security by allowing users specific access.
- Combination of relational-level security and view-level security can be used to limit, precisely, user access.
- To create a view, a user must have read auth on all relations the view accesses.
### Example
Suppose a bank clerk needs to know the names of the customers that have a loan and which branch they bank with, but is not authorised to see specific loan information.
1. Deny bank clerk direct access to loan relation
2. Create view to provide necessary information.
```SQL
CREATE VIEW cust-loan AS
SELECT branchname, customer-name
FROM borrower, loan
WHERE borrower.loan-number = loan.loan-num
```
3. Grant bank clerk access to view
The clerk is now authorised to see the result of a query on the view
```SQL
SELECT *
FROM cust-loan
```
If the creator of the cust-loan view has only read auth on borrower and loan, the creator will only have read auth on the view.
## Granting Privileges in SQL
```SQL
GRANT <privilege list>
ON <relation / view name >
TO <user list>
```
- GRANT statement is used to confer authorisation
- Lists the privileges to be granted
- Specifies the relation / view that will be effected
- Stipulates who is being authorised.
- user id
- PUBLIC ( all valid users )
- role
- Granting privilege on a view does not imply privilege on any relation.
- Grantor of privilege must hold the privilege, or be the administrator.
### Types of Privilege
- SELECT: allows read access
- INSERT: allows use of INSERT INTO
- UPDATE: allows use of UPDATE
- DELETE: allows tuples to be deleted
- REFERENCES: allows foreign keys to be declared when creating relations
- ALL PRIVILEGES: used as a short term for all.
### Allowing Granting
- Users can be allowed to pass a privilege on to other users.
```SQL
GRANT SELECT
ON branch
TO U1
WITH GRANT OPTION
```
- This gives U1 the select privilege on branch and allows U1 to grant this privilege to other users.
### Revoking Privilege
- REVOKE is used to remove authorisation
- Lists all privileges to be revokes
- If list contains ALL, all privileges will be removed
- Specifies relation or view that will be effected.
```SQL
REVOKE <privilege list>
ON <relation / view name>
FROM <user list>
[RESTRICT | CASCADE]
```
- If same privilege granted twice to same user by different grantors, user may retain privilege after revoke.
- All privileges that depend solely on privilege being revoked are also revoked.
- If revoking a privilege from a user causes other users to lose that privilege, the revoke is CASCADED.
- Cascading can be prevented by specifying RESTRICT
- With restrict, the revoke command fails if cascading revokes are necessary.
- If \<user list> includes public, all users lose the privilege, except those granted explicitly.
## Roles
Roles permit common privileges for a class of users
Privileges can be granted or revoked from roles
Roles can be assigned to users, and also other roles
### Roles in SQL
```SQL
CREATE ROLE teller;
CREATE ROLE manager;
GRANT SELECT ON branch TO teller;
GRANT UPDATE(balance) ON account TO teller;
GRANT ALL PRIVILEGES ON account TO manager;
GRANT teller to manager;
GRANT teller TO alice, bob;
GRANT manager TO avi;
```
## Limitations of SQL Authorisation
No support for tuple-level authorisation
All end-users of an application may be mapped to a single user.
Task of auth in above cases falls on application program
- Auth must be performed at an application level, rather than SQL.
- Checking for absence of loopholes becomes difficult, since it requires reading a larger amount of code.
# Tutorial
1. Define following terms:
1. Authentication
- The process of verifying the authenticity of a user.
2. Authorisation
- The process of verifying permission / privilege to access a system / object.
3. Roles within SQL
- Permit common privileges for users, allowing groups of user's permissions to be changed.
2. Explain the following parts of an auth grant graph:
1. Nodes
- Nodes represent users
2. Root Node
- Root node represents db admin
3. Edge
- Edges represent permission grants between users.
3. Consider the following:
![](Pasted%20image%2020240312161656.png)
What would be the result of U1 revoking auth from U4?
- U6 would have its privilege revoked, as there is no path to the root node. All other nodes would be unaffected, since they all have a path to the root.
4. Consider the following:
![](Pasted%20image%2020240312161933.png)
What would be the result of DBA revoking auth from U1?
- U2, U4, and U6 all have auth revoked, as here is no path to the root.
5. Suppose a database includes the following relations.
Student(sNo, sName, sAddress, sLevel, sMno, sPerformance)
Module(mNo, mTitle, mLevel, mLecturer)
1. Users are:
- Alfred - Authorised to do anything
- Christian - See and change student details, cannot register or delete
- Robin - Same auth as christian
- George - Same auth as Robin
2. There is another User, Jessica, who can only see final year students and final year modules. Jessica is not authorised to do anything else. Write SQL statements that implement this. Hint: you can use a view to achieve this!
3. Now suppose that George has now moved to another university and, therefore, should no longer have access to the database. Write SQL statements to implement this.
##### Q5 Answers
1. .
```SQL
GRANT ALL PRIVILEGES ON student TO alfred;
GRANT ALL PRIVILEGES ON module TO alfred;
GRANT select, update ON student TO christian, robin, george;
```
1. .
```SQL
CREATE VIEW studentFinal AS
SELECT *
FROM student
WHERE sLevel = 6
CREATE VIEW moduleFinal AS
SELECT *
FROM module
WHERE mLevel = 6;
REVOKE ALL PRIVILEGES ON student, module FROM jessica RESTRICT;
GRANT SELECT ON studentFinal TO jessica;
GRANT SELECT ON moduleFinal TO jessica;
```
1. .
```SQL
REVOKE ALL PRIVILEGES ON * FROM george;
```