vault backup: 2024-04-18 15:44:37

.obsidian/app.json

@@ -7,8 +7,8 @@
   "pdfExportSettings": {
     "pageSize": "A4",
     "landscape": false,
-    "margin": "2",
-    "downscalePercent": 100
+    "margin": "0",
+    "downscalePercent": 78
   },
   "readableLineLength": false,
   "alwaysUpdateLinks": true,

.obsidian/workspace.json

@@ -25,7 +25,7 @@
             "state": {
               "type": "markdown",
               "state": {
-                "file": "Semester 2/Database Systems/Week 11/Week 11 Database Systems.md",
+                "file": "Semester 2/Database Systems/Trimester 2 Assignment.md",
                 "mode": "source",
                 "source": false
               }
@@ -33,22 +33,6 @@
           }
         ],
         "currentTab": 1
-      },
-      {
-        "id": "6e12dd6a998cfc12",
-        "type": "tabs",
-        "children": [
-          {
-            "id": "ec2850de42a22f4a",
-            "type": "leaf",
-            "state": {
-              "type": "pdf",
-              "state": {
-                "file": "Semester 2/Database Systems/Exercise Booklet.pdf"
-              }
-            }
-          }
-        ]
       }
     ],
     "direction": "vertical"
@@ -115,7 +99,7 @@
             "state": {
               "type": "backlink",
               "state": {
-                "file": "Semester 2/Database Systems/Week 11/Week 11 Database Systems.md",
+                "file": "Semester 2/Database Systems/Trimester 2 Assignment.md",
                 "collapseAll": false,
                 "extraContext": false,
                 "sortOrder": "alphabetical",
@@ -132,7 +116,7 @@
             "state": {
               "type": "outgoing-link",
               "state": {
-                "file": "Semester 2/Database Systems/Week 11/Week 11 Database Systems.md",
+                "file": "Semester 2/Database Systems/Trimester 2 Assignment.md",
                 "linksCollapsed": false,
                 "unlinkedCollapsed": true
               }
@@ -155,7 +139,7 @@
             "state": {
               "type": "outline",
               "state": {
-                "file": "Semester 2/Database Systems/Week 11/Week 11 Database Systems.md"
+                "file": "Semester 2/Database Systems/Trimester 2 Assignment.md"
               }
             }
           },
@@ -197,8 +181,10 @@
   },
   "active": "3ed058b7ba32ddc0",
   "lastOpenFiles": [
-    "Semester 2/Database Systems/Trimester 2 Assignment.md",
+    "images/Pasted image 20240417140336.png",
+    "images/Pasted image 20240417140243.png",
     "Semester 2/Database Systems/Week 11/Week 11 Database Systems.md",
+    "Semester 2/Database Systems/Trimester 2 Assignment.md",
     "Semester 2/Database Systems/Exercise Booklet.pdf",
     "Semester 2/Database Systems/Week 11",
     "Semester 2/Untitled",
@@ -228,7 +214,6 @@
     "Semester 2/Programming 2/Week 10 Revision/Q4.md",
     "images/Pasted image 20240319224232.png",
     "Semester 2/Programming 2/Week 10 Revision/Q3.md",
-    "images/Pasted image 20240319163053.png",
     "Semester 2/Programming 2/Week 10 Revision/Q1.md",
     "Semester 2/Database Systems/Week 2/Week 2 Database Systems.md",
     "Semester 2/Database Systems/Week 1/Week 1 Database Systems.md",

Semester 2/Database Systems/Trimester 2 Assignment.md

@@ -1,3 +1,7 @@
+| User ID     | CHC119   |
+| ----------- | -------- |
+| Roll Number | 00677611 |
+
 # Q1
 
 ### a)
@@ -23,8 +27,8 @@ If the "street" attribute is unneeded, less IO operations are needed to retrieve
 
 #### i)
 
-![](Pasted%20image%2020240415135455.png)
-# Add Projections
+- ![](Pasted%20image%2020240417140336.png)
+
 #### ii)
 
 Root Node: $\pi$ ( factory.name )
@@ -36,8 +40,9 @@ Line-by-line:
 
 1. This is the final attribute we want to obtain. Placing this here ensures only the necessary data is output; reduces IO operations and memory usage, as only the required data is given.
 2. Exists to join the 2 tables together based on the condition that the order's factory ID = factory's ID, allowing the projection root node to have the necessary data from the factory table to obtain the factory's name.
-3. There is an argument for this being above or below the theta join, however I have placed this here due to the heuristic principles of query optimisation, moving selection operations down the tree. This exists to "filter" the result on the condition that the order is urgent. By placing this selection after the theta join, we can "filter" more selectively and reduce the dataset size to optimise memory usage, similar to the adjacent selection operation.
-4. This exists to "filter" the dataset on the condition that the quantity is larger than 20 units. By placing this at the start, we ensure filtering is executed earlier, as to not waste compute resources. This reduces the dataset size, allowing the following operations to be more optimised, as there is less data to be processed.
+3. These projections are necessary to optimise the dataset by reducing the size of the total data when the tables are joined by removing irrelevant columns we would not need for the output of the query. This would decrease the amount of memory and disk space used by the query, and reduce the CPU cycle cost for the theta join.
+4. There is an argument for this being above or below the theta join, however I have placed this here due to the heuristic principles of query optimisation, moving selection operations down the tree. This exists to "filter" the result on the condition that the order is urgent. By placing this selection after the theta join, we can "filter" more selectively and reduce the dataset size to optimise memory usage, similar to the adjacent selection operation.
+5. This exists to "filter" the dataset on the condition that the quantity is larger than 20 units. By placing this at the start, we ensure filtering is executed earlier, as to not waste compute resources. This reduces the dataset size, allowing the following operations to be more optimised, as there is less data to be processed.
 
 # Q2
 
@@ -54,7 +59,7 @@ To guarantee consistency, a DBMS handles the enforcement of atomicity, consisten
 
 Ideal SQL Transfer of crates:
 
-```sql
+```
 UPDATE warehouse
 SET crates = crates - 3
 WHERE wname = 'warehouse1'
@@ -65,6 +70,7 @@ WHERE wname = 'warehouse2';
 ```
 
 If the second query is not run, it is not the fault of the DBMS. A DBMS can only enforce ACID rules and ensure consistency, not transaction logic.
+
 ### c)
 
 By allowing concurrent execution of transactions, system resources are allocated more efficiently due to multiple operations occurring simultaneously. This has an effect of being more performant, since more transactions can be processed per second.
@@ -112,8 +118,12 @@ Deadlock does not occur, since there are no cycles in the graph
 ### d)
 
 #### i)
-# TO DO
-The recovery manager would first identify in-progress transactions at the time of failure
+
+T1 starts and commits before the checkpoint, the recovery manager would recognise this and take no action, since the data is consistent in the database: the transaction is safe. T2 also starts and commits before the checkpoint; the recovery manager would take the same action as with T1, as the data is consistent: transaction is safe. T3 commits after the checkpoint, so must be active during the checkpoint; for this reason, the recovery manager must redo the transaction to maintain consistency in the database. T4 is active at the point of failure - since the transaction never completed, it must be undone as the database is no longer consistent; values may have been made durable before the transaction had committed.
+
+#### ii)
+
+Using the immediate update protocol, the recovery manager would first analyse the recovery log, working backwards to identify in-progress transactions at the time of failure, and determine the last record of a checkpoint. Following this, the recovery manager creates 2 lists: undo, and redo. Then by compensating for changes made until <T, start>, recorded in the recovery log, changes are undone for transactions running at the time of failure. Finally, the recovery manager reapplies changes recorded in the log for committed transactions before the time of failure, the recovery manager redoes the necessary transactions ensuring the database is consistent with updates prior to the failure.
 
 # Q4
 
@@ -121,7 +131,7 @@ The recovery manager would first identify in-progress transactions at the time o
 
 #### i)
 
-```sql
+```
 SELECT partName
 FROM part
 WHERE partPrice > 100;
@@ -129,7 +139,7 @@ WHERE partPrice > 100;
 
 #### ii)
 
-```sql
+```
 SELECT carModel
 FROM car
 JOIN carPart ON car.carId = carPart.carId
@@ -137,7 +147,6 @@ GROUP BY car.carModel
 HAVING COUNT(carPart.partID) > 4;
 ```
 
-
 ### b)
 
 If the DBA revoked auth from U2 -> U1, U4, and U5 would also have auth revoked due to cascading revokes. There is no path from U1, U4 or U5 to the DBA if U2's authorisation is revoked. U3 and U6 still have a path to the DBA, as they do not depend on U2 for authorisation, authorisation is still valid.
@@ -146,7 +155,7 @@ If the DBA revoked auth from U2 -> U1, U4, and U5 would also have auth revoked d
 
 #### i)
 
-```sql
+```
 GRANT ALL PRIVILEGES ON * TO Isavella
 
 CREATE VIEW employeeView AS
@@ -158,7 +167,7 @@ GRANT SELECT, UPDATE ON employeeView TO Laura, Naser;
 
 #### ii)
 
-```sql
+```
 CREATE VIEW projectsView AS
 	SELECT *
 	FROM project
@@ -169,6 +178,6 @@ GRANT SELECT ON projectsView TO Jane;
 
 #### iii)
 
-```SQL
+```
 REVOKE ALL PRIVILEGES ON * FROM Naser;
-```
+```