11 | 
11 |
12 | The above design assumes that the game is soccer. That explains the
13 | mapping cardinalties given in the picture.
--------------------------------------------------------------------------------
/Ch05_Advanced_SQL/5.20.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 20
3 | title: '5.20'
4 | ---
5 | > The execution of a trigger can cause another action to be triggered. Most
6 | > database systems place a limit on how deep the nesting can be. Explain why
7 | > they might place such a limit.
8 |
9 | --------------------------------
10 |
11 | This is to protect the user of the database system against accidental infinite
12 | chain of triggering.
--------------------------------------------------------------------------------
/Ch06_Database_Design_Using_the_ER_Model/6.19.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 19
3 | title: '6.19'
4 | ---
5 | > We can convert any weak entity set to a strong entity set by simply adding
6 | > appropriate attributes. Why, then do we have weak entity sets?
7 |
8 | --------------------------------
9 |
10 | We have weak entity sets, because we want to make the dependence of the weak
11 | entity set on its identifying entity set **explicit**.
12 |
--------------------------------------------------------------------------------
/Ch14_Indexing/14.5.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 5
3 | title: '14.5'
4 | ---
5 | > Consider the modified redistribution scheme for B+-trees described on page 651.
6 | > What is the expected height of the tree as a function of n?
7 |
8 | --------------------------------
9 |
10 | If there are $K$ search-key values and $m - 1$ sibilings are involved in the redistribution,
11 | the expected height of the tree is: $\log_{\lfloor (m-1)n/m \rfloor} (K)$
--------------------------------------------------------------------------------
/Ch01_Introduction/1.15.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 15
3 | title: '1.15'
4 | ---
5 | > Describe at least three tables that might be used to store information in a social-
6 | > networking system such as Facebook.
7 |
8 | 1. Users table - that contains id, full name, phone number, email, date of birth, profile pic
9 | 2. Chats table - that contains the chat
10 | 3. Friends table - that contains basically two columns of user ids (foreign keys from Users table)
--------------------------------------------------------------------------------
/Ch04_Intermediate_SQL/4.20.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 20
3 | title: '4.20'
4 | ---
5 | > Show how to define a view _tot_credits(year,num_credits)_, giving the total number
6 | > of credits taken in each year.
7 |
8 | --------------------------------
9 |
10 | ```sql
11 | CREATE VIEW tot_credits(year,num_credits) AS (
12 | SELECT year, SUM(credits)
13 | FROM takes NATURAL JOIN course
14 | GROUP BY year
15 | ORDER BY year ASC
16 | )
17 | ```
--------------------------------------------------------------------------------
/Ch06_Database_Design_Using_the_ER_Model/6.28.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 28
3 | title: '6.28'
4 | ---
5 | > Explain the distinction between total and partial constraints.
6 |
7 | --------------------------------
8 |
9 | * **Total specialization constraint** - Each higher-level entity must belong to a
10 | lower-level entity set.
11 | * **Partial specialization constraint** - Some higher-level entities may not belong
12 | to any lower-level entity set.
13 |
--------------------------------------------------------------------------------
/Ch02_Introduction_to_the_Relational_Model/2.10.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 10
3 | title: '2.10'
4 | ---
5 | > Describe the differences in meaning between the terms _relation_ and _relation schema_.
6 |
7 | --------------------------------
8 |
9 | _relation_ is a set of tuples.
10 |
11 |
10 |
11 |
13 |
14 | TODO: This answer requires more explanation.
--------------------------------------------------------------------------------
/Ch13_Data_Storage_Structures/13.5.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 5
3 | title: '13.5'
4 | ---
5 | > It is important to be able to quickly find out if a block is present in the buffer,
6 | > and if so where in the buffer it resides. Given that database buffer sizes are very
7 | > large, what (in-memory) data structure would you use for this task?
8 |
9 | --------------------------------
10 |
11 | Hash table is the common option for large database buffers. The hash function helps
12 | in locating the appropriate bucket on which linear search is performed.
--------------------------------------------------------------------------------
/Ch15_Query_Processing/15.11.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 11
3 | title: '15.11'
4 | ---
5 | > Suppose a query retrieves only the first $K$ results of an operation
6 | > and terminates after that. Which choice of demand-driven or producer-driven
7 | > pipelining (with buffering) would be a good choice for such a query?
8 | > Explain your answer.
9 |
10 | --------------------------------
11 |
12 | Demand driven is better, since it will only generate the top $K$ results. Producer
13 | driven may generate a lot more answers, many of which would not get used.
--------------------------------------------------------------------------------
/Ch05_Advanced_SQL/5.10.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 10
3 | title: '5.10'
4 | ---
5 | > Using the relation from Exercise 5.9, write an SQL query to generate a report
6 | > showing the number of shares traded, number of trades, and total dollar volume
7 | > broken down by year, each month of each year, and each trading day.
8 |
9 | --------------------------------
10 |
11 | ```sql
12 | SELECT year,month,day,SUM(shares_traded) AS shares,
13 | SUM(num_trades) AS trades,
14 | SUM(dollar_volume) AS total_volume
15 | FROM nyse
16 | GROUP BY ROLLUP(year,month,day);
17 | ```
--------------------------------------------------------------------------------
/Ch02_Introduction_to_the_Relational_Model/2.4.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 4
3 | title: '2.4'
4 | ---
5 | > In the instance of _instructor_ shown in Figure 2.1, no two instructors
6 | > have the same name. From this, can we conclude that _name_ can be used
7 | > as a superkey (or primary key) of _instructor_?
8 |
9 | No. For this possible instance of the instructor table the names are unique,
10 | but in general this may not always be the case (unless the university has a
11 | rule that two instructors cannot have the same name, which is a rather unlikely
12 | scenario :) ).
13 |
--------------------------------------------------------------------------------
/Ch02_Introduction_to_the_Relational_Model/2.7.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 7
3 | title: '2.7'
4 | ---
5 | > Consider the bank database of Figure 2.18. Give an expression
6 | > in the relational algebra for each of the following queries: 
16 |
--------------------------------------------------------------------------------
/Ch14_Indexing/14.2.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 2
3 | title: '14.2'
4 | ---
5 | > Is it possible in general to have two clustering indices on the same relation for
6 | > different search keys? Explain your answer.
7 |
8 | --------------------------------
9 |
10 | In general, it is not possible to have two primary indices on the same relation for
11 | different keys because the tuples in a relation would have to be stored in different
12 | order to have the same values stored together. We could accomplish this by storing the
13 | relation twice and duplicating all values, but for a centralized system, this is not
14 | efficient.
--------------------------------------------------------------------------------
/Ch14_Indexing/14.6.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 6
3 | title: '14.6'
4 | ---
5 | > Give pseudocode for a B+-tree function `findRangeIterator()`, which is like the
6 | > function `findRange()`, except that it returns an iterator object, as described in
7 | > Section 14.3.2. Also give pseudocode for the iterator class, including the
8 | > variables in the iterator object, and the `next()` method.
9 |
10 | --------------------------------
11 |
12 | 
13 |
14 | If you want to learn more about the magic of Python Generators, head on over to [python.org](https://docs.python.org/3/tutorial/classes.html#generators).
15 |
16 |
--------------------------------------------------------------------------------
/Ch05_Advanced_SQL/5.8.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 8
3 | title: '5.8'
4 | ---
5 | > Given a relation _S(student,subject,marks)_, write a query to find the top 10 students
6 | > by total marks, by using SQL ranking. Include all students tied for the final spot
7 | > in the ranking, even if that results in more than 10 total students.
8 |
9 | --------------------------------
10 |
11 | ```sql
12 | SELECT *
13 | FROM (
14 | SELECT student,total,RANK() OVER (ORDER BY (total) DESC) AS t_rank
15 | FROM (
16 | SELECT student, SUM(marks) AS total
17 | FROM S
18 | GROUP BY student
19 | )
20 | )
21 | WHERE t_rank <= 10
22 | ```
--------------------------------------------------------------------------------
/Ch04_Intermediate_SQL/4.24.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 24
3 | title: '4.24'
4 | ---
5 | > Suppose user _A_, who has all authorization privileges on a relation _r_, grants **select**
6 | > on relation _r_ to **public** with grant option. Suppose user _B_ then grants **select** on
7 | > r to _A_. Does this cause a cycle in the authorization graph? Explain why.
8 |
9 | --------------------------------
10 |
11 | I don't think so. Since user _A_ has all authorization privileges on a relation _r_, _B_ granting
12 | **select** on r to _A_ doesn't bring any new privilege to user _A_.
13 |
14 | I guess this depends on the internals of the Database Management System.
--------------------------------------------------------------------------------
/Ch05_Advanced_SQL/5.22.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 22
3 | title: '5.22'
4 | ---
5 | > Given relation _s(a,b,c)_, write an SQL statement to generate a histogram
6 | > showing the sum of _c_ values versus _a_, dividing _a_ into 20 equal-sized
7 | > partitions (i.e., where each partition contains 5 percent of tuples in _s_,
8 | > sorted by _a_).
9 |
10 | --------------------------------
11 |
12 | ```sql
13 | WITH s_with_partition(a,b,c,partion_id) AS (
14 | SELECT a,b,c,NTILE(20) OVER (ORDER BY (a) ASC) AS partition_id
15 | FROM s
16 | )
17 | SELECT partition_id,SUM(c)
18 | FROM s_with_partition
19 | GROUP BY partition_id
20 | ORDER BY partition_id;
21 | ```
--------------------------------------------------------------------------------
/_quarto.yml:
--------------------------------------------------------------------------------
1 | project:
2 | type: website
3 | render:
4 | - "*.md"
5 | - "*.qmd"
6 | - "!PRIVATE_README.md"
7 |
8 | website:
9 | title: "Database System Concepts Answers"
10 | navbar:
11 | background: primary
12 | left:
13 | - href: index.qmd
14 | text: Home
15 | tools:
16 | - icon: github
17 | href: https://github.com/noahabe/database_system_concepts_answers
18 | sidebar:
19 | style: "floating"
20 | collapse-level: 1
21 | search: false
22 | contents: auto
23 |
24 | format:
25 | html:
26 | theme: cosmo
27 | css: styles.css
28 | toc: true
29 |
30 |
31 |
32 |
--------------------------------------------------------------------------------
/Ch07_Relational_Database_Design/7.27.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 27
3 | title: '7.27'
4 | ---
5 | > Use Armstrong's axioms to prove the soundness of the decomposition rule.
6 |
7 | --------------------------------
8 |
9 | * **Decomposition Rule** states: If $\alpha \rightarrow \beta\gamma$ holds, then $\alpha \rightarrow \beta$ holds
10 | and $\alpha \rightarrow \gamma$ holds.
11 |
12 | Suppose $\alpha \rightarrow \beta\gamma$ holds. By **Reflexivity rule** we know that,
13 | $\beta\gamma \rightarrow \beta$ and $\beta\gamma \rightarrow \gamma$ holds.
14 |
15 | By **Transitivity rule** $\alpha \rightarrow \beta$ holds
16 | and $\alpha \rightarrow \gamma$ holds.
--------------------------------------------------------------------------------
/Ch11_Data_Analytics/11.4.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 4
3 | title: '11.4'
4 | ---
5 | > Consider the data warehouse schema depicted in Figure 11.2. Give an SQL query
6 | > to summarize sales numbers and price by store and date, along with the hierarchies
7 | > on store and date.
8 |
9 | --------------------------------
10 |
11 | ```sql
12 | SELECT store_id, city, state, country,
13 | date, month, quarter, year,
14 | sum(number), sum(price)
15 | FROM sales, store, date
16 | WHERE sales.store_id = store.store_id AND
17 | sales.date = date.date
18 | GROUP BY ROLLUP(country, state, city, store_id),
19 | ROLLUP(year, quarter, month, date)
20 | ```
--------------------------------------------------------------------------------
/Ch14_Indexing/14.10.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 10
3 | title: '14.10'
4 | ---
5 | > Suppose you are given a database schema and some queries that are executed frequently.
6 | > How would you use the above information to decide what indices to create?
7 |
8 | --------------------------------
9 |
10 | Indices on any attributes on which there are selection conditions; if there are only a
11 | few distinct values for that attribute, a bitmap index may be created, otherwise a normal
12 | B+-tree index.
13 |
14 | B+-tree indices on primary-key and foreign-key attributes.
15 |
16 | Also indices on attributes that are involved in join conditions in the queries.
17 |
--------------------------------------------------------------------------------
/Ch02_Introduction_to_the_Relational_Model/2.11.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 11
3 | title: '2.11'
4 | ---
5 | > Consider the _advisor_ relation shown in the schema diagram in Figure 2.9,
6 | > with _s_id_ as the primary key of _advisor_. Suppose a student can have more than one
7 | > advisor. Then, would _s_id_ still be a primary key of the _advisor_ relation? If not,
8 | > what should the primary key of _advisor_ be?
9 |
10 | --------------------------------
11 |
12 | _s_id_ alone **cannot** be a primary key of the _advisor_ relation, since it
13 | doesn't identify uniquely a tuple in the relation _advisor_ (It is possible
14 | for one student to have many advisors).
--------------------------------------------------------------------------------
/Ch04_Intermediate_SQL/4.23.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 23
3 | title: '4.23'
4 | ---
5 | > Explain why, when a manager, say Satoshi, grants an authorization, the grant
6 | > should be done by the manager role, rather than by the user Satoshi.
7 |
8 | --------------------------------
9 |
10 | Assume the grant is done by the user Satoshi instead of the manager role. Then if Satoshi
11 | leaves the company one day, and the DBA revokes Satoshi's authorization, all of the employees
12 | granted by Satoshi will have their authorization revoked.
13 |
14 | If the DBA doesn't want that, he should have the manager role grant an authorization instead of
15 | the user Satoshi.
16 |
--------------------------------------------------------------------------------
/Ch07_Relational_Database_Design/7.17.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 17
3 | title: '7.17'
4 | ---
5 | > Give an example of a relation schema $R'$ and set $F'$ of functional dependencies
6 | > such that there are at least three distinct lossless decompositions of $R'$ into
7 | > BCNF.
8 |
9 | --------------------------------
10 |
11 | Given the relation $R' = (A, B, C, D)$ the set of functional dependencies
12 | $F' = A \rightarrow B, C \rightarrow D, B \rightarrow C$ allows three distinct
13 | BCNF decompositions.
14 |
15 | $$R_1 = \{ (A, B), (C, D), (B, C) \}$$
16 | is in BCNF as is
17 | $$R_2 = \{ (A, B), (C, D), (A, C) \}$$
18 | $$R_3 = \{ (B, C), (A, D), (A, B) \}$$
--------------------------------------------------------------------------------
/Ch10_Big_Data/10.3.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 3
3 | title: '10.3'
4 | ---
5 | > Suppose you wish to store utility bills for a large number of users, where
6 | > each bill is identified by a customer ID and a date. How would you store the
7 | > bills in a key-value store that supports range queries, if queries request the bills
8 | > of a specified customer for a specified date range.
9 |
10 | --------------------------------
11 |
12 | Create a key by concatenating the customer ID and date (with date represented
13 | in the form year/month/date, e.g., 2018/02/28) and store the records indexed
14 | on this key. Now the required records can be retrieved by a range query.
--------------------------------------------------------------------------------
/Ch07_Relational_Database_Design/7.44.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 44
3 | title: '7.44'
4 | ---
5 | > Given two relations $r(A, B, \text{validtime})$ and $s(B, C, \text{validtime})$ where
6 | > $\text{validtime}$ denotes the valid time interval, write an SQL query to compute the
7 | > temporal natural join of the two relations. You can use the && operator to check if
8 | > two intervals overlap and the * operator to compute the intersection of two intervals.
9 |
10 | --------------------------------
11 |
12 | ```sql
13 | SELECT A, r.B, r.validtime * s.validtime
14 | FROM r INNER JOIN s
15 | ON (r.B = s.B
16 | AND
17 | r.validtime && s.validtime)
18 | ```
--------------------------------------------------------------------------------
/Ch03_Introduction_to_SQL/3.29.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 29
3 | title: '3.29'
4 | ---
5 | > Using the university schema, write an SQL query to find the name and ID of each History
6 | > student whose name begins with the letter 'D' and who has _not_ taken at least five
7 | > Music courses.
8 |
9 | --------------------------------
10 |
11 | ```sql
12 | SELECT id,name
13 | FROM student AS s
14 | WHERE dept_name = 'History'
15 | AND name LIKE 'D%'
16 | AND (
17 | SELECT COUNT(DISTINCT course_id)
18 | FROM takes
19 | WHERE takes.id = s.id AND
20 | course_id IN (SELECT course_id FROM course WHERE dept_name = 'Music')
21 | ) < 5;
22 | ```
--------------------------------------------------------------------------------
/Ch06_Database_Design_Using_the_ER_Model/6.7.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 7
3 | title: '6.7'
4 | ---
5 | > A weak entity set can always be made into a strong entity set
6 | > by adding to its attributes the primary-key attributes of its
7 | > identifying entity set. Outline what sort of redundancy will
8 | > result if we do so.
9 |
10 | --------------------------------
11 |
12 | The primary key of a weak entity set can be inferred from its relationship
13 | with the strong entity set. If we add primary-key attributes to the weak
14 | entity set, they will be present in both the entity set, and the relationship
15 | set and they have to be the same. Hence there will be redundancy.
--------------------------------------------------------------------------------
/Ch12_Physical_Storage_Systems/12.4.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 4
3 | title: '12.4'
4 | ---
5 | > Consider the following data and parity-block arrangement on four disks:
6 | >
7 | > 
8 | >
9 | > The $B_i$ s represent data blocks; the $P_i$ s represent parity blocks. Parity block
10 | > $P_i$ is the parity block for data blocks $B_{4i-3}$ to $B_{4i}$. What, if any,
11 | > problem might this arrangement present?
12 |
13 | --------------------------------
14 |
15 | This arrangement has the problem that $P_i$ and $B_{4i-3}$ are on the same disk. So if
16 | that disk fails, reconstruction of $B_{4i-3}$ is not possible, since data and parity
17 | are both lost.
--------------------------------------------------------------------------------
/Ch14_Indexing/14.14.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 14
3 | title: '14.14'
4 | ---
5 | > Suppose you have a relation containing the $x, y$ coordinates and names of restaurants.
6 | > Suppose also that the only queries that will be asked are of the following form: The query
7 | > specifies a point and asks if there is a restaurant exactly at that point. Which type of index
8 | > would be preferable, R-tree or B-tree? Why?
9 |
10 | --------------------------------
11 |
12 | B-tree index on the $(x, y)$ coordinates would be preferable. Even though we have a spatial data
13 | in two dimensions, the query that we are performing is not a **range queries** nor a **nearest neightbor** query.
--------------------------------------------------------------------------------
/Ch08_Complex_Data_Types/8.7.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 7
3 | title: '8.7'
4 | ---
5 | > Compute the relevance (using appropriate definitions of term frequency and
6 | > inverse document frequency) of each of the Practice Exercises in this chapter
7 | > by the query "SQL relation".
8 |
9 | --------------------------------
10 |
11 | We do not consider the questions containing neither of the keywords because
12 | their relevance to the keywords is zero. The number of words in a question
13 | include stop words. We use the equations given in Section 31.2 to compute
14 | relevance; the $\log$ term in the equation is assumed to be to the base $2$.
15 |
16 | 
--------------------------------------------------------------------------------
/Ch03_Introduction_to_SQL/3.28.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 28
3 | title: '3.28'
4 | ---
5 | > Using the university schema, write an SQL query to find the names and IDs of
6 | > those instructors who teach every course taught in his or her department
7 | > (i.e., every course that appears in the _course_ relation with the instructor's
8 | > department name). Order result by name.
9 |
10 | --------------------------------
11 |
12 | ```sql
13 | SELECT id, name
14 | FROM instructor AS i
15 | WHERE NOT EXISTS (
16 | (SELECT course_id FROM course WHERE dept_name = i.dept_name)
17 | EXCEPT
18 | (SELECT course_id FROM teaches WHERE teaches.id = i.id)
19 | )
20 | ORDER BY name ASC
21 | ```
--------------------------------------------------------------------------------
/Ch15_Query_Processing/15.5.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 5
3 | title: '15.5'
4 | ---
5 | > Let $r$ and $s$ be relations with no indices, and assume that the relations are not sorted.
6 | > Assuming infinite memory, what is the lowest-cost way (in terms of I/O operations)
7 | > to compute $r \bowtie s$? What is the amount of memory required for this algorithm.
8 |
9 | --------------------------------
10 |
11 | We can store the entire smaller relation in memory, read the larger relation block by block,
12 | and perform nested-loop join using the larger one as the outer relation. The number of I/O operations
13 | is equal to $b_r + b_s$, and the memory requirement is $\min(b_r, b_s) + 2$ pages.
--------------------------------------------------------------------------------
/Ch01_Introduction/1.5.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 5
3 | title: '1.5'
4 | ---
5 | > Keyword queries used in web search are quite different from database queries.
6 | > List key differences between the two, in terms of the way the queries are
7 | > specified and in terms of what is the result of a query.
8 |
9 | Queries used in the web are specified by providing a list of keywords with no
10 | specific syntax. The result is typically an ordered list of URLs, along with snippets
11 | of information about the content of the URLs. In contrast, database queries have
12 | a specific syntax allowing complex queries to be specified. And in the relational
13 | world the result of query is always a table.
--------------------------------------------------------------------------------
/Ch02_Introduction_to_the_Relational_Model/2.3.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 3
3 | title: '2.3'
4 | ---
5 | > Consider the _time_slot_ relation. Given that a particular time slot
6 | > can meet more than once in a week, explain why _day_ and _start_time_
7 | > are part of the primary key of this relation, while _end_time_ is not.
8 |
9 | The attributes _day_ and _start_time_ are part of the primary key
10 | since a particular class will most likely meet on several different
11 | days and may even meet more than once in a day. However, _end_time_
12 | is not part of the primary key since a particular class that starts
13 | at a particular time on a particular day cannot end at more than one time.
14 |
--------------------------------------------------------------------------------
/Ch03_Introduction_to_SQL/3.33.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 33
3 | title: '3.33'
4 | ---
5 | > Using the university schema, write an SQL query to find the ID and title
6 | > of each course in Comp. Sci. that has had at least one section with afternoon
7 | > hours (i.e., ends at or after 12:00). (You should eliminate duplicates if any.)
8 |
9 | --------------------------------
10 |
11 | ```sql
12 | SELECT course_id,title
13 | FROM course AS c
14 | WHERE dept_name = 'Comp. Sci.' AND
15 | EXISTS (
16 | SELECT *
17 | FROM section
18 | WHERE section.course_id = c.course_id AND
19 | time_slot_id IN (SELECT time_slot_id FROM time_slot WHERE end_hr >= 12)
20 | )
21 | ```
--------------------------------------------------------------------------------
/Ch06_Database_Design_Using_the_ER_Model/6.17.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 17
3 | title: '6.17'
4 | ---
5 | > Explain the difference between a weak and a strong entity set.
6 |
7 | --------------------------------
8 |
9 | A **weak entity set** is one whose existence is dependent on another entity set,
10 | called its **identifying entity set**; instead of associating a primary key with a weak
11 | entity, we use the primary key of the identifying entity, along with extra attributes,
12 | called **discriminator attributes** to uniquely identify a weak entity.
13 |
14 | An entity set that is not a weak entity set is termed a **strong entity set**.
15 |
16 | Learn more in section 6.5.3 of the book.
--------------------------------------------------------------------------------
/Ch08_Complex_Data_Types/8.15.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 15
3 | title: '8.15'
4 | ---
5 | > The Google search engine provides a feature whereby websites
6 | > can display advertisements supplied by Google. The advertisements
7 | > supplied are based on the contents of the page. Suggest how Google
8 | > might choose which advertisements to supply for a page, given
9 | > the page contents.
10 |
11 | --------------------------------
12 |
13 | Google might use **data clustering** algorithms to cluster a given webpage.
14 | Possible clusters might look like: [_sports_, _car engines_, _cloth_]. And based
15 | on which cluster a webpage ends up in, it can show ads that are relevant to that
16 | cluster.
--------------------------------------------------------------------------------
/Ch04_Intermediate_SQL/4.25.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 25
3 | title: '4.25'
4 | ---
5 | > Suppose a user creates a new relation _r1_ with a foreign key referencing another relation
6 | > _r2_. What authorization privilege does the user need on _r2_? Why should this not simply
7 | > be allowed without any such authorization?
8 |
9 | --------------------------------
10 |
11 | The **references** privilege needs to be granted to the user on the relation _r2_. This should not
12 | be allowed without any such authorization because, foreign-key constraints restrict deletion and
13 | update operations on the referenced relation. That is, operations such as **update** and **delete**
14 | on _r2_ may bring changes to _r1_ as well.
15 |
--------------------------------------------------------------------------------
/Ch10_Big_Data/10.15.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 15
3 | title: '10.15'
4 | ---
5 | > Suppose a stream can deliver tuples out of order with respect to tuple
6 | > timestamps. What extra information should the stream provide, so a stream
7 | > query processing system can decide when all tuples in a window have been
8 | > seen?
9 |
10 | --------------------------------
11 |
12 | Such streams should contain **punctuations**, that is, metadata tuples that state
13 | that all future tuples will have a timestamp greater than some value. Such punctuations
14 | are emitted periodically and can be used by window operators to decide when an aggregate
15 | result, such as aggregates for an hourly window, is complete and can be output.
--------------------------------------------------------------------------------
/Ch03_Introduction_to_SQL/3.35.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 35
3 | title: '3.35'
4 | ---
5 | > Using the university schema, write an SQL query to find section(s) with maximum
6 | > enrollment. The result columns should appear in the order "courseid, secid, year,
7 | > semester, num". (It may be convenient to use the _with_ construct.)
8 |
9 | --------------------------------
10 |
11 | ```sql
12 | WITH section_student_frequency(courseid, secid, year, semester, num) AS (
13 | SELECT course_id, sec_id, year, semester, COUNT(DISTINCT ID)
14 | FROM takes
15 | GROUP BY course_id, sec_id, year, semester
16 | )
17 | SELECT *
18 | FROM section_student_frequency
19 | WHERE num = (SELECT MAX(num) FROM section_student_frequency);
20 | ```
--------------------------------------------------------------------------------
/Ch04_Intermediate_SQL/4.11.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 11
3 | title: '4.11'
4 | ---
5 | > Operating systems usually offer only two types of authorization control for data
6 | > files: read access and write access. Why do database systems offer so many kinds of
7 | > authorization?
8 |
9 | --------------------------------
10 |
11 | There are many reasons - we list a few here. One might wish to allow
12 | a user only to append new information without altering old information.
13 | One might wish to allow a user to access a relation but not change its schema.
14 | One might wish to limit access to aspects of the database that are not technically
15 | data access but instead impact resource utilization, such as creating an index.
16 |
--------------------------------------------------------------------------------
/Ch03_Introduction_to_SQL/3.31.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 31
3 | title: '3.31'
4 | ---
5 | > Using the university schema, write an SQL query to find the ID and name
6 | > of each instructor who has never given an A grade in any course she or
7 | > he has taught. (Instructors who have never taught a course trivially satisfy
8 | > this condition.)
9 |
10 | --------------------------------
11 |
12 | ```sql
13 | SELECT id, name
14 | FROM instructor AS i
15 | WHERE 'A' NOT IN (
16 | SELECT takes.grade
17 | FROM takes INNER JOIN teaches
18 | ON (takes.course_id,takes.sec_id,takes.semester,takes.year) =
19 | (teaches.course_id,teaches.sec_id,teaches.semester,teaches.year)
20 | WHERE teaches.id = i.id
21 | )
22 | ```
--------------------------------------------------------------------------------
/Ch07_Relational_Database_Design/7.5.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 5
3 | title: '7.5'
4 | ---
5 | > Use Armstrong's axioms to prove the soundness of the pseudotransitivity rule.
6 |
7 | --------------------------------
8 |
9 | Proof using Armstrong's axioms of the pseudotransitivity rule:
10 |
11 | $$
12 | \text{if $\alpha \rightarrow \beta$ and $\gamma\beta \rightarrow \delta$ then $\alpha\gamma \rightarrow \delta$ }
13 | $$
14 |
15 | Proof:
16 |
17 | $$
18 | \alpha \rightarrow \beta \quad \text{given} \\
19 | \alpha\gamma \rightarrow \gamma\beta \quad \text{augmentation rule and set union commutativity} \\
20 | \gamma\beta \rightarrow \delta \quad \text{given} \\
21 | \alpha\gamma \rightarrow \delta \quad \text{transitivity rule} \\
22 | $$
--------------------------------------------------------------------------------
/Ch14_Indexing/14.11.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 11
3 | title: '14.11'
4 | ---
5 | > In write-optimized trees such as the LSM tree or the stepped-merge index, entries in
6 | > one level are merged into the next level only when the level is full. Suggest how this
7 | > policy can be changed to improve read performance during periods when there are many
8 | > reads but no updates.
9 |
10 | --------------------------------
11 |
12 | If there have been no updates in a while, but there are a lot of index look ups on an
13 | index, then entries at one level, say $i$, can be merged into the next level, even if the
14 | level is not full. The benefit is that reads would then not have to look up indices at level
15 | $i$, reducing the cost of reads.
--------------------------------------------------------------------------------
/Ch01_Introduction/1.14.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 14
3 | title: '1.14'
4 | ---
5 | > Explain why NoSQL systems emerged in the 2000s, and briefly contrast their
6 | > features with traditional database systems.
7 |
8 | Why did NoSQL systems emerged in the 2000s?
9 | 
11 |
12 | --------------------------------
13 |
14 | ```sql
15 | CREATE TRIGGER check_delete_trigger
16 | AFTER DELETE ON account
17 | REFERENCING OLD ROW AS orow
18 | FOR EACH ROW
19 | DELETE FROM depositor
20 | WHERE depositor.customer_name NOT IN (
21 | SELECT customer_name
22 | FROM depositor
23 | WHERE account_number <> orow.account_number
24 | )
25 | END
26 | ```
27 |
28 |
--------------------------------------------------------------------------------
/Ch09_Application_Development/9.26.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 26
3 | title: '9.26'
4 | ---
5 | > Explain what is a challenge-response system for authentication. Why is
6 | > it more secure than a traditional password-based system?
7 |
8 | --------------------------------
9 |
10 | The following is taken from [wiki](https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication).
11 |
12 | **Challenge-response authentication** is a family of protocols in which one party presents
13 | a question ("challenge") and another party must provide a valid answer ("response") to be
14 | authenticated.
15 |
16 | The simplest example of a challenge-response protocol is password authentication, where the
17 | challenge is asking for the password and the valid response is the correct password.
18 |
19 |
--------------------------------------------------------------------------------
/Ch06_Database_Design_Using_the_ER_Model/6.3.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 3
3 | title: '6.3'
4 | ---
5 | > Design an E-R diagram for keeping track of the
6 | > scoring statistics of your favorite sports team.
7 | > You should store **the matches played**, **the scores
8 | > in each match**, **the players in each match**, and
9 | > **individual player scoring statistics for each match**.
10 | > Summary statistics should be modeled as derived
11 | > attributes with an explanation as to how they
12 | > are computed.
13 |
14 | --------------------------------
15 |
16 | The diagram is shown in Figure 6.104. The derived
17 | attribute _season_score_ is computed by summing
18 | the score values associated with the _player_
19 | entity set via the _played_ relationship set.
20 |
21 | 
--------------------------------------------------------------------------------
/Ch02_Introduction_to_the_Relational_Model/2.17.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 17
3 | title: '2.17'
4 | ---
5 | > Discuss the relative merits of imperative, functional, and declarative languages.
6 |
7 | --------------------------------
8 |
9 | Merits of imperative languages
10 | * Easy to read
11 | * Conceptual model (solution path) is very easy for beginners to understand.
12 | * Characteristics of specific applications can be taken into account.
13 | [for more](https://www.ionos.com/digitalguide/websites/web-development/imperative-programming/)
14 |
15 | Mertis of functional languages
16 | * Lazy Evaluation
17 | * Seamless Parallel Programming
18 | [for more](https://en.wikipedia.org/wiki/Functional_programming)
19 |
20 | Merits of declarative languages
21 | * easy to use (since you only tell what you need).
--------------------------------------------------------------------------------
/Ch08_Complex_Data_Types/8.10.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 10
3 | title: '8.10'
4 | ---
5 | > Redesign the database of Exercise 8.4 into first normal form and fourth normal form.
6 | > List any functional and multivalued dependencies that you assume. Also list all
7 | > referential-integrity constraints that should be present in the first and fourth
8 | > normal form schemas.
9 |
10 | --------------------------------
11 |
12 | _Emp = (emp_id, ename)_ 
19 |
20 | > b. Delete record 2.
21 |
22 | 
23 |
24 |
25 | Note that the free record chain could have alternatively been from the header to
26 | 4, from 4 to 2, and finally from 2 to 6.
27 |
28 | > c. Insert (34556, Thompson, Music, 67000).
29 |
30 | 
31 |
--------------------------------------------------------------------------------
/Ch12_Physical_Storage_Systems/12.7.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 7
3 | title: '12.7'
4 | ---
5 | > Storing all blocks of a large file on consecutive disk blocks would
6 | > minimize seeks during sequential file reads. Why is it impractical to do so?
7 | > What do operating systems do instead, to minimize the number of seeks during
8 | > sequential reads?
9 |
10 | --------------------------------
11 |
12 | Reading data sequentially from a large file could be done with only one seek
13 | if the entire file was stored on consecutive disk blocks. Ensuring availability
14 | of large numbers of consecutive free blocks is not easy, since files are created
15 | and deleted, resulting in fragmentation of the free blocks on disks. Operating systems
16 | allocate blocks on large but fixed-sized sequential extents instead, and only one seek
17 | is required per extent.
--------------------------------------------------------------------------------
/Ch05_Advanced_SQL/5.1.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 1
3 | title: '5.1'
4 | ---
5 | > Consider the following relations for a company database:
6 | > * _emp(ename, dname, salary)_
7 | > * _mgr(ename,mname)_ 
11 |
12 | The above schema will result in worse performance, because given an **index_name**
13 | we would have to perform a join with the relation **Index_Attributes** every time
14 | we want to see the attributes that are associated with that index.
15 |
16 | Note that the above schema is in first normal form. Normalizing it further, to BCNF
17 | will result in a more even worse schema in the eyes of performance. It is not in
18 | BCNF because of the functional dependency index_name $\twoheadrightarrow$ relation_name
19 | in the table **Index_Attributes**.
--------------------------------------------------------------------------------
/Ch10_Big_Data/10.14.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 14
3 | title: '10.14'
4 | ---
5 | > Fill in the blanks below to complete the following Apache Spark
6 | > program which computes the number of occurrences of each word in a file.
7 | > For simplicity we assume that words only occur in lowercase, and there
8 | > are no punctuations marks.
9 | >
10 | > ```java
11 | > JavaRDD
15 |
16 | Relation schemas:
17 |
18 |
19 | customer(customer_id, name, phone_number, address) 
9 |
10 | > For entity sets $A$, $B$, and $C$, explain how attributes are inherited from the higher
11 | > level entity sets $X$ and $Y$. Discuss how to handle a case where an attribute of $X$
12 | > has the same name as some attribute of $Y$.
13 |
14 | --------------------------------
15 |
16 | $A$ inherits all the attributes of $X$, plus it may define its own attributes. Similarly, $C$
17 | inherits all the attributes of $Y$ plus its own attributes. $B$ inherits the attributes of both
18 | $X$ and $Y$. If there is some attribute _name_ which belongs to both $X$ and $Y$, it may be
19 | referred to in $B$ by the qualified name $X$._name_ or $Y$._name_.
--------------------------------------------------------------------------------
/Ch14_Indexing/14.7.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 7
3 | title: '14.7'
4 | ---
5 | > What would the occupancy of each leaf node of a B+-tree be if index entries
6 | > were inserted in sorted order? Explain why.
7 |
8 | --------------------------------
9 |
10 | If the index entries are inserted in ascending order, the new entries get directed
11 | to the last leaf node. When this leaf node gets filled, it is split into two. Of the
12 | two nodes generated by the split, the left node is left untouched and the insertions
13 | take place on the right node. This makes the occupancy of the leaf nodes about 50 percent
14 | except for the last leaf.
15 |
16 | If keys that are inserted are sorted in descending order, the above situation would
17 | still occur, but symmetrically, with the right node of a split never getting touched again,
18 | and occupancy would again be 50 percent for all nodes other than the first leaf.
--------------------------------------------------------------------------------
/Ch12_Physical_Storage_Systems/12.11.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 11
3 | title: '12.11'
4 | ---
5 | > RAID systems typically allow you to replace failed disks without stopping
6 | > access to the system. Thus, the data in the failed disk must be rebuilt
7 | > and written to the replacement disk while the system is in operation.
8 | > Which of the RAID levels yields the least amount of interference
9 | > between the rebuild and ongoing disk accesses? Explain your answer.
10 |
11 | --------------------------------
12 |
13 | **RAID level 1** (Mirroring Disks).
14 |
15 | The time to rebuild the data of a failed disk can be significant, and it
16 | varies with the RAID level that is used. Rebuilding is easiest for **RAID
17 | level 1**, since data can be copied from another disk; for the other levels
18 | (excluding RAID level 0), we need to access all the other disks in the
19 | array to rebuild data of a failed disk.
--------------------------------------------------------------------------------
/Ch04_Intermediate_SQL/4.14.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 14
3 | title: '4.14'
4 | ---
5 | > Consider the query
6 | > ```sql
7 | > SELECT course_id,semester,year,sec_id,AVG(tot_cred)
8 | > FROM takes NATURAL JOIN student
9 | > WHERE year = 2017
10 | > GROUP BY course_id,semester,year,sec_id
11 | > HAVING COUNT(id) >= 2;
12 | > ```
13 | > Explain why appending **NATURAL JOIN** _section_ in the **FROM** clause would not change the
14 | > result.
15 |
16 | --------------------------------
17 |
18 | Appending **NATURAL JOIN** _section_ in the **FROM** clause would not change the
19 | result because there is no logic in the query that uses attributes in _section_ that
20 | are not found in _takes_ relation. Also since every tuple in _takes_ relation has a corresponding
21 | tuple in the _section_ relation (due to foreign key constraint), there will be no change if we append
22 | the **NATURAL JOIN** _section_ in the **FROM** clause.
--------------------------------------------------------------------------------
/Ch07_Relational_Database_Design/7.35.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 35
3 | title: '7.35'
4 | ---
5 | > Although the BCNF algorithm ensures that the resulting decomposition
6 | > is lossless, it is possible to have a schema and a decompsition that
7 | > was not generated by the algorithm, that is in BCNF, and is not
8 | > lossless. Give an example of such a schema and its decomposition.
9 |
10 | --------------------------------
11 |
12 | Take the schema $R = (A,B,C,D,E)$ given on Practice Exercise 1.
13 | Assume the following set $F$ of functional dependencies holds:
14 |
15 | $$
16 | F := \{A \rightarrow BC, CD \rightarrow E, B \rightarrow D, E \rightarrow A\}
17 | $$
18 |
19 | Take the decomposition of $R$ given on Exercise 7.29.
20 |
21 | $$
22 | (A,B,C) \\
23 | (C,D,E) \\
24 | $$
25 |
26 | The above two decompsitions are clearly in BCNF.
27 |
28 | They are also **lossy decompositions** (We have shown this in Exercise 7.29).
--------------------------------------------------------------------------------
/Ch06_Database_Design_Using_the_ER_Model/6.25.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 25
3 | title: '6.25'
4 | ---
5 | > In Section 6.9.4, we represented a ternary relationship (repeated in Figure
6 | > 6.29a) using binary relationships, as shown in Figure 6.29b. Consider the
7 | > alternative shown in Figure 6.29c. Discuss the relative mertis of these
8 | > two alternative representations of a ternary relationship by binary relationships.
9 |
10 |
11 | 
12 |
13 | --------------------------------
14 |
15 | For Figure 6.29b to represent a ternary relationship, all relationship sets
16 | $R_A$, $R_B$, and $R_C$ need to be many-to-one relationships, with a total
17 | participation from entity set $E$.
18 |
19 | Let $(a,b,c)$ in $R$ (the ternary relationship in the above figure). Then we insert
20 |
21 | * $(a,b)$ in $R_{AB}$
22 | * $(b,c)$ in $R_{BC}$
23 | * $(c,a)$ in $R_{AC}$
24 |
25 | TODO: This answer needs more explanation.
--------------------------------------------------------------------------------
/Ch02_Introduction_to_the_Relational_Model/2.15.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 15
3 | title: '2.15'
4 | ---
5 | > Consider the bank database of Figure 2.18. Give an expression in the
6 | > relational algebra for each of the following queries:
7 | >
8 | > a. Find each loan number with a loan amount greater than $10000. 
9 |
10 | --------------------------------
11 |
12 | The nontrivial functional dependencies are $A \rightarrow B$ and $C \rightarrow B$,
13 | and a dependency they logically imply: $AC \rightarrow B$. $C$ does not functionally
14 | determine $A$ because the first and third tuples have the same $C$ value but different
15 | $A$ values. The same tuples also show $B$ does not functionally determine $A$. Likewise,
16 | $A$ does not functionally determine $C$ because the first two tuples have the same $A$
17 | value and different $C$ values. The same tuples also show $B$ does not functionally
18 | determine $C$. There are 19 trivial functional dependencies of the form $\alpha \rightarrow \beta$,
19 | where $\beta \subseteq \alpha$.
--------------------------------------------------------------------------------
/Ch07_Relational_Database_Design/7.29.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 29
3 | title: '7.29'
4 | ---
5 | > Show that the following decomposition of the schema $R$ of Exercise 7.1 is not a lossless
6 | > decomposition:
7 | >
8 | > $$
9 | > (A,B,C) \\
10 | > (C,D,E) \\
11 | > $$
12 | >
13 | > _Hint_: Give an example of a relation $r(R)$ such that $\Pi_{A,B,C}(r) \bowtie \Pi_{C,D,E}(r) \not = r$
14 |
15 | --------------------------------
16 |
17 | Take the following instance of $r(R)$:-
18 |
19 | A|B|C|D|E
20 | -|-|-|-|-
21 | 1|6|5|7|3
22 | 2|8|5|9|4
23 |
24 | Then $\Pi_{A,B,C}(r)$ is:-
25 |
26 | A|B|C
27 | -|-|-
28 | 1|6|5
29 | 2|8|5
30 |
31 | $\Pi_{C,D,E}(r)$ is:-
32 |
33 | C|D|E
34 | -|-|-
35 | 5|7|3
36 | 5|9|4
37 |
38 | And their natural join $\Pi_{A,B,C}(r) \bowtie \Pi_{C,D,E}(r)$ is:-
39 |
40 | A|B|C|D|E
41 | -|-|-|-|-
42 | 1|6|5|7|3
43 | 1|6|5|9|4
44 | 2|8|5|7|3
45 | 2|8|5|9|4
46 |
47 | Thus, the decomposition is a **lossy decomposition**.
--------------------------------------------------------------------------------
/Ch10_Big_Data/10.9.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 9
3 | title: '10.9'
4 | ---
5 | > Suppose you wish to model the university schema as a graph. For each of the
6 | > following relations, explain whether the relation would be modeled as a node
7 | > or as an edge: 
17 |
18 | --------------------------------
19 | Query:
20 |
21 | $ \Pi_{T.branch\_name} ( (\Pi_{branch\_name, assets}(\rho_T(branch))) \bowtie_{T.assets > S.assets} (\Pi_{assets} (\sigma_{branch\_city = 'Brooklyn'}(\rho_S(branch))))) $
22 |
23 | This expression performs the theta join on the smallest amount of data possible. It does
24 | this by restricting the right-hand side operand of the join to only those branches in Brooklyn
25 | and also eliminating the unneeded attributes from both the operands.
--------------------------------------------------------------------------------
/Ch01_Introduction/1.7.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 7
3 | title: '1.7'
4 | ---
5 | > List four significant differences between a file-processing system and a DBMS.
6 |
7 | 1) A file-processing system is more specific to the problem at hand while a DBMS
8 | is more general. A file-processing system used by a university is difficult to
9 | use in a hospital setting. While a DBMS once written can be used in different places.
10 |
11 | 2) It is difficult to ensure atomicity in a conventional file-processing system while
12 | it is a lot easier in a DBMS. Often wrapping a set of SQL statements in a "BEGIN TRANSACTION"
13 | and "END TRANSACTION" are often enough in the relational DBMS world.
14 |
15 | 3) Protecting against concurrent-access anomalies in a file-processing system is
16 | difficult. Using a DBMS is much easier to protect against concurrent-access anomalies.
17 |
18 | 4) Most DBMS have a concept of a user and what access that user has. Enforcing such
19 | authorization in a file-processing system is really difficult.
20 |
--------------------------------------------------------------------------------
/Ch14_Indexing/14.1.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 1
3 | title: '14.1'
4 | ---
5 | > Indices speed query processing, but it is usually a bad idea to create indices on
6 | > every attribute, and every combination of attributes, that are potential search keys.
7 | > Explain why.
8 |
9 | --------------------------------
10 |
11 | Reasons for not keeping indices on every attribute include:
12 |
13 | * Every index requires additional CPU time and disk I/O overhead during inserts
14 | and deletions.
15 |
16 | * Indices on non-primary keys might have to be changed on updates, although an
17 | index on the primary key might not (this is because updates typically do not modify
18 | the primary-key attributes).
19 |
20 | * Each extra index requires additional storage space.
21 |
22 | * For queries which involve conditions on several search keys, efficiency might not
23 | be bad even if only some of the keys have indices on them. Therefore, database performance
24 | is improved less by adding indices when many indices already exist.
--------------------------------------------------------------------------------
/Ch09_Application_Development/9.10.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 10
3 | title: '9.10'
4 | ---
5 | > Exercise 9.9 addresses the problem of encryption of certain attributes.
6 | > However, some database systems support encryption of entire databases.
7 | > Explain how the problems raised in Exercise 9.9 are avoided if the entire
8 | > database is encrypted.
9 |
10 | --------------------------------
11 |
12 | When the entire database is encrypted, it is easy for the database to perform
13 | decryption as data are fetched from disk into memory, so in-memory storage is
14 | unencrypted. With this option, everything in the database, including indices, is
15 | encrypted when on disk, but unencrypted in memory. As a result, only the data access
16 | layer of the database system code needs to be modified to perform encryption, leaving
17 | other layers untouched. Thus, indices can be used unchanged, and primary-key and
18 | foreign-key constraints enforced without any change to the corresponding layers of the
19 | database system code.
--------------------------------------------------------------------------------
/Ch15_Query_Processing/15.19.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 19
3 | title: '15.19'
4 | ---
5 | > Design a variant of the hybrid merge-join algorithm for the case where both relations
6 | > are not physically sorted, but both have a sorted secondary index on the join attributes.
7 |
8 | --------------------------------
9 |
10 | Let $r$ and $s$ be the two relations that are unsorted but have an ordered secondary index
11 | (such as B+-trees) on the join attributes. We use an algorithm similar to the one given on
12 | Figure 15.7, but instead of acting on the actual relations, it will operate on the leaf nodes
13 | of the indices of $r$ and $s$. The result file contains addresses for tuples of $r$ and addresses
14 | for tuples of $s$. We will first sort the file on the addresses for tuples of $r$ and retrieve the
15 | actual tuples in physical storage order and concatenate them with their counterparts of $s$. We will
16 | then sort this new file on the addresses of $s$ and retrieve them in phyiscal storage order.
17 | This will complete the join.
--------------------------------------------------------------------------------
/Ch09_Application_Development/9.19.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 19
3 | title: '9.19'
4 | ---
5 | > Many web sites today provide rich user interfaces using Ajax. List
6 | > two features each of which reveals if a site uses Ajax, without having
7 | > to look at the source code. Using the above features, find three sites
8 | > which use Ajax; you can view the HTML source of the page to check if the
9 | > site is actually using Ajax.
10 |
11 | --------------------------------
12 |
13 | If a website can load data without refreshing the page, it is using Ajax.
14 |
15 | Two features that reveal if a site uses Ajax:
16 | 1. Infinite scroll (like the one on twitter)
17 | 2. Maps loading new data when you zoom (like the one on Google maps)
18 |
19 | Three sites that use Ajax:
20 | 1. [Google Maps](https://www.google.com/maps/)
21 | 2. [Twitter](https://twitter.com/home)
22 | 3. Pretty much every website that uses [Ads](https://www.google.com/adsense/start/).
23 | Since the ads need to be refreshed, without refreshing the web page they need to use Ajax.
--------------------------------------------------------------------------------
/Ch09_Application_Development/9.2.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 2
3 | title: '9.2'
4 | ---
5 | > List some benefits and drawbacks of connectionless protocols over protocols
6 | > that maintain connections.
7 |
8 | --------------------------------
9 |
10 | Most computers have limits on the number of simultaneous connections they can
11 | accept. With connectionless protocols, connections are broken as soon as the
12 | request is satisfied, and therefore other clients can open connections. Thus
13 | more clients can be served at the same time. A request can be routed to any one
14 | of a number of different servers to balance load, and if a server crashes,
15 | another can take over without the client noticing any problem.
16 |
17 | The drawback of connectionless protocols is that a connection has to be
18 | reestablished every time a request is sent. Also, session information has
19 | to be sent each time in the form of cookies or hidden fields. This make
20 | them slower than the protocols which maintain connections in case state information
21 | is required.
--------------------------------------------------------------------------------
/Ch14_Indexing/14.26.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 26
3 | title: '14.26'
4 | ---
5 | > Some attributes of relations may contain sensitive data, and may be
6 | > required to be stored in an encrypted fashion. How does data encryption
7 | > affect index schemes? In particular, how might it affect schemes that
8 | > attempt to store data in sorted order?
9 |
10 | --------------------------------
11 |
12 | Let $r(A, B, C)$ be a relation. Suppose attribute $B$ of relation $r$ contains
13 | sensitive data and we want it encrypted. Suppose also we want to create an index
14 | on attribute $B$.
15 |
16 | But there are so many questions that we can ask from the above paragraph:
17 | 1. What kind of encryption algorithm are we going to use?
18 | 2. Are we going to create the index on attribute $B$, before it is encrypted or after?
19 | That is, are we going to index on the plain text values of attribute $B$ or the encrypted
20 | values of attribute $B$?
21 | 3. In what kinds of situation are we in? That is,
22 | what is the attack model? Who is Alice, Bob and Eve???
--------------------------------------------------------------------------------
/Ch04_Intermediate_SQL/4.18.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 18
3 | title: '4.18'
4 | ---
5 | > For the database of Figure 4.12, write a query to find the ID of each employee
6 | > with no manager. Note that an employee may simply have no manager listed or may
7 | > have a _null_ manager. Write your query using an outer join and then write it
8 | > again using no outer join at all.
9 |
10 | --------------------------------
11 |
12 | Note that, the primary key of the _manages_ relation is _id_. Thus each employee can
13 | have at most one manager.
14 |
15 | Using an outer join we can write the query as:-
16 |
17 | ```sql
18 | SELECT e.id
19 | FROM employee e LEFT OUTER JOIN manages m
20 | ON e.id = m.id
21 | WHERE m.id IS NULL
22 | OR m.manager_id IS NULL;
23 | ```
24 |
25 | Using no outer join we can write the query as:-
26 |
27 | ```sql
28 | SELECT id
29 | FROM employee
30 | WHERE id NOT IN (
31 | -- this gives us all of the employee ids that have a manager
32 | SELECT id
33 | FROM manages
34 | WHERE manager_id IS NOT NULL
35 | );
36 | ```
--------------------------------------------------------------------------------
/Ch11_Data_Analytics/11.8.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 8
3 | title: '11.8'
4 | ---
5 | > Consider each of the _takes_ and _teaches_ relations as a fact table; they do not
6 | > have an explicit measure attribute, but assume each table has a measure attribute reg_count
7 | > whose value is always 1. What would the dimension attributes and dimension tables
8 | > be in each case. Would the resultant schemas be star schemas or snowflake schemas?
9 |
10 | --------------------------------
11 |
12 | Dimension attributes:
13 |
14 | * Dimension attributes of the _takes_ relation: ID, course_id, sec_id, semester, year, grade
15 | * Dimension attributes of the _teaches_ relation: ID, course_id, sec_id, semester, year
16 |
17 | Dimension tables:
18 |
19 | * Dimension tables of the _takes_ relation: student, section, course, department, classroom, time_slot
20 | * Dimension tables of the _teaches_ relation: instructor, section, course, department, classroom, time_slot
21 |
22 |
23 | The resultant schema would be a **snowflake schema** ❄️.
--------------------------------------------------------------------------------
/Ch07_Relational_Database_Design/7.4.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 4
3 | title: '7.4'
4 | ---
5 | > Use Armstrong's axioms to prove the soundness of the union rule. (_Hint_: Use the
6 | > augmentation rule to show that, if $\alpha \rightarrow \beta$, then
7 | > $\alpha \rightarrow \alpha \beta$. Apply the augmentation rule again, using
8 | > $\alpha \rightarrow \gamma$, and then apply the transitivity rule.)
9 |
10 | --------------------------------
11 |
12 | To prove that:
13 |
14 | $$
15 | \text{if $\alpha \rightarrow \beta$ and $\alpha \rightarrow \gamma$ then $\alpha \rightarrow \beta \gamma$ }
16 | $$
17 |
18 | Following the hint, we derive:
19 |
20 | $$ \alpha \rightarrow \beta \quad \text{given}\\
21 | \alpha \alpha \rightarrow \alpha \beta \quad \text{augmentation rule}\\
22 | \alpha \rightarrow \alpha \beta \quad \text{union of identical sets}\\
23 | \alpha \rightarrow \gamma \quad \text{given}\\
24 | \alpha\beta \rightarrow \gamma\beta \quad \text{augmentation rule}\\
25 | \alpha \rightarrow \beta\gamma \quad \text{transitivity rule and set union commutativity}
26 | $$
--------------------------------------------------------------------------------
/Ch04_Intermediate_SQL/4.13.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 13
3 | title: '4.13'
4 | ---
5 | > Consider a view _v_ whose definition references only relation _r_.
6 | > * If a user is granted **select** authorization on _v_, does that user need to have
7 | > **select** authorization on _r_ as well? Why or why not? 
16 |
17 | --------------------------------
18 |
19 | a.
20 |
21 | 
22 |
23 | Note that `Blu_ray_discs` and `downloadable_videos` are weak entities while
24 | `video_in_bluray` and `video_on_net` are the identifying relationships sets.
25 | `video` is the identifying entity set and owns both of the weak entities.
26 |
27 | b.
28 |
29 | 
30 |
--------------------------------------------------------------------------------
/Ch07_Relational_Database_Design/7.14.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 14
3 | title: '7.14'
4 | ---
5 | > Show that there can be more than one canonical cover for a given set of functional
6 | > dependencies, using the following set of dependencies:
7 | > $$
8 | > X \rightarrow YZ, Y \rightarrow XZ, \text{ and } Z \rightarrow XY
9 | > $$
10 |
11 | --------------------------------
12 |
13 | Consider the first functional dependency. We can verify that $Z$ is extraneous in
14 | $X \rightarrow YZ$ and delete it. Subsequently, we can similarly check that $X$ is
15 | extraneous in $Y \rightarrow XZ$ and delete it, and that $Y$ is extraneous in
16 | $Z \rightarrow XY$ and delete it, resulting in a canonical cover
17 | $X \rightarrow Y, Y \rightarrow Z, Z \rightarrow X$.
18 |
19 | However, we can also verify that $Y$ is extraneous in $X \rightarrow YZ$ and delete it.
20 | Subsequently, we can similarly check that $Z$ is extraneous in $Y \rightarrow XZ$ and
21 | delete it, and that $X$ is extraneous in $Z \rightarrow XY$ and delete it, resulting
22 | in a canonical cover $X \rightarrow Z, Y \rightarrow X, Z \rightarrow Y$.
--------------------------------------------------------------------------------
/Ch14_Indexing/14.21.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 21
3 | title: '14.21'
4 | ---
5 | > Suppose you have to create a B+-tree index on a large number of names, where
6 | > the maximum size of a name may be quite large (say 40 characters) and the
7 | > average name is itself large (say 10 characters). Explain how prefix compression
8 | > can be used to maximize the average fanout of nonleaf nodes.
9 |
10 | --------------------------------
11 |
12 | With **prefix compression**, we do not store the entire search key value at nonleaf
13 | nodes. We only store a prefix of each search key value that is sufficient to distinguish
14 | between the key values in the subtrees that it separates. For example, if we had an
15 | index on names, the key values at a nonleaf node could be a prefix of a name; it may
16 | suffice to store "Silb" at a nonleaf node, instead of the full "Silberschatz" if the
17 | closest values in the two subtrees that it separates are, say, "Silas" and "Silver"
18 | respectively. Obviously "Silb" is going to occupy less space than "Silberschatz", thus
19 | maximizing the average fanout of nonleaf nodes.
--------------------------------------------------------------------------------
/Ch09_Application_Development/9.18.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 18
3 | title: '9.18'
4 | ---
5 | > Explain the terms CRUD and REST.
6 |
7 | --------------------------------
8 |
9 | * **CRUD** stands for **Create, Read, Update,** and **Delete**. They are the
10 | four basic operations of persistent storage. For more info, read the wiki page of CRUD:
11 | [wiki](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete)
12 |
13 | * **REST** stands for **Representational state transfer**. It is a software architectural
14 | style that describes a uniform interface between physically separate components, often
15 | across the Internet in a Client-Server architecture. In web development REST allows
16 | content to be rendered when it's requested, often referred to as Dynamic Content.
17 | RESTful Dynamic content uses server-side rendering to generate a website and
18 | send the content to the requesting web browser, which interprets the server's code and
19 | renders the page in the user's web browser. For more info, read the wiki page of REST:
20 | [wiki](https://en.wikipedia.org/wiki/Representational_state_transfer)
--------------------------------------------------------------------------------
/Ch14_Indexing/14.3.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 3
3 | title: '14.3'
4 | ---
5 | > Construct a B+-tree for the following set of key values:
6 | > $$
7 | > (2, 3, 5, 7, 11, 17, 19, 23, 29, 31)
8 | > $$
9 | > Assume that the tree is initially empty and values are added in
10 | > ascending order. Construct B+-trees for the case where the number
11 | > of pointers that will fit in one node is as follows:
12 | >
13 | > a. Four
14 | >
15 | > b. Six
16 | >
17 | > c. Eight
18 |
19 | --------------------------------
20 |
21 | The following were generated by inserting values into the B+-tree in ascending
22 | order. A node (other than the root) was never allowed to have fewer than
23 | $\lceil n / 2 \rceil$ values/pointers.
24 |
25 | > a. Four
26 |
27 | 
28 |
29 | > b. Six
30 |
31 | 
32 |
33 | > c. Eight
34 |
35 | 
36 |
37 | TODO: change the above 3 pngs into an animated gif that shows the insertion step by step.
38 |
39 | If you want to play with B+-tree animation, head on over to: [B+ tree animation](https://dichchankinh.com/~galles/visualization/BPlusTree.html).
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | MIT License
2 |
3 | Copyright (c) 2022 Noah Abe
4 |
5 | Permission is hereby granted, free of charge, to any person obtaining a copy
6 | of this software and associated documentation files (the "Software"), to deal
7 | in the Software without restriction, including without limitation the rights
8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 |
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 |
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 | SOFTWARE.
22 |
--------------------------------------------------------------------------------
/Ch15_Query_Processing/15.14.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 14
3 | title: '15.14'
4 | ---
5 | > Suggest how a document containing a word (such as "leopard") can be indexed
6 | > such that it is efficiently retrieved by queries using a more general concept
7 | > (such as "carnivore" or "mammal"). You can assume that the concept hierarchy is
8 | > not very deep, so each concept has only a few generalizations (a concept can,
9 | > however, have a large number of specializations). You can also assume that you are
10 | > provided with a function that returns the concept for each word in a document. Also
11 | > suggest how a query using a specialized concept can retrieve documents using a more
12 | > general concept.
13 |
14 | --------------------------------
15 |
16 | By using a **classification hierarchy** in which the general concepts lie in the upper parts
17 | of the hierarchy and the specializations lie in the lower parts of the hierarchy.
18 |
19 | I highly recommend reading **Section 31.9 Directories and Categories** from the
20 | online chapter of the book "[Chapter 31: Information Retrieval](https://www.db-book.com/online-chapters-dir/31.pdf)". It is free.
--------------------------------------------------------------------------------
/Ch04_Intermediate_SQL/4.4.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 4
3 | title: '4.4'
4 | ---
5 | > Suppose we have three relations $r(A,B)$, $s(B,C)$, and $t(B,D)$, with all attributes declared
6 | > as **not null**.
7 | > 
--------------------------------------------------------------------------------
/Ch14_Indexing/14.25.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 25
3 | title: '14.25'
4 | ---
5 | > Spatial indices that can index spatial intervals can conceptually be used to index
6 | > temporal data by treating valid time as a time interval. What is the problem
7 | > with doing so, and how is the problem solved?
8 |
9 | --------------------------------
10 |
11 | The problem of using a spatial index is that the end time of an interval may be infinity
12 | (perhaps represented by a very large value), whereas spatial indices typically assume that
13 | bounding boxes are finite, and may have poor performance if bounding boxes are very large.
14 | This problem can be dealt with as follows:
15 |
16 | * All current tuples (i.e., those with end time as infinity, which is perhaps represented
17 | by a large time value) are stored in a separate index from those tuples that have a non-infinite
18 | end time. The index on current tuples can be a B+-tree index.
19 |
20 | * Those tuples that are not current can be indexed by a spatial index. When performing
21 | a lookup, we look both in the spatial index and our B+-tree index.
22 |
23 | Read more in section 14.10.2 (Indexing Temporal Data).
--------------------------------------------------------------------------------
/Ch04_Intermediate_SQL/4.9.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 9
3 | title: '4.9'
4 | ---
5 | > SQL allows a foreign-key dependecy to refer to the same relation, as in the following
6 | > example:
7 | > ```sql
8 | > CREATE TABLE manager (
9 | > employee_id char(20),
10 | > manager_id char(20),
11 | > PRIMARY KEY employee_id,
12 | > FOREIGN KEY (manager_id) REFERENCES manager (employee_id)
13 | > ON DELETE CASCADE
14 | > );
15 | > ```
16 | > Here, _employee_id_ is a key to the table _manager_, meaning that each employee has at
17 | > at most one manager. The foreign-key clause requires that every manager also be an employee.
18 | > Explain exactly what happens when a tuple in the relation _manager_ is deleted.
19 |
20 | --------------------------------
21 |
22 | The tuples of all employees of the manager, at all levels, get deleted as well!
23 | This happens in a series of steps. The inital deletion will
24 | trigger deletion of all the tuples corresponding to direct
25 | employees of the manager. These deletions will in turn cause
26 | deletions of second-level employee tuples, and so on, till all
27 | direct and indirect employee tuples are deleted.
28 |
--------------------------------------------------------------------------------
/Ch06_Database_Design_Using_the_ER_Model/6.15.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 15
3 | title: '6.15'
4 | ---
5 | > Construct an E-R diagram for a hospital with a set of patients and a set of medical
6 | > doctors. Associate with each patient a log of the various tests and examinations
7 | > conducted.
8 |
9 | --------------------------------
10 |
11 | 
12 |
13 | `patientTests` is a ternary relationship set.
14 |
15 | Another method is, to make the `testsAndExaminations` entity a weak entity having identifying
16 | entity set `Patient`. And then adding a relationship set between the weak entity `testsAndExaminations`
17 | and `MedicalDoctor`, representing which medical doctor performed which test and examination.
18 | In fact doing that has the added benefit of constraining each entity in `testsAndExaminations` to a
19 | single `Patient`.
20 |
21 | But using a ternary relationship as depicted in the above diagram, also has its benefits. For example,
22 | if a group of patients are tested and examined by the same type of test and have the same result, we
23 | might associate each of the patients in the group to the same entity in `testsAndExaminations`.
--------------------------------------------------------------------------------
/Ch13_Data_Storage_Structures/13.8.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 8
3 | title: '13.8'
4 | ---
5 | > PostgreSQL normally uses a small buffer, leaving it to the operating system
6 | > buffer manager to manage the rest of main memory available for file system
7 | > buffering. Explain (a) What is the benefit of this approach, and
8 | > (b) one key limitation of this approach.
9 |
10 | --------------------------------
11 |
12 | The database system does not know what are the memory demands from other processes.
13 | By using a small buffer, PostgreSQL ensures that it does not grab too much of main memory.
14 | But at the same time, even if a block is evicted from the buffer, if the file system buffer
15 | manager has enough memory allocated to it, the evicted page is likely to still be cached
16 | in the file system buffer. Thus, a database buffer miss is often not very expensive
17 | since the block is still in the file system buffer.
18 |
19 | The drawback of this approach is that the database system may not be able to control
20 | the file system buffer replacement policy. Thus, the operating system may make suboptimal
21 | decisions on what to evict from the file system buffer.
--------------------------------------------------------------------------------
/Ch03_Introduction_to_SQL/3.17.md:
--------------------------------------------------------------------------------
1 | ---
2 | order: 17
3 | title: '3.17'
4 | ---
5 | > Consider the employee database of Figure 3.19. Give an expression in SQL for
6 | > each of the following queries.
7 | >
8 | > a. Give all employees for "First Bank Corporation" a 10 percent raise.
3 | 
4 |
24 | 
25 | 
--------------------------------------------------------------------------------