-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
630 changed files
with
87,742 additions
and
2,431 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,150 @@ | ||
| --- | ||
| title: "CS134-lecture-20210628" | ||
| # date: 2021-06-28T13:52:38-07:00 | ||
| draft: false | ||
| bookToc: true | ||
| tags: ["SQL"] | ||
| --- | ||
|
|
||
| ## SQL cont. | ||
|
|
||
| ### Aggregate functions cont. | ||
|
|
||
| {{< hint danger >}} | ||
| Include in weekly assignment. | ||
| {{< /hint >}} | ||
|
|
||
| List each employee(ssn, fname, lname) who has more than 3 daughters and the salary of the employee is less than 60000. | ||
|
|
||
| ```sql | ||
| SELECT e.ssn, e.fname, e.lname | ||
| FROM employee AS e | ||
| WHERE e.salary < 60000 AND | ||
| (SELECT COUNT(*) | ||
| FROM dependent AS dep | ||
| WHERE e.ssn=dep.essn AND | ||
| dep.relationship='daughter') > 3; | ||
| ``` | ||
|
|
||
| ### `GROUP BY` clause | ||
|
|
||
|  | ||
|
|
||
| A clause `GROUP BY` is used to create sub groups. | ||
| This allows us to do some operations within a specific sub group. | ||
|
|
||
| The attributes being grouped by must appear in the select clause: | ||
|
|
||
| ```sql | ||
| SELECT x, y | ||
| -- from ... | ||
| GROUP BY x, y | ||
| ``` | ||
|
|
||
| For each department, retrieve the department number, the number of employees in the department, and their average salary. | ||
|
|
||
| ```sql | ||
| SELECT dno, COUNT(*), AVG(salary) | ||
| FROM employee | ||
| GROUP BY dno | ||
| ``` | ||
|
|
||
|  | ||
|
|
||
| ### `HAVING` clause | ||
|
|
||
|  | ||
|
|
||
| Since the `WHERE` clause comes before the `GROUP BY` clause, if we want to filter the results of the grouping, we can use the `HAVING` clause. | ||
| This allows us to filter the results of the grouping by making sure each sub group satisfies the condition after the `HAVING` clause. | ||
|
|
||
| - it is okay to have a `GROUP BY` clause without a `HAVING` | ||
| - it is **not** okay to have a `HAVING` clause without a `GROUP BY` | ||
|
|
||
| For each department which has more than two employees, retrieve the department number, the number of employees in the department, and their average salary. | ||
|
|
||
| ```sql | ||
| SELECT dno, COUNT(*), AVG(salary) | ||
| FROM employee | ||
| GROUP BY dno | ||
| HAVING COUNT(*) > 2; | ||
| ``` | ||
|
|
||
| ### Summary of SQL queries | ||
|
|
||
|  | ||
|
|
||
| The optional clauses are surrounded in square brackets `[]`. | ||
|
|
||
|  | ||
|
|
||
| ### In class exercise | ||
|
|
||
|  | ||
|
|
||
| Retrieve the department name if the lowest employee salary of the department is greater than 50000. | ||
| List department name and lowest salary. | ||
|
|
||
| ```sql | ||
| SELECT dname, MIN(salary) | ||
| FROM department, employee | ||
| WHERE dno=dnumber | ||
| GROUP BY dname | ||
| HAVING MIN(salary) > 50000; | ||
| ``` | ||
|
|
||
| ### Another solution to a previous problem | ||
|
|
||
| Our previous problem can be solved using our new clauses: | ||
|
|
||
| List each employee(ssn, fname, lname) who has more than 3 daughters and the salary of the employee is less than 60000. | ||
|
|
||
| ```sql | ||
| SELECT ssn, fname, lname | ||
| FROM employee, department | ||
| WHERE ssn=essn AND | ||
| relationship='daughter' AND | ||
| salary < 60000 | ||
| GROUP BY ssn, fname, lname | ||
| HAVING COUNT(*) > 3; | ||
| ``` | ||
|
|
||
| ### Returning to earlier problems we skipped | ||
|
|
||
| Before we skipped the delete statement with the subquery. | ||
|
|
||
| ```sql | ||
| DELETE FROM employee | ||
| WHERE dno IN (SELECT dnumber | ||
| FROM department | ||
| WHERE dname='Research'); | ||
| ``` | ||
|
|
||
| We can also use a subquery in an `UPDATE`: | ||
|
|
||
| ```sql | ||
| UPDATE employee | ||
| SET salary=salary*1.1 | ||
| WHERE dno IN (SELECT dnumber | ||
| FROM department | ||
| WHERE dname='Research'); | ||
| ``` | ||
|
|
||
| We can use a subquery in an insert statement: | ||
|
|
||
| ```sql | ||
| CREATE TABLE dept_info( | ||
| dept_name VARCHAR(10), | ||
| no_of_emps INTEGER, | ||
| total_sal INTEGER | ||
| ); | ||
|
|
||
| INSERT INTO dept_info (dept_name, no_of_emps, total_sal) | ||
| SELECT dname, COUNT(*), SUM(salary) | ||
| FROM department, employee | ||
| WHERE dnumber=dno | ||
| GROUP BY dname; | ||
| ``` | ||
|
|
||
| - the result of the subquery will be inserted into the `dept_info` table's values. | ||
|
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,206 @@ | ||
| --- | ||
| title: "CS134-lecture-20210629" | ||
| # date: 2021-06-29T17:46:25-07:00 | ||
| draft: false | ||
| bookToc: true | ||
| tags: ["SQL", "functional dependency", "normalization"] | ||
| --- | ||
|
|
||
| ## SQL cont. | ||
|
|
||
|  | ||
|
|
||
| Subqueries can be used inside insert statements: | ||
|
|
||
|  | ||
|
|
||
| This insert statement will update the numbers dynamically based on the response from the subquery. | ||
| The next time an employee is inserted, we can run this insert statement to update `DEPTS_INFO` using a trigger. | ||
|
|
||
| Or, we can use views... | ||
|
|
||
| ### Virtual table view | ||
|
|
||
| ```sql | ||
| CREATE VIEW dept_info_view AS | ||
| SELECT dname, | ||
| COUNT(*) AS no_of_emps, | ||
| SUM(salary) AS total_sal | ||
| FROM department, employee | ||
| WHERE dnumber=dno | ||
| GROUP BY dname; | ||
| ``` | ||
|
|
||
| This results in a self updating table, called a view: | ||
|
|
||
|  | ||
|
|
||
| We can query the view the same way we'd query a table. | ||
|
|
||
| ```sql | ||
| SELECT * FROM dept_info_view; | ||
| ``` | ||
|
|
||
| The views are maintained by the DBMS. | ||
| The views will be automatically updated, to main consistency between the view and the table being viewed. | ||
| This is a way we can have derived attributes. | ||
|
|
||
| {{< hint info >}} | ||
| Note: Views are covered more in depth in CS174. | ||
| {{< /hint >}} | ||
|
|
||
| ## Functional dependencies and normalization | ||
|
|
||
| {{< hint info >}} | ||
| File: [*Normalization slides*](/notes/134-7.pdf) | ||
| {{< /hint >}} | ||
|
|
||
|  | ||
|
|
||
| Formal measures are also called normal forms. | ||
| To understand normal forms, we will start with functional dependency. | ||
|
|
||
| ### Functional dependencies | ||
|
|
||
|  | ||
|  | ||
|
|
||
| {{<k display>}} | ||
| \begin{aligned} | ||
| X \to Y | ||
| \end{aligned} | ||
| {{</k>}} | ||
|
|
||
| - {{<k>}} X {{</k>}} and {{<k>}} Y {{</k>}} are sets of attributes | ||
|
|
||
| The functional dependency means that if 2 tuples share the same {{<k>}} X {{</k>}} value for an attribute, it means | ||
| they also share the same {{<k>}} Y {{</k>}} value for an attribute. | ||
|
|
||
|  | ||
|
|
||
| When {{<k>}} X {{</k>}} and {{<k>}} Y {{</k>}} are sets of a single item, they may be commonly notated like | ||
|
|
||
| {{<k display>}} | ||
| \begin{aligned} | ||
| \text{ssn} \to \text{ename} | ||
| \end{aligned} | ||
| {{</k>}} | ||
|
|
||
| So if 2 tuples share the same {{<k>}} \text{ssn} {{</k>}}, they will share the same {{<k>}} \text{ename} {{</k>}}. | ||
|
|
||
|  | ||
|  | ||
|
|
||
| ### Armstrong's inferences rules | ||
|
|
||
|  | ||
|  | ||
|
|
||
| - For reflexivity, if | ||
| {{<k display>}} | ||
| \begin{aligned} | ||
| \{\text{ssn}\} \subseteq \{\text{ssn,ename}\} | ||
| \end{aligned} | ||
| {{</k>}} | ||
| then | ||
| {{<k display>}} | ||
| \begin{aligned} | ||
| \{\text{ssn,ename}\} \to \text{ssn} | ||
| \end{aligned} | ||
| {{</k>}} | ||
|
|
||
| - For augmentation, if | ||
| {{<k display>}} | ||
| \begin{aligned} | ||
| \text{ssn} \to \text{ename} | ||
| \end{aligned} | ||
| {{</k>}} | ||
| we can add something to both sides, and it still holds | ||
| {{<k display>}} | ||
| \begin{aligned} | ||
| \{\text{ssn, address}\} \to \{\text{ename, address}\} | ||
| \end{aligned} | ||
| {{</k>}} | ||
|
|
||
| - For transitivity, | ||
|  | ||
|
|
||
|  | ||
|
|
||
| - For decomposition, if | ||
| {{<k display>}} | ||
| \begin{aligned} | ||
| \text{ssn} \to \{\text{ename, bdate, address}\} | ||
| \end{aligned} | ||
| {{</k>}} | ||
| then we also know | ||
| {{<k display>}} | ||
| \begin{aligned} | ||
| \text{ssn} &\to \text{ename} \\ | ||
| \text{ssn} &\to \text{bdate} \\ | ||
| \text{ssn} &\to \text{address} \\ | ||
| \text{ssn} &\to \{\text{ename, bdate}\} \\ | ||
| \text{ssn} &\to \{\text{bdate, address}\} \\ | ||
| \text{ssn} &\to \{\text{ename, address}\} \\ | ||
| \end{aligned} | ||
| {{</k>}} | ||
| - Union is the opposite of the decomposition above | ||
| - Pseudotransitivity is the transitivity between decomposed sets above | ||
|
|
||
| ### Closure | ||
|
|
||
|  | ||
|  | ||
|
|
||
| Each element of the set {{<k>}} F {{</k>}} is a functional dependency. | ||
| The set {{<k>}} F^+ {{</k>}} is all the dependencies in {{<k>}} F {{</k>}}, plus all the dependencies | ||
| that can be inferred from {{<k>}} F {{</k>}}. | ||
|
|
||
| The set {{<k>}} X^+ {{</k>}} is the set of attributes that are functionally deteremined by {{<k>}} X {{</k>}} based on {{<k>}} F {{</k>}}. | ||
|
|
||
|  | ||
|  | ||
|
|
||
| ### Equivalence | ||
|
|
||
|  | ||
|  | ||
|
|
||
| ### Minimal sets | ||
|
|
||
|  | ||
|  | ||
|  | ||
|  | ||
|
|
||
| ## Normalization | ||
|
|
||
|  | ||
|
|
||
| There are 4 normal forms we will study: 1NF, 2NF, 3NF, BCNF. | ||
| The higher the number, the more strict the form. | ||
|
|
||
|  | ||
|
|
||
| ### Keys and superkeys | ||
|
|
||
|  | ||
|
|
||
| - any key is a superkey | ||
|
|
||
|  | ||
|
|
||
| ### First normal form | ||
|
|
||
|  | ||
|  | ||
|
|
||
| Since the Research department has a set of locations, it is not in first normal form. | ||
| We can put it in first normal form by using decomposition. | ||
|
|
||
|  | ||
|
|
||
| - The disadvantage to solution 2 is that the department name and manager's ssn is repeated for each location. | ||
| - The disadvantage to solution 3 is that any tuple that doesn't have exactly 3 locations will have a lot of null values in the table. | ||
| Also the schema would needed to be modified if a department needed 4 locations. | ||
|
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.