The Tables You Will Query
A board paper gives you a table and asks five things about it. This track does the same, except that the same three tables run through every page — so you spend your time on the queries instead of re-reading a new schema each time.
1Build them yourself
Type these in once and every question in this track will work on your own machine. Start with the database:
Then the three tables. dept first, because emp refers to it:
The last line of emp is the one to notice. The foreign key tells MySQL that a deptno in emp must be a department that really exists in dept — which is exactly why dept had to be created first. With it in place, a row pointing at a department that does not exist is refused rather than quietly stored:
create table if you like — nothing else in this chapter changes. Every page from here on asks you to read these tables with queries, and a query returns exactly the same answer whether the constraint is there or not. It is written in because emp and dept genuinely are related, and saying so in the schema is what makes “create dept first” mean something.Three tables, as promised:
2emp — the main table
PRI on empno is the primary key, and the MUL now sitting against deptno is the foreign key’s index — multiple rows are allowed to share a value there, which is right: a department has many employees.
3dept — the second table
deptno is the column the two tables have in common, and every two-table question on this track joins on it.
4item — the unseen table
item is kept back for the full board-style sets at the end, so that you meet it the way you will meet a table in the exam hall: cold.
5Degree and cardinality
Two words a paper asks for by name. Degree is the number of columns; cardinality is the number of rows. You can read both straight off the output above — describe ends with the column count, and a select * ends with the row count.
6Four things planted on purpose
Bina Sharma, Emil Lepcha and Ishan Pradhan. Every NULL question uses them.
Emil Lepcha and Jyoti Tamang — so count(city) and count(*) disagree.
Her deptno is NULL, so she vanishes from every join. That is the point.
Department 40 exists in dept but appears in no employee row.
What is the degree and cardinality of the emp table?
If you insert one more employee, what changes?