- Added database implementation assignment documents from INFO 212 2011 and redesigned for INFO 214 2012.

nigel.stanger / sqlmarker

Browse code - Added database implementation assignment documents from INFO 212 2011 and redesigned for INFO 214 2012. master
0 parent commit bc7f0c4d70f162715434f6693ad4fde2701b9433 nstanger authored on 23 Jul 2012

Patch

Showing 4 changed files

Ignore Space Show notes View BDL.xml 0 → 100755
<?xml version="1.0" standalone="yes"?> <document class="fragment"> <section label="sec:database-info"> <title>System specification and details</title> <p>Better Digital, Ltd. (BDL) is a large U.S. company that produces a wide range of consumer electronics devices such as radios, stereo components, digital clocks, universal remotes, etc., which they sell in bulk to various retailers. The company has branches in several major U.S. cities, and employs about <number>9000</number> staff across six departments: Central Management, Sales <ampersand/> Marketing, Personnel, Manufacturing, Inventory and Accounts.</p> <p>BDL are currently designing and implementing a new corporate database that will be located at the company headquarters in Los Angeles. The requirements analysis phase of the project is almost complete, and you have been brought in as a lead database developer. It will be your task to implement an initial prototype of the specification resulting from the requirements analysis phase. An ERD of the proposed database is shown in <hyperlink label="fig-erd"><reference label="fig-erd"/></hyperlink>, and more detailed specifications of the database requirements may be found in the following sections.</p> <figure label="fig-erd" latex-placement="!hb"> <caption>ERD of Better Digital’s database (Barker notation)</caption> <image basename="BDL_barker" location="images"> <description>ERD of Better Digital’s database (Barker notation)</description> </image> </figure> <section> <title>The <tt>Staff</tt> entity</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row-rule/> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt><hash/></tt></cell> <cell><code>Staff_ID</code></cell> <cell>Internally generated 7 digit identifier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Surname</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Firstnames</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Phone</code></cell> <cell>(see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Address</code></cell> <cell>Up to 150 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Department</code></cell> <cell>(see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Position</code></cell> <cell>(see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Salary</code></cell> <cell>Monetary, <dollar-sign/><number>1000.00</number><endash/><dollar-sign/><number>99999.99</number></cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Comments</code></cell> <cell>Arbitrary text</cell> </row> <row-rule/> </tabular-body> </tabular> <itemised-list> <item>As noted above, BDL has about <number>9000</number> employees. The usual details such as name, address and phone number will be recorded. The phone number must cater for both (U.S.) landline and mobile numbers.</item> <item>There are six possible departments, as follows: <quote>Central Management</quote>, <quote>Sales <ampersand /> Marketing</quote>, <quote>Personnel</quote>, <quote>Manufacturing</quote>, <quote>Inventory</quote> and <quote>Accounts</quote>.</item> <item>There are twenty possible employee positions, as follows: <quote>CEO</quote>, <quote>CTO</quote>, <quote>CFO</quote>, <quote>CIO</quote>, <quote>Director</quote>, <quote>President</quote>, <quote>Vice-President</quote>, <quote>Manager</quote>, <quote>Personal Assistant</quote>, <quote>Secretary</quote>, <quote>Technician</quote>, <quote>Researcher</quote>, <quote>Designer</quote>, <quote>Assembler</quote>, <quote>Programmer</quote>, <quote>Contractor</quote>, <quote>Sales Representative</quote>, <quote>Accountant</quote>, <quote>Inventory</quote> and <quote>Assistant</quote>.</item> <item>Salary values are monthly.</item> </itemised-list> </section> <section label="sec:customer"> <title>The <tt>Customer</tt> entity</title> <tabular border="1" align="left"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row> <cell header="yes" columns="3" align="left"><tt>Customer</tt></cell> </row> <row-rule /> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt><hash/></tt></cell> <cell><code>Customer_ID</code></cell> <cell>Internally generated 7 digit identifier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Name</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Contact_Person</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Phone</code></cell> <cell>(see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Address</code></cell> <cell>Up to 200 characters</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Email</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Comments</code></cell> <cell>Arbitrary text</cell> </row> <row-rule/> </tabular-body> </tabular> <vskip size="medium"/> <p indent="no">BDL’s customers are retail outlets of various sizes. BDL currently has about <number>400000</number> customers on its books, increasing by about <number>10000</number> per year. The usual details will be recorded for each customer: name, address, phone and optionally the name of a contact person and an email address. The phone number must cater for full international numbers, as many of BDL’s customers are based outside the U.S.</p> </section> <section label="sec:supplier"> <title>The <tt>Supplier</tt> entity</title> <tabular border="1" align="left"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row> <cell header="yes" columns="3" align="left"><tt>Supplier</tt></cell> </row> <row-rule /> <row> <cell><tt><hash/></tt></cell> <cell><code>Supplier_ID</code></cell> <cell>Internally generated 7 digit identifier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Name</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Contact_Person</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Phone</code></cell> <cell>(see description for <code>Customer</code> entity)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Address</code></cell> <cell>Up to 200 characters</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Email</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Comments</code></cell> <cell>Arbitrary text</cell> </row> <row-rule/> </tabular-body> </tabular> <vskip size="medium"/> <p indent="no">BDL orders components from a small group of trusted suppliers (of which there are currently thirty-three). Many of these suppliers overlap in the components that they supply, thus enabling BDL to take advantage of special deals, and providing alternative sources for components. BDL normally buys components from the supplier offering the best deal at the time of ordering (pricing data will not be stored in the database because they change too frequently). The details to be recorded for suppliers are identical to those for customers.</p> </section> <section> <title>The <tt>Product</tt> entity</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row-rule/> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt><hash/></tt></cell> <cell><code>Product_Code</code></cell> <cell>Internally generated 8 digit identifier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Description</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Stock_Count</code></cell> <cell>Number of units in stock, 0<endash/><number>99999</number></cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Restock_Level</code></cell> <cell>Number of units to restock to, 0<endash/><number>99999</number> (see below)</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Minimum_Level</code></cell> <cell>Threshold at which restocking occurs (see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>List_Price</code></cell> <cell>Monetary, <dollar-sign/>0.00<endash/><dollar-sign/><number>99999.99</number></cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Assembly_Manual</code></cell> <cell>Assembly instructions in PDF format</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Assembly_Program</code></cell> <cell>Compiled Java class for assembly line</cell> </row> <row-rule/> </tabular-body> </tabular> <itemised-list> <item>BDL currently manufactures <number>16492</number> different products, which are assembled from various components (resistors, capacitors, controller chips, power supplies, cases, etc.). BDL can manufacture products on demand in response to a sale, but they also produce an ongoing supply of the most popular products. These are stored in a warehouse and used to fulfil sales.</item> <item>Popular products have a <quote>restock</quote> and a <quote>minimum</quote> stock level. If the stock count for a product falls below the minimum level, an alert is raised by the inventory management application to Inventory staff, who then request Manufacturing to make more of the product. Manufacturing then produce enough units to bring the number in stock back up to at least the restock level (the smallest possible production run is fifty units). The minimum level must therefore be smaller than the restock level; it may be zero.</item> <item>The database will contain the assembly instructions for each product, where applicable. The <code>Assembly_Manual</code> column will contain a PDF detailing the assembly procedure for each product in human-readable form. These PDFs will average about 150 KB each. The <code>Assembly_Program</code> column will contain a compiled Java class file that can be downloaded from the database and used to control one of BDL’s fifty automated assembly lines. These files will average about 50 KB each.</item> </itemised-list> </section> <section> <title>The <tt>Component</tt> entity</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row-rule/> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt><hash/></tt></cell> <cell><code>Component_Code</code></cell> <cell>Internally generated 8 digit identifier</cell> </row> <row> <cell><tt><hash/></tt></cell> <cell><code>Suppliers_Code</code></cell> <cell>Up to 25 character identifier provided by supplier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Description</code></cell> <cell>Up to 100 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Stock_Count</code></cell> <cell>Number of units in stock, 0<endash/><number>9999999</number></cell> </row> <row-rule/> </tabular-body> </tabular> <itemised-list> <item>Components are ordered from suppliers and used to assemble products. BDL currently uses about <number>120000</number> different components. While BDL always has some components in stock, it usually works on a <quote>just-in-time</quote> ordering system, where components are ordered shortly before they are actually required. This means that there will be frequent small orders to suppliers for components.</item> <item>The same component may be used in many different products, and multiple times in the same product.</item> <item>The same component is often provided by more than one supplier. For example, <quote>35 ohm resistor</quote> might be available from thirteen different suppliers, at varying prices (pricing data will not be stored in the database because they change too frequently). Although it leads to duplication of component descriptions, BDL have decided for practical reasons to individually store details of each component from each supplier (so in the example above, <quote>35 ohm resistor</quote> would appear thirteen times).</item> <item>Since BDL has no control over how suppliers identify their components, different suppliers may sometimes use the same component codes for different components. For example, Western Electronics may use the code <quote>BC882719</quote> for 35 ohm resistors, whereas Eastern Electrical Supplies may use the same code for large red LEDs.</item> </itemised-list> </section> <section label="sec:assembly"> <title>The <tt>Assembly</tt> entity</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row-rule /> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule /> <row> <cell><tt></tt></cell> <cell><code>Quantity</code></cell> <cell>Number of units of this component used, 1–<number>9999</number></cell> </row> <row-rule /> </tabular-body> </tabular> <vskip size="medium" /> <paragraph indent="no">Each product can be made from at least two up to hundreds of distinct components. Some components (e.g., transistors) occur many times in the same product.</paragraph> </section> <section label="sec:sales"> <title>The <tt>Sale<underscore />head</tt> and <tt>Sale<underscore />line</tt> entities</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row> <cell header="yes" columns="3" align="left"><tt>Sale<underscore />head</tt></cell> </row> <row-rule /> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule /> <row> <cell><tt><hash/></tt></cell> <cell><code>Sale_Num</code></cell> <cell>Internally generated 10 digit identifier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Sale_Date</code></cell> <cell>Date and time of sale (cannot be in future)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Status</code></cell> <cell>Current status of sale (see below)</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Comments</code></cell> <cell>Arbitrary text</cell> </row> <row-rule /> </tabular-body> </tabular> <tabular border="1" align="left"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row> <cell header="yes" columns="3" align="left"><tt>Sale<underscore />line</tt></cell> </row> <row-rule /> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule /> <row> <cell><tt></tt></cell> <cell><code>Quantity</code></cell> <cell>Number of units of a product sold, up to <number>9999</number></cell> </row> <row> <cell><tt></tt></cell> <cell><code>Actual_Price</code></cell> <cell>Unit sale price, <dollar-sign/>0.00<endash/><dollar-sign/><number>99999.99</number></cell> </row> <row-rule /> </tabular-body> </tabular> <itemised-list> <item>On a typical working day, BDL makes about seven thousand sales. Each sale is typically for some quantity (possibly several thousand) of each of about seven to ten different products. For example, a customer might buy twenty-three remote garage door openers and two burglar alarm systems in the same sale.</item> <item>Products may sell for a different (usually lower) price from that listed (e.g., bulk discounts, cash payments, etc.).</item> <item>The status of a sale must be one of the following: <quote>pending</quote>, <quote>in progress</quote>, <quote>cancelled</quote>, <quote>backordered</quote> or <quote>shipped</quote>.</item> </itemised-list> </section> <section label="sec:orders"> <title>The <tt>Order<underscore />head</tt> and <tt>Order<underscore />line</tt> entities</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row> <cell header="yes" columns="3" align="left"><tt>Order<underscore />head</tt></cell> </row> <row-rule /> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule /> <row> <cell><tt><hash/></tt></cell> <cell><code>Order_Num</code></cell> <cell>Internally generated 10 digit identifier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Order_Date</code></cell> <cell>Date and time of order (cannot be in future)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Due_Date</code></cell> <cell>Date that final shipment is due (after <code>Order_Date</code>)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Status</code></cell> <cell>Current status of order (see below)</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Comments</code></cell> <cell>Arbitrary text</cell> </row> <row-rule /> </tabular-body> </tabular> <tabular border="1" align="left"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row> <cell header="yes" columns="3" align="left"><tt>Order<underscore />line</tt></cell> </row> <row-rule /> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule /> <row> <cell><tt></tt></cell> <cell><code>Qty_Ordered</code></cell> <cell>Number units of a component ordered, up to <number>99999</number></cell> </row> <row> <cell><tt></tt></cell> <cell><code>Price</code></cell> <cell>Unit price (see below)</cell> </row> <row> <cell><tt>*</tt></cell> <cell><code>Qty_Received</code></cell> <cell>Number of components received (see below)</cell> </row> <row-rule /> </tabular-body> </tabular> <itemised-list> <item>BDL places an average of about 320 orders to suppliers per working day. Each order is typically for some quantity (possibly tens of thousands) of each of about fifteen to twenty different components.</item> <item>Since pricing data will not be stored with the actual component data, the unit prices paid for components must be recorded on the order. Prices are in the range <dollar-sign/>0.00<endash/><dollar-sign/><number>9999.99</number>.</item> <item>Components arrive in shipments from a supplier, which may or may not correspond to the original order (for example, a single shipment might include components from several different orders to that supplier). When a shipment arrives, the Inventory staff need to note on the original order how many of each component they have received, so that they can determine when the order is complete (this happens when the number of components received is equal to the number of components ordered). This will also enable them to tell when they have received more components than they originally ordered.</item> <item>The status of an order must be one of the following: <quote>in progress</quote> or <quote>complete</quote>.</item> </itemised-list> </section> </section> </document>

Ignore Space Show notes View

BDL.xml 0 → 100755

<?xml version="1.0" standalone="yes"?>

<section label="sec:database-info">
	
		<title>System specification and details</title>

Better Digital, Ltd. (BDL) is a large U.S. company that produces a wide range of consumer electronics devices such as radios, stereo components, digital clocks, universal remotes, etc., which they sell in bulk to various retailers. The company has branches in several major U.S. cities, and employs about <number>9000</number> staff across six departments: Central Management, Sales <ampersand/> Marketing, Personnel, Manufacturing, Inventory and Accounts.
		
		BDL are currently designing and implementing a new corporate database that will be located at the company headquarters in Los Angeles. The requirements analysis phase of the project is almost complete, and you have been brought in as a lead database developer. It will be your task to implement an initial prototype of the specification resulting from the requirements analysis phase. An ERD of the proposed database is shown in <hyperlink label="fig-erd"><reference label="fig-erd"/></hyperlink>, and more detailed specifications of the database requirements may be found in the following sections.

<figure label="fig-erd" latex-placement="!hb">
			<caption>ERD of Better Digital’s database (Barker notation)</caption>
			<image basename="BDL_barker" location="images">
				<description>ERD of Better Digital’s database (Barker notation)</description>
			</image>
		</figure>

<section>
		
			<title>The <tt>Staff</tt> entity</title>

<tabular border="1">
				<tabular-columns>
					<column align="center" left-border="|" right-border="|"/>
					<column align="left" right-border="|"/>
					<column align="left" right-border="|"/>
				</tabular-columns>
				<tabular-body>
					<row-rule/>
					<row>
						<cell header="yes"/>
						<cell header="yes">Column</cell>
						<cell header="yes">Description</cell>
					</row>
					<row-rule/>
					<row>
						<cell><tt><hash/></tt></cell>
						<cell><code>Staff_ID</code></cell>
						<cell>Internally generated 7 digit identifier</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Surname</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Firstnames</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Phone</code></cell>
						<cell>(see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Address</code></cell>
						<cell>Up to 150 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Department</code></cell>
						<cell>(see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Position</code></cell>
						<cell>(see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Salary</code></cell>
						<cell>Monetary, <dollar-sign/><number>1000.00</number><endash/><dollar-sign/><number>99999.99</number></cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Comments</code></cell>
						<cell>Arbitrary text</cell>
					</row>
					<row-rule/>
				</tabular-body>
			</tabular>

<itemised-list>

<item>As noted above, BDL has about <number>9000</number> employees. The usual details such as name, address and phone number will be recorded. The phone number must cater for both (U.S.) landline and mobile numbers.</item>
				
				<item>There are six possible departments, as follows: <quote>Central Management</quote>, <quote>Sales <ampersand /> Marketing</quote>, <quote>Personnel</quote>, <quote>Manufacturing</quote>, <quote>Inventory</quote> and <quote>Accounts</quote>.</item>
			
				<item>There are twenty possible employee positions, as
				follows: <quote>CEO</quote>, <quote>CTO</quote>, <quote>CFO</quote>, <quote>CIO</quote>, <quote>Director</quote>, <quote>President</quote>, <quote>Vice-President</quote>, <quote>Manager</quote>, <quote>Personal Assistant</quote>, <quote>Secretary</quote>, <quote>Technician</quote>, <quote>Researcher</quote>, <quote>Designer</quote>, <quote>Assembler</quote>, <quote>Programmer</quote>, <quote>Contractor</quote>, <quote>Sales Representative</quote>, <quote>Accountant</quote>, <quote>Inventory</quote> and <quote>Assistant</quote>.</item>
				
				<item>Salary values are monthly.</item>
			
			</itemised-list>
			
		</section>

<section label="sec:customer">
		
			<title>The <tt>Customer</tt> entity</title>

BDL’s customers are retail outlets of various sizes. BDL currently has about <number>400000</number> customers on its books, increasing by about <number>10000</number> per year. The usual details will be recorded for each customer: name, address, phone and optionally the name of a contact person and an email address. The phone number must cater for full international numbers, as many of BDL’s customers are based outside the U.S.
			
		</section>

<section label="sec:supplier">
		
			<title>The <tt>Supplier</tt> entity</title>
				
			<tabular border="1" align="left">
				<tabular-columns>
					<column align="center" left-border="|" right-border="|"/>
					<column align="left" right-border="|"/>
					<column align="left" right-border="|"/>
				</tabular-columns>
				<tabular-body>
					<row>
						<cell header="yes" columns="3" align="left"><tt>Supplier</tt></cell>
					</row>
					<row-rule />
					<row>
						<cell><tt><hash/></tt></cell>
						<cell><code>Supplier_ID</code></cell>
						<cell>Internally generated 7 digit identifier</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Name</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Contact_Person</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Phone</code></cell>
						<cell>(see description for <code>Customer</code> entity)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Address</code></cell>
						<cell>Up to 200 characters</cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Email</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Comments</code></cell>
						<cell>Arbitrary text</cell>
					</row>
					<row-rule/>
				</tabular-body>
			</tabular>

<vskip size="medium"/>
			
			BDL orders components from a small group of trusted suppliers (of which there are currently thirty-three). Many of these suppliers overlap in the components that they supply, thus enabling BDL to take advantage of special deals, and providing alternative sources for components. BDL normally buys components from the supplier offering the best deal at the time of ordering (pricing data will not be stored in the database because they change too frequently). The details to be recorded for suppliers are identical to those for customers.

</section>

<section>
		
			<title>The <tt>Product</tt> entity</title>

<tabular border="1">
				<tabular-columns>
					<column align="center" left-border="|" right-border="|"/>
					<column align="left" right-border="|"/>
					<column align="left" right-border="|"/>
				</tabular-columns>
				<tabular-body>
					<row-rule/>
					<row>
						<cell header="yes"/>
						<cell header="yes">Column</cell>
						<cell header="yes">Description</cell>
					</row>
					<row-rule/>
					<row>
						<cell><tt><hash/></tt></cell>
						<cell><code>Product_Code</code></cell>
						<cell>Internally generated 8 digit identifier</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Description</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Stock_Count</code></cell>
						<cell>Number of units in stock, 0<endash/><number>99999</number></cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Restock_Level</code></cell>
						<cell>Number of units to restock to, 0<endash/><number>99999</number> (see below)</cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Minimum_Level</code></cell>
						<cell>Threshold at which restocking occurs (see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>List_Price</code></cell>
						<cell>Monetary, <dollar-sign/>0.00<endash/><dollar-sign/><number>99999.99</number></cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Assembly_Manual</code></cell>
						<cell>Assembly instructions in PDF format</cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Assembly_Program</code></cell>
						<cell>Compiled Java class for assembly line</cell>
					</row>
					<row-rule/>
				</tabular-body>
			</tabular>

<itemised-list>
			
				<item>BDL currently manufactures <number>16492</number> different products, which are assembled from various components (resistors, capacitors, controller chips, power supplies, cases, etc.). BDL can manufacture products on demand in response to a sale, but they also produce an ongoing supply of the most popular products. These are stored in a warehouse and used to fulfil sales.</item>
				
				<item>Popular products have a <quote>restock</quote> and a <quote>minimum</quote> stock level. If the stock count for a product falls below the minimum level, an alert is raised by the inventory management application to Inventory staff, who then request Manufacturing to make more of the product. Manufacturing then produce enough units to bring the number in stock back up to at least the restock level (the smallest possible production run is fifty units). The minimum level must therefore be smaller than the restock level; it may be zero.</item>
				
				<item>The database will contain the assembly instructions for each product, where applicable. The <code>Assembly_Manual</code> column will contain a PDF detailing the assembly procedure for each product in human-readable form. These PDFs will average about 150 KB each. The <code>Assembly_Program</code> column will contain a compiled Java class file that can be downloaded from the database and used to control one of BDL’s fifty automated assembly lines. These files will average about 50 KB each.</item>
				
			</itemised-list>
			
		</section>

<section>
		
			<title>The <tt>Component</tt> entity</title>

<itemised-list>

<item>Components are ordered from suppliers and used to assemble products. BDL currently uses about <number>120000</number> different components. While BDL always has some components in stock, it usually works on a <quote>just-in-time</quote> ordering system, where components are ordered shortly before they are actually required. This means that there will be frequent small orders to suppliers for components.</item>
				
				<item>The same component may be used in many different products, and multiple times in the same product.</item>
				
				<item>The same component is often provided by more than one supplier. For example, <quote>35 ohm resistor</quote> might be available from thirteen different suppliers, at varying prices (pricing data will not be stored in the database because they change too frequently). Although it leads to duplication of component descriptions, BDL have decided for practical reasons to individually store details of each component from each supplier (so in the example above, <quote>35 ohm resistor</quote> would appear thirteen times).</item>
				
				<item>Since BDL has no control over how suppliers identify their components, different suppliers may sometimes use the same component codes for different components. For example, Western Electronics may use the code <quote>BC882719</quote> for 35 ohm resistors, whereas Eastern Electrical Supplies may use the same code for large red LEDs.</item>
				
			</itemised-list>
			
		</section>

<section label="sec:assembly">
		
			<title>The <tt>Assembly</tt> entity</title>

<paragraph indent="no">Each product can be made from at least two up to hundreds of distinct components. Some components (e.g., transistors) occur many times in the same product.</paragraph>
			
		</section>

<title>The <tt>Sale<underscore />head</tt> and <tt>Sale<underscore />line</tt> entities</title>

<tabular border="1">
				<tabular-columns>
					<column align="center" left-border="|" right-border="|"/>
					<column align="left" right-border="|"/>
					<column align="left" right-border="|"/>
				</tabular-columns>
				<tabular-body>
					<row>
						<cell header="yes" columns="3" align="left"><tt>Sale<underscore />head</tt></cell>
					</row>
					<row-rule />
					<row>
						<cell header="yes"/>
						<cell header="yes">Column</cell>
						<cell header="yes">Description</cell>
					</row>
					<row-rule />
					<row>
						<cell><tt><hash/></tt></cell>
						<cell><code>Sale_Num</code></cell>
						<cell>Internally generated 10 digit identifier</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Sale_Date</code></cell>
						<cell>Date and time of sale (cannot be in future)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Status</code></cell>
						<cell>Current status of sale (see below)</cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Comments</code></cell>
						<cell>Arbitrary text</cell>
					</row>
					<row-rule />
				</tabular-body>
			</tabular>

<itemised-list>
			
				<item>On a typical working day, BDL makes about seven thousand sales. Each sale is typically for some quantity (possibly several thousand) of each of about seven to ten different products. For example, a customer might buy twenty-three remote garage door openers and two burglar alarm systems in the same sale.</item>
				
				<item>Products may sell for a different (usually lower) price from that listed (e.g., bulk discounts, cash payments, etc.).</item>
				
				<item>The status of a sale must be one of the following: <quote>pending</quote>, <quote>in progress</quote>, <quote>cancelled</quote>, <quote>backordered</quote> or <quote>shipped</quote>.</item>
				
			</itemised-list>

</section>

<section label="sec:orders">
		
			<title>The <tt>Order<underscore />head</tt> and <tt>Order<underscore />line</tt> entities</title>

<tabular border="1">
				<tabular-columns>
					<column align="center" left-border="|" right-border="|"/>
					<column align="left" right-border="|"/>
					<column align="left" right-border="|"/>
				</tabular-columns>
				<tabular-body>
					<row>
						<cell header="yes" columns="3" align="left"><tt>Order<underscore />head</tt></cell>
					</row>
					<row-rule />
					<row>
						<cell header="yes"/>
						<cell header="yes">Column</cell>
						<cell header="yes">Description</cell>
					</row>
					<row-rule />
					<row>
						<cell><tt><hash/></tt></cell>
						<cell><code>Order_Num</code></cell>
						<cell>Internally generated 10 digit identifier</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Order_Date</code></cell>
						<cell>Date and time of order (cannot be in future)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Due_Date</code></cell>
						<cell>Date that final shipment is due (after <code>Order_Date</code>)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Status</code></cell>
						<cell>Current status of order (see below)</cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Comments</code></cell>
						<cell>Arbitrary text</cell>
					</row>
					<row-rule />
				</tabular-body>
			</tabular>

</section>
	
	</section>

</document>

Ignore Space Show notes View STINK_postgrad.xml 0 → 100755
<?xml version="1.0" standalone="yes"?> <document class="fragment"> <section label="sec:database-info"> <title>System specification and details</title> <p>The Southern Technical Institute for Natural Knowledge is a medium-sized tertiary education provider, founded in 1982, which teaches papers across many subjects leading to many different qualifications. They began offering postgraduate degrees in 2008, and are in the process of designing and implementing a database to keep track of their postgraduate students. The requirements analysis and conceptual design phases of the project are complete, and you have been brought in as lead database developer. Your task is to verify the soundness of the conceptual specification by implementing an initial prototype based on it. A design-level entity-relationship diagram of the proposed database is shown in <hyperlink label="fig:erd"><reference label="fig:erd"/></hyperlink>, and more detailed specifications of the database requirements may be found in the following sections.</p> <figure label="fig:erd" latex-placement="!hb"> <caption>Design-level ERD of the proposed database</caption> <image basename="STINK_postgrad" location="images"> <description>Design-level ERD of the proposed database</description> </image> </figure> <section> <title>The <tt>Degree</tt> entity</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row-rule/> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt><hash/></tt></cell> <cell><code>Abbreviation</code></cell> <cell>Up to 10 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Full_Name</code></cell> <cell>Up to 100 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Degree_Type</code></cell> <cell>(see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Funding_Limit</code></cell> <cell>Zero or greater</cell> </row> <row-rule/> </tabular-body> </tabular> <itemised-list> <item>The abbreviation is a short string identifying the postgraduate degree, for example, <quote>PhD</quote>, <quote>MSc</quote>, <quote>PGDipCom</quote>.</item> <item>The degree type must be one of the following: <quote>Taught</quote>, <quote>Papers <ampersand/> thesis</quote> or <quote>Thesis only</quote>.</item> <item>The funding limit specifies the maximum number of years that the degree will be funded by the government, for example, four years for a PhD. This may not always be a whole number.</item> </itemised-list> <answer> <p><strong>Degree</strong>{<underline>Abbreviation</underline>, Full<underscore />Name, Degree<underscore />Type, Funding<underscore />Limit}</p> <code-block> CREATE TABLE Degree ( Abbreviation VARCHAR2(10), Full_Name VARCHAR2(100) NOT NULL, Degree_Type VARCHAR2(15) NOT NULL CHECK ( Degree_Type IN ( 'Taught', 'Papers & thesis', 'Thesis only' ) ), Funding_Limit NUMBER(3,1) NOT NULL CHECK ( Funding_Limit >= 0 ) -- PRIMARY KEY (Abbreviation) ); </code-block> <p>Some people added lookup tables for things like degree types. Strictly speaking, this isn<apostrophe />t really part of of the schema transformation (the schema will work fine either with or without lookup tables), but in general there is nothing wrong with doing this, <em>as long as it doesn<apostrophe />t change the specification</em>. Some people did do this correctly, by simply using the existing values (which are already unique) as the primary key of the new lookup table. For example, the <code>Degree_Type</code> table would consist of a single column <code>Degree_Type</code>, which contained the valid values for degree types, and was also the primary key. Other people got carried away and invented unnecessary surrogate keys for their lookup tables, thus completely breaking the specification.</p> </answer> </section> <section> <title>The <tt>Student</tt> entity</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row-rule/> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt><hash/></tt></cell> <cell><code>Student_ID</code></cell> <cell>Internally generated 7 digit identifier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Surname</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Other_Names</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Contact_Phone</code></cell> <cell>(see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Contact_Address</code></cell> <cell>Up to 200 characters</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Home_Phone</code></cell> <cell>(see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Home_Address</code></cell> <cell>Up to 200 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Username</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>International</code></cell> <cell>Boolean, default false</cell> </row> <row-rule/> </tabular-body> </tabular> <vskip size="large"/> <p indent="no">Many students are international, so phone numbers must cater for this.</p> <answer> <p><strong>Student</strong>{<underline>Student<underscore />ID</underline>, Surname, Other<underscore />Names, Contact<underscore />Phone, Contact<underscore />Address, Home<underscore />Phone, Home<underscore />Address, Username, International, Degree<underscore />Code); Degree<underscore />Code FK to <strong>Degree</strong>.</p> <code-block> CREATE TABLE Student ( Student_ID NUMBER(7), Surname VARCHAR2(50) NOT NULL, Other_Names VARCHAR2(50) NOT NULL, Contact_Phone VARCHAR2(15), -- at least 15, maybe more -- for international numbers Contact_Address VARCHAR2(200) NOT NULL, Home_Phone VARCHAR2(15), Home_Address VARCHAR2(200) NOT NULL, Username VARCHAR2(50) NOT NULL, International CHAR(1) DEFAULT 'F' NOT NULL CHECK ( International IN ( 'T', 'F' ) ), Degree_Code VARCHAR2(10) NOT NULL, -- PRIMARY KEY (Student_ID), FOREIGN KEY (Degree_Code) REFERENCES Degree (Abbreviation) ); </code-block> <p>Remember that <code>ON DELETE CASCADE</code> is not appropriate in all cases! Many people added an <code>ON DELETE CASCADE</code> to the foreign key from <code>Student</code> to <code>Degree</code>, but if you think about how the organisation would work, this doesn<apostrophe />t make any sense. Why should deleting a degree cause all students enrolled in that degree to also be deleted? This is equivalent to expelling the student (actually, worse, since even expelled students probably wouldn<apostrophe />t have their data deleted). It<apostrophe />s much more likely that the affected students would be reassigned to a different degree (or at the very least to a <quote>dummy</quote> placeholder degree until their status is resolved).</p> </answer> </section> <section> <title>The <tt>Enrolment</tt> entity</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row-rule/> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt><hash/></tt></cell> <cell><code>Enrolment_ID</code></cell> <cell>Internally generated 10 digit identifier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Description</code></cell> <cell>Up to 100 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Year_Enrolled</code></cell> <cell>4 digits</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Grade</code></cell> <cell>(see below)</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Comments</code></cell> <cell>Arbitrary text</cell> </row> <row-rule/> </tabular-body> </tabular> <itemised-list> <item>The year of enrolment cannot be earlier than the year in which the Institute started offering postgraduate degrees.</item> <item>For a paper, the grade must be one of the following: <quote>E</quote>, <quote>D</quote>, <quote>C<endash/></quote>, <quote>C</quote>, <quote>C+</quote>, <quote>B<endash/></quote>, <quote>B</quote>, <quote>B+</quote>, <quote>A<endash/></quote>, <quote>A</quote> or <quote>A+</quote>. For a thesis, the grade must be one of the following: <quote>Fail</quote>, <quote>Pass</quote>, <quote>Credit</quote>, <quote>Distinction</quote> or <quote>Incomplete</quote>.</item> </itemised-list> <answer> <p><strong>Enrolment</strong>(<underline>Enrolment<underscore />ID</underline>, Description, Year<underscore />Enrolled, Grade, Comments, Component<underscore />Code, Student<underscore />ID); Component<underscore />Code FK to <strong>Component</strong>, Student<underscore />ID FK to <strong>Student</strong></p> <code-block> CREATE TABLE Enrolment ( Enrolment_ID NUMBER(10), Description VARCHAR2(100) NOT NULL, Year_Enrolled NUMBER(4) NOT NULL CHECK ( Year_Enrolled >= 2008 ), Result VARCHAR2(11) NOT NULL CHECK ( Result IN ( 'E', 'D', 'C-', 'C', 'C+', 'B-', 'B', 'B+', 'A-', 'A', 'A+', 'Fail', 'Pass', 'Credit', 'Distinction', 'Incomplete' ) ) Comments VARCHAR2(4000), -- or CLOB (LONG is deprecated) Student_ID NUMBER(7) NOT NULL, Component_Code CHAR(7) NOT NULL, -- PRIMARY KEY (Enrolment_ID), FOREIGN KEY (Student_ID) REFERENCES Student, FOREIGN KEY (Component_Code) REFERENCES Component ); </code-block> <p><code>ON DELETE CASCADE</code> <em>does</em> make sense for the <code>Student_ID</code> foreign key here (and also for the foreign keys in <code>Staff_Component</code>), because the existence of these data is very tightly linked with the associated data. This is a very good illustration of the point that we need to consider not just structural aspects of a problem when building a database, but also procedural aspects.</p> </answer> </section> <section> <title>The <tt>Component</tt> entity and its subtypes</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row> <cell header="yes" columns="3"><tt>Component</tt></cell> </row> <row-rule/> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt><hash/></tt></cell> <cell><code>Component_Code</code></cell> <cell>7 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Title</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Description</code></cell> <cell>Up to 200 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Points</code></cell> <cell>Integer, default 20 (also see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Period</code></cell> <cell>(see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Component_Type</code></cell> <cell>(see below)</cell> </row> <row-rule/> </tabular-body> </tabular> <itemised-list> <item>The component code comprises a four-letter subject code (e.g., <quote>INFO</quote>) followed by a three digit course number (e.g., <quote>212</quote>). The course numbers for Diploma, Masters<apostrophe/> and PhD theses are 480, 580 and 980 respectively.</item> <item>The period of a component must be one of the following: <quote>SS</quote> (Summer School), <quote>S1</quote> (Semester One), <quote>S2</quote> (Semester Two), <quote>FY</quote> (Full Year) or <quote>O</quote> (Other). [<strong>Bonus:</strong> thesis courses must always be Other.]</item> <item>The component type must be one of the following: <quote>Doctoral thesis</quote>, <quote>Masters<apostrophe/> thesis</quote>, <quote>Diploma thesis</quote> or <quote>Paper</quote>.</item> <item>Semester and Summer School papers are worth 20 points, while full year papers are worth 40 points. A Diploma thesis is worth 40 points, a Masters<apostrophe /> thesis 120 points and a PhD thesis 360 points.</item> <item>The <tt>Thesis</tt> and <tt>Paper</tt> subtypes have no additional attributes.</item> </itemised-list> <answer> <p><strong>Component</strong>(<underline>Component_Code</underline>, Title, Description, Points, Period, Component<underscore />Type)</p> <code-block> CREATE TABLE Component ( Component_Code CHAR(7), Title VARCHAR2(50) NOT NULL, Description VARCHAR2(200) NOT NULL, Points NUMBER(2) NOT NULL CHECK ( Points IN ( 20, 40, 120, 360 ) ), Period CHAR(2) NOT NULL CHECK ( Period IN ( 'S1', 'S2', 'SS', 'FY', 'O' ) ), Component_Type VARCHAR2(15) NOT NULL CHECK ( Component_Code IN ( 'Doctoral thesis', 'Masters'' thesis', 'Diploma thesis', 'Paper' ) ) -- PRIMARY KEY (Component_Code) ); </code-block> <p>This solution uses the integrated approach for transforming subtypes (i.e., one relation containing all the super- and subtype attributes). The reason for this is that the two <code>Component</code> subtypes provide no additional attributes. Splitting them off as separate (single-attribute) relations therefore seems somewhat pointless (but see the further discussion below).</p> <p>There is one significant consequence of using the integrated approach. If we collapse all the <code>Component</code> super- and subtypes into a single entity, we may also want to collapse the <strong>supervises</strong> and <strong>teaches</strong> many-to-many relationships into a single relationship (although we aren<apostrophe />t required to do so). If we do nothing else at this point, we have eliminated some important information from the schema: namely the type of relationship between staff and components (a subtle but important distinction). We can re-introduce this information by adding a <code>Type</code> attribute to the <code>Staff_Component</code> relation when we resolve the many-to-many relationship. This has been included in the SQL code for the table.</p> <p>Some people stated that the discrete approach (three relations) was the best choice, then gave either no justification at all or simply repeated the advantages of the approach mentioned in lectures, presumably on the theory that <quote>if it was stated in lectures, it <em>must</em> be true</quote>. (It is worth noting that we quite clearly stated in those lectures that you should always consider the context in which subtypes occur when deciding on the best approach to transform them.) This clearly shows that those people had not thought about what the best solution might be <em>for this case</em>, and were instead applying a <quote>one size fits all</quote> mentality, which can be very dangerous. In this case, the discrete approach is perhaps not an ideal solution, as it adds some data redundancy and complicates queries by requiring extra joins.</p> <p>However, you can successfully argue that the Institute might want to add new subtypes in future, which would be difficult to achieve under the integrated approach. This is a perfectly valid solution, <em>as long as you clearly state this assumption</em>. A couple of people did precisely this, and got full marks for the subtype transformation. In other words, the schema presented here is not the only possible solution to this problem.</p> <p>A common error when using the discrete approach was to define all three relations containing the all the <code>Component</code> attributes. However, this defeats the purpose of having a <code>Component</code> supertype relation, as the supertype is supposed to contain the attributes that are shared across all subtypes. Implementing it this way would be little different from the additive approach (which doesn<apostrophe />t really work in this scenario; see below). With three relations, <code>Component</code> should have all the attributes, while <code>Thesis</code> and <code>Paper</code> have only the primary key column (plus a foreign key to <code>Component</code>) and nothing else. Yes, it looks weird, but it works, and the end user never has to see it (logical data independence).</p> <p>As noted above, the integrated approach merges the two many-to-many relationships into one, which means you need some kind of <quote>type</quote> attribute in the intermediate relation. However, as a few observant people noted, you can achieve the same effect by looking up <code>Component_Type</code> in <code>Component</code> (bonus marks were awarded to those who spotted this, although note that this solution would require application developers to join with <code>Component</code> and filter appropriately).</p> <p>The additive approach is definitely inappropriate for this scenario because it would force us to include two foreign keys to <code>Component</code> in <code>Enrolment</code>. Worse, because each enrolment is for a single component, only one of those foreign keys can have a value for any given enrolment. This means that both foreign key columns must allow nulls, which is a significant variation from what the original ERD specified. Also, with this approach it is possible to have two identical components that are both a paper and a thesis at the same time!</p> <p>On a completely different note, most people who implemented the <code>CHECK</code> constraint for <code>Component.Component_Type</code> got it slightly wrong, by checking for <quote>Masters thesis</quote> instead of <quote>Masters<apostrophe /> thesis</quote> (note the apostrophe after <quote>Masters</quote>, and check the code above to see how this is done in SQL). This may seem rather picky, but once again, you have to follow the specification in detail, otherwise you can end up in a situation where the front end supplies what should be a valid value, which is then unexpectedly rejected by the back end!</p> </answer> </section> <section> <title>The <tt>Staff</tt> entity</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row-rule/> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt><hash/></tt></cell> <cell><code>Staff_ID</code></cell> <cell>Internally generated 5 digit identifier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Surname</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Other_Names</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Contact_Phone</code></cell> <cell>(see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Contact_Address</code></cell> <cell>Up to 200 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Username</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Grade</code></cell> <cell>(see below)</cell> </row> <row> <cell><tt>*</tt></cell> <cell><code>Salary</code></cell> <cell>Monetary, <ge/><dollar-sign/>42<digitsep/>670.00</cell> </row> <row-rule/> </tabular-body> </tabular> <itemised-list> <item>Phone numbers must cater for both local landline and cellular numbers.</item> <item>A staff member<apostrophe/>s grade must be one of the following: <quote>AL</quote> (Assistant Lecturer), <quote>L</quote> (Lecturer), <quote>SL</quote> (Senior Lecturer), <quote>AP</quote> (Associate Professor) or <quote>P</quote> (Professor).</item> </itemised-list> <answer> <p><strong>Staff</strong>(<underline>Staff<underscore />ID</underline>, Surname, Other<underscore />Names, Contact<underscore />Phone, Contact<underscore />Address, Username, Grade, Salary)</p> <code-block> CREATE TABLE Staff ( Staff_ID NUMBER(5), Surname VARCHAR2(50) NOT NULL, Other_Names VARCHAR2(50) NOT NULL, Contact_Phone VARCHAR2(10), -- at least 10, maybe more Contact_Address VARCHAR2(200) NOT NULL, Username VARCHAR2(50) NOT NULL, Grade VARCHAR2(2) NOT NULL CHECK ( Grade IN ( 'AL', 'L', 'SL', 'AP', 'P' ) ), Salary NUMBER(7,2) NOT NULL CHECK ( Salary >= 42670 ), -- PRIMARY KEY (Staff_ID) ); </code-block> <p>We also need to add a relation between <code>Staff</code> and <code>Component</code> to resolve the many-to-many relationship:</p> <p><strong>Staff<underscore />Component</strong>(<underline>Staff<underscore />ID, Component<underscore />Code</underline>, Type)</code>; <code>Staff<underscore />ID</code> FK to <code><strong>Staff</strong></code>, <code>Component<underscore />Code</code> FK to <code><strong>Component</strong></p> <code-block> CREATE TABLE Staff_Component ( Staff_ID NUMBER(5), Component_Code CHAR(7), Type VARCHAR2(10) NOT NULL CHECK ( Type IN ( 'teaches', 'supervises' ) ), -- PRIMARY KEY (Staff_ID, Component_Code), FOREIGN KEY (Staff_ID) REFERENCES Staff, FOREIGN KEY (Component_Code) REFERENCES Component ); </code-block> </answer> </section> </section> </document>

Ignore Space Show notes View

STINK_postgrad.xml 0 → 100755

<?xml version="1.0" standalone="yes"?>

<section label="sec:database-info">
	
		<title>System specification and details</title>
		
		The Southern Technical Institute for Natural Knowledge is a medium-sized tertiary education provider, founded in 1982, which teaches papers across many subjects leading to many different qualifications. They began offering postgraduate degrees in 2008, and are in the process of designing and implementing a database to keep track of their postgraduate students. The requirements analysis and conceptual design phases of the project are complete, and you have been brought in as lead database developer. Your task is to verify the soundness of the conceptual specification by implementing an initial prototype based on it. A design-level entity-relationship diagram of the proposed database is shown in <hyperlink label="fig:erd"><reference label="fig:erd"/></hyperlink>, and more detailed specifications of the database requirements may be found in the following sections.

<figure label="fig:erd" latex-placement="!hb">
			<caption>Design-level ERD of the proposed database</caption>
			<image basename="STINK_postgrad" location="images">
				<description>Design-level ERD of the proposed database</description>
			</image>
		</figure>

<section>
		
			<title>The <tt>Degree</tt> entity</title>

<itemised-list>

<item>The abbreviation is a short string identifying the postgraduate degree, for example, <quote>PhD</quote>, <quote>MSc</quote>, <quote>PGDipCom</quote>.</item>
				
				<item>The degree type must be one of the following: <quote>Taught</quote>, <quote>Papers <ampersand/> thesis</quote> or <quote>Thesis only</quote>.</item>
				
				<item>The funding limit specifies the maximum number of years that the degree will be funded by the government, for example, four years for a PhD. This may not always be a whole number.</item>
				
			</itemised-list>
			
			<answer>
			
				Degree{<underline>Abbreviation</underline>, Full<underscore />Name, Degree<underscore />Type, Funding<underscore />Limit}
				
				<code-block>
CREATE TABLE Degree
( Abbreviation VARCHAR2(10),
 Full_Name VARCHAR2(100) NOT NULL,
 Degree_Type VARCHAR2(15) NOT NULL
 CHECK ( Degree_Type IN ( 'Taught', 'Papers &amp; thesis', 'Thesis only' ) ),
 Funding_Limit NUMBER(3,1) NOT NULL
 CHECK ( Funding_Limit &gt;= 0 )
 --
 PRIMARY KEY (Abbreviation)
);
				</code-block>
				
				Some people added lookup tables for things like degree types. Strictly speaking, this isn<apostrophe />t really part of of the schema transformation (the schema will work fine either with or without lookup tables), but in general there is nothing wrong with doing this, as long as it doesn<apostrophe />t change the specification. Some people did do this correctly, by simply using the existing values (which are already unique) as the primary key of the new lookup table. For example, the <code>Degree_Type</code> table would consist of a single column <code>Degree_Type</code>, which contained the valid values for degree types, and was also the primary key. Other people got carried away and invented unnecessary surrogate keys for their lookup tables, thus completely breaking the specification.

</answer>
			
		</section>

<section>
		
			<title>The <tt>Student</tt> entity</title>

<tabular border="1">
				<tabular-columns>
					<column align="center" left-border="|" right-border="|"/>
					<column align="left" right-border="|"/>
					<column align="left" right-border="|"/>
				</tabular-columns>
				<tabular-body>
					<row-rule/>
					<row>
						<cell header="yes"/>
						<cell header="yes">Column</cell>
						<cell header="yes">Description</cell>
					</row>
					<row-rule/>
					<row>
						<cell><tt><hash/></tt></cell>
						<cell><code>Student_ID</code></cell>
						<cell>Internally generated 7 digit identifier</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Surname</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Other_Names</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Contact_Phone</code></cell>
						<cell>(see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Contact_Address</code></cell>
						<cell>Up to 200 characters</cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Home_Phone</code></cell>
						<cell>(see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Home_Address</code></cell>
						<cell>Up to 200 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Username</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>International</code></cell>
						<cell>Boolean, default false</cell>
					</row>
					<row-rule/>
				</tabular-body>
			</tabular>

<vskip size="large"/>
			
			Many students are international, so phone numbers must cater for this.
			
			<answer>
			
				Student{<underline>Student<underscore />ID</underline>, Surname, Other<underscore />Names, Contact<underscore />Phone, Contact<underscore />Address, Home<underscore />Phone, Home<underscore />Address, Username, International, Degree<underscore />Code); Degree<underscore />Code FK to Degree.

<code-block>
CREATE TABLE Student
( Student_ID NUMBER(7),
 Surname VARCHAR2(50) NOT NULL,
 Other_Names VARCHAR2(50) NOT NULL,
 Contact_Phone VARCHAR2(15), -- at least 15, maybe more
 -- for international numbers
 Contact_Address VARCHAR2(200) NOT NULL,
 Home_Phone VARCHAR2(15),
 Home_Address VARCHAR2(200) NOT NULL,
 Username VARCHAR2(50) NOT NULL,
 International CHAR(1) DEFAULT 'F' NOT NULL
 CHECK ( International IN ( 'T', 'F' ) ),
 Degree_Code VARCHAR2(10) NOT NULL,
 --
 PRIMARY KEY (Student_ID),
 FOREIGN KEY (Degree_Code) REFERENCES Degree (Abbreviation)
);
				</code-block>
				
				Remember that <code>ON DELETE CASCADE</code> is not appropriate in all cases! Many people added an <code>ON DELETE CASCADE</code> to the foreign key from <code>Student</code> to <code>Degree</code>, but if you think about how the organisation would work, this doesn<apostrophe />t make any sense. Why should deleting a degree cause all students enrolled in that degree to also be deleted? This is equivalent to expelling the student (actually, worse, since even expelled students probably wouldn<apostrophe />t have their data deleted). It<apostrophe />s much more likely that the affected students would be reassigned to a different degree (or at the very least to a <quote>dummy</quote> placeholder degree until their status is resolved).

</answer>
				
		</section>

<section>
		
			<title>The <tt>Enrolment</tt> entity</title>

<itemised-list>
			
				<item>The year of enrolment cannot be earlier than the year in which the Institute started offering postgraduate degrees.</item>
				
				<item>For a paper, the grade must be one of the following: <quote>E</quote>, <quote>D</quote>, <quote>C<endash/></quote>, <quote>C</quote>, <quote>C+</quote>, <quote>B<endash/></quote>, <quote>B</quote>, <quote>B+</quote>, <quote>A<endash/></quote>, <quote>A</quote> or <quote>A+</quote>. For a thesis, the grade must be one of the following: <quote>Fail</quote>, <quote>Pass</quote>, <quote>Credit</quote>, <quote>Distinction</quote> or <quote>Incomplete</quote>.</item>
			
			</itemised-list>
			
			<answer>
			
				Enrolment(<underline>Enrolment<underscore />ID</underline>, Description, Year<underscore />Enrolled, Grade, Comments, Component<underscore />Code, Student<underscore />ID); Component<underscore />Code FK to Component, Student<underscore />ID FK to Student
				
				<code-block>
CREATE TABLE Enrolment
( Enrolment_ID NUMBER(10),
 Description VARCHAR2(100) NOT NULL,
 Year_Enrolled NUMBER(4) NOT NULL
 CHECK ( Year_Enrolled &gt;= 2008 ),
 Result VARCHAR2(11) NOT NULL
 CHECK ( Result IN ( 'E', 'D', 'C-', 'C', 'C+',
 'B-', 'B', 'B+', 'A-', 'A', 'A+',
 'Fail', 'Pass', 'Credit',
 'Distinction', 'Incomplete'
 )
 )
 Comments VARCHAR2(4000), -- or CLOB (LONG is deprecated)
 Student_ID NUMBER(7) NOT NULL,
 Component_Code CHAR(7) NOT NULL,
 --
 PRIMARY KEY (Enrolment_ID),
 FOREIGN KEY (Student_ID) REFERENCES Student,
 FOREIGN KEY (Component_Code) REFERENCES Component
);
				</code-block>
				
				<code>ON DELETE CASCADE</code> does make sense for the <code>Student_ID</code> foreign key here (and also for the foreign keys in <code>Staff_Component</code>), because the existence of these data is very tightly linked with the associated data. This is a very good illustration of the point that we need to consider not just structural aspects of a problem when building a database, but also procedural aspects.
			
			</answer>
			
		</section>

<section>
		
			<title>The <tt>Component</tt> entity and its subtypes</title>

<tabular border="1">
				<tabular-columns>
					<column align="center" left-border="|" right-border="|"/>
					<column align="left" right-border="|"/>
					<column align="left" right-border="|"/>
				</tabular-columns>
				<tabular-body>
					<row>
						<cell header="yes" columns="3"><tt>Component</tt></cell>
					</row>
					<row-rule/>
					<row>
						<cell header="yes"/>
						<cell header="yes">Column</cell>
						<cell header="yes">Description</cell>
					</row>
					<row-rule/>
					<row>
						<cell><tt><hash/></tt></cell>
						<cell><code>Component_Code</code></cell>
						<cell>7 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Title</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Description</code></cell>
						<cell>Up to 200 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Points</code></cell>
						<cell>Integer, default 20 (also see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Period</code></cell>
						<cell>(see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Component_Type</code></cell>
						<cell>(see below)</cell>
					</row>
					<row-rule/>
				</tabular-body>
			</tabular>

<itemised-list>
			
				<item>The component code comprises a four-letter subject code (e.g., <quote>INFO</quote>) followed by a three digit course number (e.g., <quote>212</quote>). The course numbers for Diploma, Masters<apostrophe/> and PhD theses are 480, 580 and 980 respectively.</item>
				
				<item>The period of a component must be one of the following: <quote>SS</quote> (Summer School), <quote>S1</quote> (Semester One), <quote>S2</quote> (Semester Two), <quote>FY</quote> (Full Year) or <quote>O</quote> (Other). [Bonus: thesis courses must always be Other.]</item>
				
				<item>The component type must be one of the following: <quote>Doctoral thesis</quote>, <quote>Masters<apostrophe/> thesis</quote>, <quote>Diploma thesis</quote> or <quote>Paper</quote>.</item>
				
				<item>Semester and Summer School papers are worth 20 points, while full year papers are worth 40 points. A Diploma thesis is worth 40 points, a Masters<apostrophe /> thesis 120 points and a PhD thesis 360 points.</item>
				
				<item>The <tt>Thesis</tt> and <tt>Paper</tt> subtypes have no additional attributes.</item>
			
			</itemised-list>
			
			<answer>
			
				Component(<underline>Component_Code</underline>, Title, Description, Points, Period, Component<underscore />Type)
				
				<code-block>
CREATE TABLE Component
( Component_Code CHAR(7),
 Title VARCHAR2(50) NOT NULL,
 Description VARCHAR2(200) NOT NULL,
 Points NUMBER(2) NOT NULL
 CHECK ( Points IN ( 20, 40, 120, 360 ) ),
 Period CHAR(2) NOT NULL
 CHECK ( Period IN ( 'S1', 'S2', 'SS', 'FY', 'O' ) ),
 Component_Type VARCHAR2(15) NOT NULL
 CHECK ( Component_Code IN ( 'Doctoral thesis', 'Masters'' thesis',
 'Diploma thesis', 'Paper' ) )
 --
 PRIMARY KEY (Component_Code)
);
				</code-block>
				
				This solution uses the integrated approach for transforming subtypes (i.e., one relation containing all the super- and subtype attributes). The reason for this is that the two <code>Component</code> subtypes provide no additional attributes. Splitting them off as separate (single-attribute) relations therefore seems somewhat pointless (but see the further discussion below).

There is one significant consequence of using the integrated approach. If we collapse all the <code>Component</code> super- and subtypes into a single entity, we may also want to collapse the supervises and teaches many-to-many relationships into a single relationship (although we aren<apostrophe />t required to do so). If we do nothing else at this point, we have eliminated some important information from the schema: namely the type of relationship between staff and components (a subtle but important distinction). We can re-introduce this information by adding a <code>Type</code> attribute to the <code>Staff_Component</code> relation when we resolve the many-to-many relationship. This has been included in the SQL code for the table.

Some people stated that the discrete approach (three relations) was the best choice, then gave either no justification at all or simply repeated the advantages of the approach mentioned in lectures, presumably on the theory that <quote>if it was stated in lectures, it must be true</quote>. (It is worth noting that we quite clearly stated in those lectures that you should always consider the context in which subtypes occur when deciding on the best approach to transform them.) This clearly shows that those people had not thought about what the best solution might be for this case, and were instead applying a <quote>one size fits all</quote> mentality, which can be very dangerous. In this case, the discrete approach is perhaps not an ideal solution, as it adds some data redundancy and complicates queries by requiring extra joins.
			
				However, you can successfully argue that the Institute might want to add new subtypes in future, which would be difficult to achieve under the integrated approach. This is a perfectly valid solution, as long as you clearly state this assumption. A couple of people did precisely this, and got full marks for the subtype transformation. In other words, the schema presented here is not the only possible solution to this problem.
				
				A common error when using the discrete approach was to define all three relations containing the all the <code>Component</code> attributes. However, this defeats the purpose of having a <code>Component</code> supertype relation, as the supertype is supposed to contain the attributes that are shared across all subtypes. Implementing it this way would be little different from the additive approach (which doesn<apostrophe />t really work in this scenario; see below). With three relations, <code>Component</code> should have all the attributes, while <code>Thesis</code> and <code>Paper</code> have only the primary key column (plus a foreign key to <code>Component</code>) and nothing else. Yes, it looks weird, but it works, and the end user never has to see it (logical data independence).
			
				As noted above, the integrated approach merges the two many-to-many relationships into one, which means you need some kind of <quote>type</quote> attribute in the intermediate relation. However, as a few observant people noted, you can achieve the same effect by looking up <code>Component_Type</code> in <code>Component</code> (bonus marks were awarded to those who spotted this, although note that this solution would require application developers to join with <code>Component</code> and filter appropriately).
				
				The additive approach is definitely inappropriate for this scenario because it would force us to include two foreign keys to <code>Component</code> in <code>Enrolment</code>. Worse, because each enrolment is for a single component, only one of those foreign keys can have a value for any given enrolment. This means that both foreign key columns must allow nulls, which is a significant variation from what the original ERD specified. Also, with this approach it is possible to have two identical components that are both a paper and a thesis at the same time!
				
				On a completely different note, most people who implemented the <code>CHECK</code> constraint for <code>Component.Component_Type</code> got it slightly wrong, by checking for <quote>Masters thesis</quote> instead of <quote>Masters<apostrophe /> thesis</quote> (note the apostrophe after <quote>Masters</quote>, and check the code above to see how this is done in SQL). This may seem rather picky, but once again, you have to follow the specification in detail, otherwise you can end up in a situation where the front end supplies what should be a valid value, which is then unexpectedly rejected by the back end!

</answer>

</section>
		
		
		<section>
		
			<title>The <tt>Staff</tt> entity</title>

<tabular border="1">
				<tabular-columns>
					<column align="center" left-border="|" right-border="|"/>
					<column align="left" right-border="|"/>
					<column align="left" right-border="|"/>
				</tabular-columns>
				<tabular-body>
					<row-rule/>
					<row>
						<cell header="yes"/>
						<cell header="yes">Column</cell>
						<cell header="yes">Description</cell>
					</row>
					<row-rule/>
					<row>
						<cell><tt><hash/></tt></cell>
						<cell><code>Staff_ID</code></cell>
						<cell>Internally generated 5 digit identifier</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Surname</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Other_Names</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Contact_Phone</code></cell>
						<cell>(see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Contact_Address</code></cell>
						<cell>Up to 200 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Username</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Grade</code></cell>
						<cell>(see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Salary</code></cell>
						<cell>Monetary, <ge/><dollar-sign/>42<digitsep/>670.00</cell>
					</row>
					<row-rule/>
				</tabular-body>
			</tabular>

<itemised-list>
			
				<item>Phone numbers must cater for both local landline and cellular numbers.</item>
				
				<item>A staff member<apostrophe/>s grade must be one of the following: <quote>AL</quote> (Assistant Lecturer), <quote>L</quote> (Lecturer), <quote>SL</quote> (Senior Lecturer), <quote>AP</quote> (Associate Professor) or <quote>P</quote> (Professor).</item>
				
			</itemised-list>
			
			<answer>
			
				Staff(<underline>Staff<underscore />ID</underline>, Surname, Other<underscore />Names, Contact<underscore />Phone, Contact<underscore />Address, Username, Grade, Salary)
				
				<code-block>
CREATE TABLE Staff
( Staff_ID NUMBER(5),
 Surname VARCHAR2(50) NOT NULL,
 Other_Names VARCHAR2(50) NOT NULL,
 Contact_Phone VARCHAR2(10), -- at least 10, maybe more
 Contact_Address VARCHAR2(200) NOT NULL,
 Username VARCHAR2(50) NOT NULL,
 Grade VARCHAR2(2) NOT NULL
 CHECK ( Grade IN ( 'AL', 'L', 'SL', 'AP', 'P' ) ),
 Salary NUMBER(7,2) NOT NULL
 CHECK ( Salary >= 42670 ),
 --
 PRIMARY KEY (Staff_ID)
);
				</code-block>
				
				We also need to add a relation between <code>Staff</code> and <code>Component</code> to resolve the many-to-many relationship:
				
				Staff<underscore />Component(<underline>Staff<underscore />ID, Component<underscore />Code</underline>, Type)</code>; <code>Staff<underscore />ID</code> FK to <code>Staff</code>, <code>Component<underscore />Code</code> FK to <code>Component
				
				<code-block>
CREATE TABLE Staff_Component
( Staff_ID NUMBER(5),
 Component_Code CHAR(7),
 Type VARCHAR2(10) NOT NULL
 CHECK ( Type IN ( 'teaches', 'supervises' ) ),
 --
 PRIMARY KEY (Staff_ID, Component_Code),
 FOREIGN KEY (Staff_ID) REFERENCES Staff,
 FOREIGN KEY (Component_Code) REFERENCES Component
);
				</code-block>
			
			</answer>
				
		</section>

</section>

</document>

Ignore Space Show notes View STINK_student_records.xml 0 → 100755
<?xml version="1.0" standalone="yes"?> <document class="fragment"> <section label="sec:database-info"> <title>System specification and details</title> <p>The Southern Technical Institute for Natural Knowledge is a medium-sized tertiary education provider (founded in 1982) that teaches papers across many subjects, which lead to several different qualifications. They are currently in the process of designing and implementing a new student records database. The requirements analysis and conceptual design phases of the project are complete, and you have been brought in as lead database developer. It will be your task to implement an initial prototype of the conceptual specification. A design-level entity-relationship diagram of the proposed database is shown in <hyperlink label="fig:erd"><reference label="fig:erd" /></hyperlink>, and more detailed specifications of the database requirements may be found in the following sections. <strong>Reminder:</strong> In the tables that follow, <quote><tt><hash /></tt></quote> indicates the unique identifier, <quote><tt></tt></quote> indicates that a value is required, and <quote><tt>o</tt></quote> indicates that a value is not required.</p> <figure label="fig:erd" latex-placement="!hb"> <caption>Design-level ERD of the proposed database</caption> <image basename="STINK_student_records" location="images"> <description>Design-level ERD of the proposed database</description> </image> </figure> <section> <title>The <tt>Qualification</tt> entity</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|" /> <column align="left" right-border="\|" /> <column align="left" right-border="\|" /> </tabular-columns> <tabular-body> <row-rule /> <row> <cell header="yes" /> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule /> <row> <cell><tt><hash /></tt></cell> <cell><code>Abbreviation</code></cell> <cell>Up to 10 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Full_Name</code></cell> <cell>Up to 100 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Type</code></cell> <cell>(see below)</cell> </row> <row-rule /> </tabular-body> </tabular> <itemised-list> <item>The abbreviation is a short string that identifies the qualification, e.g., <quote>BCom</quote>, <quote>PGDipCApSc</quote> (these are not the only possible values).</item> <item>The qualification type must be one of the following: <quote>Degree</quote>, <quote>Diploma</quote> or <quote>Certificate</quote>.</item> </itemised-list> <answer> <p indent="no"><strong>Qualification</strong><left-brace /><underline>Abbreviation</underline>, Full<underscore />Name, Type<right-brace /></p> <code-block> CREATE TABLE Qualification ( Abbreviation VARCHAR2(10), Full_Name VARCHAR2(100) NOT NULL, Type VARCHAR2(11) NOT NULL CONSTRAINT Qualification_Type_Valid CHECK (Type IN ('Degree', 'Diploma', 'Certificate')), -- CONSTRAINT Qualification_PK PRIMARY KEY (Abbreviation) ); </code-block> <p indent="no">If we wanted to allow for additional qualification types in future, we could create a separate <code>Qualification_Type</code> lookup table, with a single column <code>Type</code>. We could then replace the <code>CHECK</code> constraint <code>Qualification_Type_Valid</code> with a foreign key to the lookup table. </p> </answer> </section> <section> <title>The <tt>Paper</tt> entity</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|" /> <column align="left" right-border="\|" /> <column align="left" right-border="\|" /> </tabular-columns> <tabular-body> <row-rule /> <row> <cell header="yes" /> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule /> <row> <cell><tt><hash /></tt></cell> <cell><code>Paper_Code</code></cell> <cell>7 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Title</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Description</code></cell> <cell>Up to 500 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Points</code></cell> <cell>Integer 0<endash />36, default 18</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Period</code></cell> <cell>(see below)</cell> </row> <row-rule /> </tabular-body> </tabular> <vskip size="large" /> <p indent="no">The period of a paper must be one of the following: <quote>SS</quote> (Summer School), <quote>S1</quote> (Semester One), <quote>S2</quote> (Semester Two) or <quote>FY</quote> (Full Year).</p> <answer> <p indent="no"><strong>Paper</strong><left-brace /><underline>Paper<underscore />Code</underline>, Title, Description, Points, Period<right-brace /></p> <code-block> CREATE TABLE Paper ( Paper_Code CHAR(7), Title VARCHAR2(50) NOT NULL, Description VARCHAR2(500) NOT NULL, Points NUMBER(2) DEFAULT 18 NOT NULL CONSTRAINT Paper_Points_Range CHECK (Points BETWEEN 0 AND 36), Period CHAR(2) NOT NULL CONSTRAINT Paper_Period_Valid CHECK (Period IN ('S1', 'S2', 'SS', 'FY')), -- CONSTRAINT Paper_PK PRIMARY KEY (Paper_Code) ); </code-block> <p indent="no">We also need to add an associative entity between <strong>Paper</strong> and <strong>Qualification</strong> in order to resolve the many-to-many relationship:</p> <vskip size="small" /> <p indent="no"><strong>Schedule</strong><left-brace/><underline>Abbreviation, Paper<underscore/>Code</underline><right-brace/>; Abbreviation FK to <strong>Qualification</strong>, Paper<underscore/>Code FK to <strong>Paper</strong></p> <code-block> CREATE TABLE Schedule ( Abbreviation VARCHAR2(10), Paper_Code CHAR(7), -- CONSTRAINT Schedule_PK PRIMARY KEY (Abbreviation, Paper_Code), CONSTRAINT Schedule_FK_to_Qualification FOREIGN KEY (Abbreviation) REFERENCES Qualification, CONSTRAINT Schedule_FK_to_Paper FOREIGN KEY (Paper_Code) REFERENCES Paper ); </code-block> </answer> </section> <section> <title>The <tt>Person</tt> entity and its subtypes</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|" /> <column align="left" right-border="\|" /> <column align="left" right-border="\|" /> </tabular-columns> <tabular-body> <row> <cell header="yes" columns="3"><tt>Person</tt></cell> </row> <row-rule /> <row> <cell header="yes" /> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule /> <row> <cell><tt><hash /></tt></cell> <cell><code>Person_ID</code></cell> <cell>Internally generated 7 digit identifier (see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Surname</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Other_Names</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Contact_Phone</code></cell> <cell>(see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Contact_Address</code></cell> <cell>Up to 200 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Username</code></cell> <cell>Up to 10 characters</cell> </row> <row-rule /> <row> <cell columns="3" /> </row> <row> <cell header="yes" columns="3"><tt>Staff</tt></cell> </row> <row-rule /> <row> <cell header="yes" /> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule /> <row> <cell><tt></tt></cell> <cell><code>Email</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Rank</code></cell> <cell>(see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Salary</code></cell> <cell>Monetary, <ge /><dollar-sign />35<digitsep />450.00</cell> </row> <row-rule /> <row> <cell columns="3" /> </row> <row> <cell header="yes" columns="3"><tt>Student</tt></cell> </row> <row-rule /> <row> <cell header="yes" /> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule /> <row> <cell><tt></tt></cell> <cell><code>Email</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Home_Phone</code></cell> <cell>(see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Home_Address</code></cell> <cell>Up to 200 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>International</code></cell> <cell>True/false, default false</cell> </row> <row-rule /> </tabular-body> </tabular> <itemised-list> <item>You are not required to automatically generate the value of the <code>Person_ID</code> attribute, but bonus marks will be awarded if you are able to do so. (This also applies to the <code>Enrolment_ID</code> and <code>Assessment_ID</code> attributes below.)</item> <item>Phone numbers must cater for full international numbers, as many students are from overseas.</item> <item>A staff member<apostrophe />s rank must be one of the following: <quote>AL</quote> (Assistant Lecturer), <quote>L</quote> (Lecturer), <quote>SL</quote> (Senior Lecturer), <quote>AP</quote> (Associate Professor) or <quote>P</quote> (Professor).</item> </itemised-list> <answer> <p indent="no"><strong>Person</strong><left-brace /><underline>Person<underscore />ID</underline>, Surname, Other<underscore />Names, Contact<underscore />Phone, Contact<underscore />Address, Username<right-brace /></p> <vskip size="small" /> <p indent="no"><strong>Staff</strong><left-brace /><underline>Staff<underscore />ID</underline>, Email, Rank, Salary<right-brace />; Staff<underscore />ID FK to <strong>Person</strong></p> <vskip size="small" /> <p indent="no"><strong>Staff</strong><left-brace /><underline>Student<underscore />ID</underline>, Email, Home<underscore />Phone, Home<underscore />Address, International, Supervisor<underscore />ID<right-brace />; Student<underscore />ID FK to <strong>Person</strong>, Supervisor<underscore />ID FK to <strong>Staff</strong></p> <code-block> CREATE TABLE Person ( Person_ID NUMBER(7), Surname VARCHAR2(50) NOT NULL, Other_Names VARCHAR2(50) NOT NULL, Contact_Phone VARCHAR2(12), -- at least 12, maybe more Contact_Address VARCHAR2(200) NOT NULL, Username VARCHAR2(50) NOT NULL CONSTRAINT Person_Username_Unique UNIQUE, -- bonus marks! -- CONSTRAINT Person_PK PRIMARY KEY (Person_ID) ); CREATE TABLE Staff ( Staff_ID NUMBER(7), Email VARCHAR2(50) NOT NULL, Rank VARCHAR2(2) NOT NULL CONSTRAINT Staff Rank_Valid CHECK (Rank IN ('AL', 'L', 'SL', 'AP', 'P')), Salary NUMBER(7,2) NOT NULL CONSTRAINT Staff_Salary_Range CHECK (Salary >= 35450), -- CONSTRAINT Staff_PK PRIMARY KEY (Staff_ID), CONSTRAINT Staff_FK_to_Person FOREIGN KEY (Staff_ID) REFERENCES Person (Person_ID) ); CREATE TABLE Student ( Student_ID NUMBER(7), Email VARCHAR2(50) NOT NULL, Home_Phone VARCHAR2(12), Home_Address VARCHAR2(200) NOT NULL, International CHAR(1) DEFAULT 'F' NOT NULL CONSTRAINT Student_International_Valid CHECK (International IN ('T', 'F')), Supervisor_ID NUMBER(7), -- optional -- CONSTRAINT Student_PK PRIMARY KEY (Student_ID), CONSTRAINT Student_FK_to_Person FOREIGN KEY (Student_ID) REFERENCES Person (Person_ID), CONSTRAINT Student_FK_to_Staff FOREIGN KEY (Supervisor_ID) REFERENCES Staff (Staff_ID) ); </code-block> <p indent="no">This solution uses the discrete approach for transforming subtypes. The additive approach is also feasible (i.e., place the <strong>Person</strong> attributes into both <strong>Staff</strong> and <strong>Student</strong>, and eliminate <strong>Person</strong> entirely). We accepted either approach, but note that the discrete approach has one distinct advantage over the additive approach in this scenario. Consider what happens when someone is both a staff member and a student: we end up duplicating all the <quote>person</quote> data across both tables. This doesn<apostrophe />t occur with the discrete approach. People who didn<apostrophe />t discuss this aspect lost marks.</p> <p>For those who implemented the additive approach, we marked the <quote>person</quote> attributes in <strong>Staff</strong> and <strong>Student</strong> as if they were a separate <strong>Person</strong> entity.</p> <p>The integrated approach was definitely <em>not</em> suitable due to the supervision relationship between <strong>Staff</strong> and <strong>Student</strong> (which, incidentally, many people missed completely), and the mandatory attributes that exist in both <strong>Staff</strong> and <strong>Student</strong>.</p> <p>We also need to add an associative entity between <strong>Paper</strong> and <strong>Staff</strong> in order to resolve the many-to-many relationship:</p> <vskip size="small" /> <p indent="no"><strong>Teach</strong><left-brace /><underline>Staff<underscore />ID, Paper<underscore />Code</underline><right-brace />; Staff<underscore />ID FK to <strong>Staff</strong>, Paper<underscore />Code FK to <strong>Paper</strong></p> <code-block> CREATE TABLE Teach ( Staff_ID NUMBER(7), Paper_Code CHAR(7), -- CONSTRAINT Teach_PK PRIMARY KEY (Staff_ID, Paper_Code), CONSTRAINT Teach_FK_to_Staff FOREIGN KEY (Staff_ID) REFERENCES Staff, CONSTRAINT Teach_FK_to_Paper FOREIGN KEY (Paper_Code) REFERENCES Paper ); </code-block> <p>It<apostrophe />s important when implementing <quote>boolean</quote> style columns such as <code>International</code> in <code>Student</code> and <code>Visible</code> in <code>Assessment</code> that you are consistent in the values that you use across all such columns (more precisely, all such columns should have the same domain). Quite a few people did something like implement one column as <code>'T', 'F'</code> and the other as <code>'True', 'False'</code>, or even more subtle, <code>'t', 'f'</code> (remembering that SQL is case sensitive). Using inconsistent domains for columns that should have the same domain could lead to subtle bugs later on.</p> <p>This of course is really a consequence of not having a proper <code>BOOLEAN</code> data type in SQL. However, one person did discover<emdash />possibly inadvertently, given that it isn<apostrophe />t mentioned anywhere in the documentation<emdash />that <OracleServer /> now supports the use of the <code>BOOLEAN</code> data type in <code>CREATE TABLE</code>! This certainly wasn<apostrophe />t possible in older versions, where <code>BOOLEAN</code> was available in PL/SQL only.</p> </answer> </section> <newpage /> <section> <title>The <tt>Enrolment</tt> entity</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|" /> <column align="left" right-border="\|" /> <column align="left" right-border="\|" /> </tabular-columns> <tabular-body> <row-rule /> <row> <cell header="yes" /> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule /> <row> <cell><tt><hash /></tt></cell> <cell><code>Enrolment_ID</code></cell> <cell>Internally generated 10 digit identifier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Description</code></cell> <cell>Up to 100 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Year_Enrolled</code></cell> <cell>4 digits</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Comments</code></cell> <cell>Arbitrary text</cell> </row> <row-rule /> </tabular-body> </tabular> <vskip size="large" /> <p indent="no">The year of enrolment cannot be earlier than the year in which the Institute was founded. (Technically it should also not be in the future, but we cannot check this in <OracleServer />.)</p> <answer> <p indent="no"><strong>Enrolment</strong>(<underline>Enrolment<underscore />ID</underline>, Description, Year<underscore />Enrolled, Comments, Paper<underscore />Code, Student<underscore />ID); Paper<underscore />Code FK to <strong>Paper</strong>, Student<underscore />ID FK to <strong>Student</strong></p> <code-block> CREATE TABLE Enrolment ( Enrolment_ID NUMBER(10), Description VARCHAR2(100) NOT NULL, Year_Enrolled NUMBER(4) NOT NULL CONSTRAINT Enrolment_Year_Enrolled_Range CHECK (Year_Enrolled >= 1982), Comments VARCHAR2(4000), -- or CLOB Student_ID NUMBER(7) NOT NULL, Paper_Code CHAR(7) NOT NULL, -- CONSTRAINT Enrolment_PK PRIMARY KEY (Enrolment_ID), CONSTRAINT Enrolment_FK_to_Student FOREIGN KEY (Student_ID) REFERENCES Student, CONSTRAINT Enrolment_FK_to_Paper FOREIGN KEY (Paper_Code) REFERENCES Paper ); </code-block> <p indent="no">A surprising number of people appear to have missed the statement of when the Institute was founded in the first paragraph of the specification!</p> <p>Another very common error was to set the size of the <code>Comments</code> column to a relatively small number, like 200. Think about how much you can say in that many characters (one and a bit text messages), then consider what kinds of things you might want to enter into a general comments column. We deducted marks for anything smaller than 500 characters. When you have no idea of how much you<apostrophe />re going to get, it<apostrophe />s much better to go large than to go small!</p> </answer> </section> <section> <title>The <tt>Assessment</tt> entity</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|" /> <column align="left" right-border="\|" /> <column align="left" right-border="\|" /> </tabular-columns> <tabular-body> <row-rule /> <row> <cell header="yes" /> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule /> <row> <cell><tt><hash /></tt></cell> <cell><code>Assessment_ID</code></cell> <cell>Internally generated 10 digit identifier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Assessment_Year</code></cell> <cell>4 digits</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Name</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Description</code></cell> <cell>Up to 500 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Type</code></cell> <cell>(see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Visible</code></cell> <cell>True/false, default false</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Weight</code></cell> <cell>0<endash />100, no decimal places</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Maximum_Mark</code></cell> <cell>(see below)</cell> </row> <row-rule /> </tabular-body> </tabular> <itemised-list> <item>A new set of assessments is created for each year that a paper is offered. The year cannot be earlier than the year in which the Institute was founded. (Technically it should also not be in the future, but we cannot check this in <OracleServer />.)</item> <item>The assessment type must be one of the following: <quote>A</quote> (assignment), <quote>T</quote> (test) or <quote>X</quote> (exam).</item> <item>The <code>Maximum_Mark</code> attribute stores the maximum possible raw mark for the assessment (e.g., 30), while the <code>Weight</code> attribute stores the percentage weight of this assessment for the paper as a whole (e.g., 10<percent-sign />). If <code>Maximum_Mark</code> is not specified, then applications should use <code>Weight</code> for both.</item> <item>The <code>Visible</code> attribute controls whether or not the marks for this assessment are publicly accessible.</item> </itemised-list> <answer> <p indent="no"><strong>Assessment</strong>(<underline>Assessment<underscore />ID</underline>, Assessment<underscore />Year, Name, Description, Type, Visible, Weight, Maximum<underscore />Mark, Paper<underscore />Code); Paper<underscore />Code FK to <strong>Paper</strong></p> <code-block> CREATE TABLE Assessment ( Assessment_ID NUMBER(10), Assessment_Year NUMBER(4) NOT NULL CONSTRAINT Assessment_Year_Range CHECK (Assessment_Year >= 1982), Name VARCHAR2(50) NOT NULL, Description VARCHAR2(500), Type CHAR(1) NOT NULL CONSTRAINT Assessment_Type_Valid CHECK (Type IN ('A', 'T', 'X')), Visible CHAR(1) DEFAULT 'F' NOT NULL CONSTRAINT Assessment_Visible_Valid CHECK (Visible IN ('T', 'F')), Weight NUMBER(3) NOT NULL CONSTRAINT Assessment_Weight_Range CHECK (Weight BETWEEN 0 AND 100), Maximum_Mark NUMBER(3), Paper_Code CHAR(7) NOT NULL, -- CONSTRAINT Assessment_PK PRIMARY KEY (Assessment_ID), CONSTRAINT Assessment_FK_to_Paper FOREIGN KEY (Paper_Code) REFERENCES Paper ); </code-block> </answer> </section> <newpage /> <section> <title>The <tt>Result</tt> entity</title> <tabular border="1"> <tabular-columns> <column align="center" left-border="\|" right-border="\|" /> <column align="left" right-border="\|" /> <column align="left" right-border="\|" /> </tabular-columns> <tabular-body> <row-rule /> <row> <cell header="yes" /> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule /> <row> <cell><tt><hash /></tt></cell> <cell><code>Assessment_ID</code></cell> <cell>10 digit identifier</cell> </row> <row> <cell><tt><hash /></tt></cell> <cell><code>Enrolment_ID</code></cell> <cell>10 digit identifier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Raw_Mark</code></cell> <cell>3 digits plus 1 decimal place (i.e., 000.0)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Weighted_Mark</code></cell> <cell>Floating point</cell> </row> <row> <cell><tt>*</tt></cell> <cell><code>Percentage_Mark</code></cell> <cell>0<endash />100, 2 decimal places</cell> </row> <row-rule /> </tabular-body> </tabular> <itemised-list> <item>The <code>Raw_Mark</code> attribute stores the raw mark awarded for an assessment. Its value should be between zero and the value of <code>Assessment.Maximum_Mark</code> (note that only the former is required for this assignment<emdash />bonus marks if you can also achieve the latter).</item> <item>The value of the <code>Weighted_Mark</code> attribute is calculated by the formula: <line-break /> <code>Raw_Mark</code> / <code>Assessment.Maximum_Mark</code><space /> <times /><space /> <code>Assessment.Weight</code>.</item> <item>The value of the <code>Percentage_Mark</code> attribute is calculated by the formula: <line-break /> <code>Raw_Mark</code> / <code>Assessment.Maximum_Mark</code><space /> <times /> 100.</item> <item>Note that the two calculations above are <emph>not</emph> constraints and should not be implemented as such. You may attempt to implement these calculations if you feel confident in your ability to do so, but please ensure that you complete the rest of the assignment <em>first</em>.</item> </itemised-list> <answer> <p indent="no"><strong>Result</strong>(<underline>Assessment<underscore />ID, Enrolment<underscore />ID</underline>, Raw<underscore />Mark, Weighted<underscore />Mark, Percentage<underscore />Mark); Assessment<underscore />ID FK to <strong>Assessment</strong>, Enrolment<underscore />ID FK to <strong>Enrolment</strong></p> <code-block> CREATE TABLE Result ( Assessment_ID NUMBER(10), Enrolment_ID NUMBER(10), Raw_Mark NUMBER(4,1) NOT NULL, Weighted_Mark NUMBER NOT NULL, Percentage_Mark NUMBER(5,2) NOT NULL CONSTRAINT Result_Percentage_Mark_Range CHECK (Percentage_Mark BETWEEN 0 AND 100), -- CONSTRAINT Result_PK PRIMARY KEY (Assessment_ID, Enrolment_ID), CONSTRAINT Result_FK_to_Assessment FOREIGN KEY (Assessment_ID) REFERENCES Assessment, CONSTRAINT Result_FK_to_Enrolment FOREIGN KEY (Enrolment_ID) REFERENCES Enrolment ); </code-block> <p indent="no">A lot of people got the sizes of the various <code>NUMBER</code> columns incorrect. Remember that the number of decimal places is <em>included</em> in the total number of digits, not <em>in addition to</em>.</p> <p>We also accepted <code>FLOAT</code> and <code>BINARY_FLOAT</code> for <code>Weighted_Mark</code>. Anything with a fixed number of decimal places was marked down, as this is a <em>fixed</em> point number, not a floating point number.</p> </answer> </section> </section> </document>

Ignore Space Show notes View

STINK_student_records.xml 0 → 100755

<?xml version="1.0" standalone="yes"?>

<title>System specification and details</title>

The Southern Technical Institute for Natural Knowledge is a medium-sized tertiary education provider (founded in 1982) that teaches papers across many subjects, which lead to several different qualifications. They are currently in the process of designing and implementing a new student records database. The requirements analysis and conceptual design phases of the project are complete, and you have been brought in as lead database developer. It will be your task to implement an initial prototype of the conceptual specification. A design-level entity-relationship diagram of the proposed database is shown in <hyperlink label="fig:erd"><reference label="fig:erd" /></hyperlink>, and more detailed specifications of the database requirements may be found in the following sections. Reminder: In the tables that follow, <quote><tt><hash /></tt></quote> indicates the unique identifier, <quote><tt>*</tt></quote> indicates that a value is required, and <quote><tt>o</tt></quote> indicates that a value is not required.

<figure label="fig:erd" latex-placement="!hb">
			<caption>Design-level ERD of the proposed database</caption>
			<image basename="STINK_student_records" location="images">
				<description>Design-level ERD of the proposed database</description>
			</image>
		</figure>

<section>
		
			<title>The <tt>Qualification</tt> entity</title>

<itemised-list>

<item>The abbreviation is a short string that identifies the qualification, e.g., <quote>BCom</quote>, <quote>PGDipCApSc</quote> (these are not the only possible values).</item>
			
				<item>The qualification type must be one of the following: <quote>Degree</quote>, <quote>Diploma</quote> or <quote>Certificate</quote>.</item>
				
			</itemised-list>
			
			<answer>
			
				Qualification<left-brace /><underline>Abbreviation</underline>, Full<underscore />Name, Type<right-brace />
				
				<code-block>
CREATE TABLE Qualification
( Abbreviation VARCHAR2(10),
 Full_Name VARCHAR2(100) NOT NULL,
 Type VARCHAR2(11) NOT NULL
 CONSTRAINT Qualification_Type_Valid 
 CHECK (Type IN ('Degree', 'Diploma', 'Certificate')),
 --
 CONSTRAINT Qualification_PK PRIMARY KEY (Abbreviation)
);
				</code-block>
				
				If we wanted to allow for additional qualification types in future, we could create a separate <code>Qualification_Type</code> lookup table, with a single column <code>Type</code>. We could then replace the <code>CHECK</code> constraint <code>Qualification_Type_Valid</code> with a foreign key to the lookup table. 
			
			</answer>
			
		</section>

<section>
		
			<title>The <tt>Paper</tt> entity</title>

<vskip size="large" />
			
			The period of a paper must be one of the following: <quote>SS</quote> (Summer School), <quote>S1</quote> (Semester One), <quote>S2</quote> (Semester Two) or <quote>FY</quote> (Full Year).
				
			<answer>
			
				Paper<left-brace /><underline>Paper<underscore />Code</underline>, Title, Description, Points, Period<right-brace />
				
				<code-block>
CREATE TABLE Paper
( Paper_Code CHAR(7),
 Title VARCHAR2(50) NOT NULL,
 Description VARCHAR2(500) NOT NULL,
 Points NUMBER(2) DEFAULT 18 NOT NULL
 CONSTRAINT Paper_Points_Range CHECK (Points BETWEEN 0 AND 36),
 Period CHAR(2) NOT NULL
 CONSTRAINT Paper_Period_Valid
 CHECK (Period IN ('S1', 'S2', 'SS', 'FY')),
 --
 CONSTRAINT Paper_PK PRIMARY KEY (Paper_Code)
);
				</code-block>
			
				We also need to add an associative entity between Paper and Qualification in order to resolve the many-to-many relationship:
				
				<vskip size="small" />
				
				Schedule<left-brace/><underline>Abbreviation, Paper<underscore/>Code</underline><right-brace/>; Abbreviation FK to Qualification, Paper<underscore/>Code FK to Paper
				
				<code-block>
CREATE TABLE Schedule
( Abbreviation VARCHAR2(10),
 Paper_Code CHAR(7),
 --
 CONSTRAINT Schedule_PK PRIMARY KEY (Abbreviation, Paper_Code),
 CONSTRAINT Schedule_FK_to_Qualification
 FOREIGN KEY (Abbreviation) REFERENCES Qualification,
 CONSTRAINT Schedule_FK_to_Paper FOREIGN KEY (Paper_Code) REFERENCES Paper
);
				</code-block>

</answer>
			
		</section>

<section>
		
			<title>The <tt>Person</tt> entity and its subtypes</title>

<tabular border="1">
				<tabular-columns>
					<column align="center" left-border="|" right-border="|" />
					<column align="left" right-border="|" />
					<column align="left" right-border="|" />
				</tabular-columns>
				<tabular-body>
					<row>
						<cell header="yes" columns="3"><tt>Person</tt></cell>
					</row>
					<row-rule />
					<row>
						<cell header="yes" />
						<cell header="yes">Column</cell>
						<cell header="yes">Description</cell>
					</row>
					<row-rule />
					<row>
						<cell><tt><hash /></tt></cell>
						<cell><code>Person_ID</code></cell>
						<cell>Internally generated 7 digit identifier (see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Surname</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Other_Names</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Contact_Phone</code></cell>
						<cell>(see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Contact_Address</code></cell>
						<cell>Up to 200 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Username</code></cell>
						<cell>Up to 10 characters</cell>
					</row>
					<row-rule />
					<row>
						<cell columns="3" />
					</row>

<row>
						<cell header="yes" columns="3"><tt>Staff</tt></cell>
					</row>
					<row-rule />
					<row>
						<cell header="yes" />
						<cell header="yes">Column</cell>
						<cell header="yes">Description</cell>
					</row>
					<row-rule />
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Email</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Rank</code></cell>
						<cell>(see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Salary</code></cell>
						<cell>Monetary, <ge /><dollar-sign />35<digitsep />450.00</cell>
					</row>
					<row-rule />
					<row>
						<cell columns="3" />
					</row>

<row>
						<cell header="yes" columns="3"><tt>Student</tt></cell>
					</row>
					<row-rule />
					<row>
						<cell header="yes" />
						<cell header="yes">Column</cell>
						<cell header="yes">Description</cell>
					</row>
					<row-rule />
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Email</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Home_Phone</code></cell>
						<cell>(see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Home_Address</code></cell>
						<cell>Up to 200 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>International</code></cell>
						<cell>True/false, default false</cell>
					</row>
					<row-rule />
				</tabular-body>
			</tabular>

<itemised-list>
			
				<item>You are not required to automatically generate the value of the <code>Person_ID</code> attribute, but bonus marks will be awarded if you are able to do so. (This also applies to the <code>Enrolment_ID</code> and <code>Assessment_ID</code> attributes below.)</item>
			
				<item>Phone numbers must cater for full international numbers, as many students are from overseas.</item>
				
				<item>A staff member<apostrophe />s rank must be one of the following: <quote>AL</quote> (Assistant Lecturer), <quote>L</quote> (Lecturer), <quote>SL</quote> (Senior Lecturer), <quote>AP</quote> (Associate Professor) or <quote>P</quote> (Professor).</item>
				
			</itemised-list>

<answer>
			
				Person<left-brace /><underline>Person<underscore />ID</underline>, Surname, Other<underscore />Names, Contact<underscore />Phone, Contact<underscore />Address, Username<right-brace />
				
				<vskip size="small" />
			
				Staff<left-brace /><underline>Staff<underscore />ID</underline>, Email, Rank, Salary<right-brace />; Staff<underscore />ID FK to Person
			
				<vskip size="small" />
			
				Staff<left-brace /><underline>Student<underscore />ID</underline>, Email, Home<underscore />Phone, Home<underscore />Address, International, Supervisor<underscore />ID<right-brace />; Student<underscore />ID FK to Person, Supervisor<underscore />ID FK to Staff
				
				<code-block>
CREATE TABLE Person
( Person_ID NUMBER(7),
 Surname VARCHAR2(50) NOT NULL,
 Other_Names VARCHAR2(50) NOT NULL,
 Contact_Phone VARCHAR2(12), -- at least 12, maybe more 
 Contact_Address VARCHAR2(200) NOT NULL,
 Username VARCHAR2(50) NOT NULL
 CONSTRAINT Person_Username_Unique UNIQUE, -- bonus marks!
 --
 CONSTRAINT Person_PK PRIMARY KEY (Person_ID)
);

CREATE TABLE Staff
( Staff_ID          NUMBER(7),
  Email             VARCHAR2(50)    NOT NULL,
  Rank              VARCHAR2(2)     NOT NULL
    CONSTRAINT Staff Rank_Valid
      CHECK (Rank IN ('AL', 'L', 'SL', 'AP', 'P')),
  Salary            NUMBER(7,2)     NOT NULL
    CONSTRAINT Staff_Salary_Range CHECK (Salary >= 35450),
  --
  CONSTRAINT Staff_PK PRIMARY KEY (Staff_ID),
  CONSTRAINT Staff_FK_to_Person
    FOREIGN KEY (Staff_ID) REFERENCES Person (Person_ID)
);

CREATE TABLE Student
( Student_ID NUMBER(7),
 Email VARCHAR2(50) NOT NULL,
 Home_Phone VARCHAR2(12),
 Home_Address VARCHAR2(200) NOT NULL,
 International CHAR(1) DEFAULT 'F' NOT NULL
 CONSTRAINT Student_International_Valid
 CHECK (International IN ('T', 'F')),
 Supervisor_ID NUMBER(7), -- optional
 --
 CONSTRAINT Student_PK PRIMARY KEY (Student_ID),
 CONSTRAINT Student_FK_to_Person
 FOREIGN KEY (Student_ID) REFERENCES Person (Person_ID),
 CONSTRAINT Student_FK_to_Staff
 FOREIGN KEY (Supervisor_ID) REFERENCES Staff (Staff_ID)
);
				</code-block>
			
				This solution uses the discrete approach for transforming subtypes. The additive approach is also feasible (i.e., place the Person attributes into both Staff and Student, and eliminate Person entirely). We accepted either approach, but note that the discrete approach has one distinct advantage over the additive approach in this scenario. Consider what happens when someone is both a staff member and a student: we end up duplicating all the <quote>person</quote> data across both tables. This doesn<apostrophe />t occur with the discrete approach. People who didn<apostrophe />t discuss this aspect lost marks.
				
				For those who implemented the additive approach, we marked the <quote>person</quote> attributes in Staff and Student as if they were a separate Person entity.
				
				The integrated approach was definitely not suitable due to the supervision relationship between Staff and Student (which, incidentally, many people missed completely), and the mandatory attributes that exist in both Staff and Student.
				
				We also need to add an associative entity between Paper and Staff in order to resolve the many-to-many relationship:
				
				<vskip size="small" />
				
				Teach<left-brace /><underline>Staff<underscore />ID, Paper<underscore />Code</underline><right-brace />; Staff<underscore />ID FK to Staff, Paper<underscore />Code FK to Paper
				
				<code-block>
CREATE TABLE Teach
( Staff_ID NUMBER(7),
 Paper_Code CHAR(7),
 --
 CONSTRAINT Teach_PK PRIMARY KEY (Staff_ID, Paper_Code),
 CONSTRAINT Teach_FK_to_Staff FOREIGN KEY (Staff_ID) REFERENCES Staff,
 CONSTRAINT Teach_FK_to_Paper FOREIGN KEY (Paper_Code) REFERENCES Paper
);
				</code-block>
				
				It<apostrophe />s important when implementing <quote>boolean</quote> style columns such as <code>International</code> in <code>Student</code> and <code>Visible</code> in <code>Assessment</code> that you are consistent in the values that you use across all such columns (more precisely, all such columns should have the same domain). Quite a few people did something like implement one column as <code>'T', 'F'</code> and the other as <code>'True', 'False'</code>, or even more subtle, <code>'t', 'f'</code> (remembering that SQL is case sensitive). Using inconsistent domains for columns that should have the same domain could lead to subtle bugs later on.
				
				This of course is really a consequence of not having a proper <code>BOOLEAN</code> data type in SQL. However, one person did discover<emdash />possibly inadvertently, given that it isn<apostrophe />t mentioned anywhere in the documentation<emdash />that <OracleServer /> now supports the use of the <code>BOOLEAN</code> data type in <code>CREATE TABLE</code>! This certainly wasn<apostrophe />t possible in older versions, where <code>BOOLEAN</code> was available in PL/SQL only.

</answer>
			
		</section>
		
		
		<newpage />
		
		
		<section>
		
			<title>The <tt>Enrolment</tt> entity</title>

<vskip size="large" />
			
			The year of enrolment cannot be earlier than the year in which the Institute was founded. (Technically it should also not be in the future, but we cannot check this in <OracleServer />.)
				
			<answer>
			
				Enrolment(<underline>Enrolment<underscore />ID</underline>, Description, Year<underscore />Enrolled, Comments, Paper<underscore />Code, Student<underscore />ID); Paper<underscore />Code FK to Paper, Student<underscore />ID FK to Student

<code-block>
CREATE TABLE Enrolment
( Enrolment_ID NUMBER(10),
 Description VARCHAR2(100) NOT NULL,
 Year_Enrolled NUMBER(4) NOT NULL
 CONSTRAINT Enrolment_Year_Enrolled_Range CHECK (Year_Enrolled >= 1982),
 Comments VARCHAR2(4000), -- or CLOB
 Student_ID NUMBER(7) NOT NULL,
 Paper_Code CHAR(7) NOT NULL,
 --
 CONSTRAINT Enrolment_PK PRIMARY KEY (Enrolment_ID),
 CONSTRAINT Enrolment_FK_to_Student
 FOREIGN KEY (Student_ID) REFERENCES Student,
 CONSTRAINT Enrolment_FK_to_Paper
 FOREIGN KEY (Paper_Code) REFERENCES Paper
);
				</code-block>
				
				A surprising number of people appear to have missed the statement of when the Institute was founded in the first paragraph of the specification!
				
				Another very common error was to set the size of the <code>Comments</code> column to a relatively small number, like 200. Think about how much you can say in that many characters (one and a bit text messages), then consider what kinds of things you might want to enter into a general comments column. We deducted marks for anything smaller than 500 characters. When you have no idea of how much you<apostrophe />re going to get, it<apostrophe />s much better to go large than to go small!
			
			</answer>
			
		</section>

<section>
		
			<title>The <tt>Assessment</tt> entity</title>

<tabular border="1">
				<tabular-columns>
					<column align="center" left-border="|" right-border="|" />
					<column align="left" right-border="|" />
					<column align="left" right-border="|" />
				</tabular-columns>
				<tabular-body>
					<row-rule />
					<row>
						<cell header="yes" />
						<cell header="yes">Column</cell>
						<cell header="yes">Description</cell>
					</row>
					<row-rule />
					<row>
						<cell><tt><hash /></tt></cell>
						<cell><code>Assessment_ID</code></cell>
						<cell>Internally generated 10 digit identifier</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Assessment_Year</code></cell>
						<cell>4 digits</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Name</code></cell>
						<cell>Up to 50 characters</cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Description</code></cell>
						<cell>Up to 500 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Type</code></cell>
						<cell>(see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Visible</code></cell>
						<cell>True/false, default false</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Weight</code></cell>
						<cell>0<endash />100, no decimal places</cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Maximum_Mark</code></cell>
						<cell>(see below)</cell>
					</row>
					<row-rule />
				</tabular-body>
			</tabular>

<itemised-list>
			
				<item>A new set of assessments is created for each year that a paper is offered. The year cannot be earlier than the year in which the Institute was founded. (Technically it should also not be in the future, but we cannot check this in <OracleServer />.)</item>
				
				<item>The assessment type must be one of the following: <quote>A</quote> (assignment), <quote>T</quote> (test) or <quote>X</quote> (exam).</item>
				
				<item>The <code>Maximum_Mark</code> attribute stores the maximum possible raw mark for the assessment (e.g., 30), while the <code>Weight</code> attribute stores the percentage weight of this assessment for the paper as a whole (e.g., 10<percent-sign />). If <code>Maximum_Mark</code> is not specified, then applications should use <code>Weight</code> for both.</item>
				
				<item>The <code>Visible</code> attribute controls whether or not the marks for this assessment are publicly accessible.</item>
				
			</itemised-list>
			
			<answer>
			
				Assessment(<underline>Assessment<underscore />ID</underline>, Assessment<underscore />Year, Name, Description, Type, Visible, Weight, Maximum<underscore />Mark, Paper<underscore />Code); Paper<underscore />Code FK to Paper

<code-block>
CREATE TABLE Assessment
( Assessment_ID NUMBER(10),
 Assessment_Year NUMBER(4) NOT NULL
 CONSTRAINT Assessment_Year_Range
 CHECK (Assessment_Year >= 1982),
 Name VARCHAR2(50) NOT NULL,
 Description VARCHAR2(500),
 Type CHAR(1) NOT NULL
 CONSTRAINT Assessment_Type_Valid CHECK (Type IN ('A', 'T', 'X')),
 Visible CHAR(1) DEFAULT 'F' NOT NULL
 CONSTRAINT Assessment_Visible_Valid CHECK (Visible IN ('T', 'F')),
 Weight NUMBER(3) NOT NULL
 CONSTRAINT Assessment_Weight_Range CHECK (Weight BETWEEN 0 AND 100),
 Maximum_Mark NUMBER(3),
 Paper_Code CHAR(7) NOT NULL,
 --
 CONSTRAINT Assessment_PK PRIMARY KEY (Assessment_ID),
 CONSTRAINT Assessment_FK_to_Paper
 FOREIGN KEY (Paper_Code) REFERENCES Paper
);
				</code-block>
				
			</answer>
			
		</section>
		
		
		<newpage />
		
		
		<section>
		
			<title>The <tt>Result</tt> entity</title>

<itemised-list>
			
				<item>The <code>Raw_Mark</code> attribute stores the raw mark awarded for an assessment. Its value should be between zero and the value of <code>Assessment.Maximum_Mark</code> (note that only the former is required for this assignment<emdash />bonus marks if you can also achieve the latter).</item>
				
				<item>The value of the <code>Weighted_Mark</code> attribute is calculated by the formula: <line-break />
				<code>Raw_Mark</code> / <code>Assessment.Maximum_Mark</code><space /> <times /><space /> <code>Assessment.Weight</code>.</item>
				
				<item>The value of the <code>Percentage_Mark</code> attribute is calculated by the formula: <line-break />
				<code>Raw_Mark</code> / <code>Assessment.Maximum_Mark</code><space /> <times /> 100.</item>
				
				<item>Note that the two calculations above are <emph>not</emph> constraints and should not be implemented as such. You may attempt to implement these calculations if you feel confident in your ability to do so, but please ensure that you complete the rest of the assignment first.</item>
				
			</itemised-list>
			
			<answer>
			
				Result(<underline>Assessment<underscore />ID, Enrolment<underscore />ID</underline>, Raw<underscore />Mark, Weighted<underscore />Mark, Percentage<underscore />Mark); Assessment<underscore />ID FK to Assessment, Enrolment<underscore />ID FK to Enrolment

<code-block>
CREATE TABLE Result
( Assessment_ID NUMBER(10),
 Enrolment_ID NUMBER(10),
 Raw_Mark NUMBER(4,1) NOT NULL,
 Weighted_Mark NUMBER NOT NULL,
 Percentage_Mark NUMBER(5,2) NOT NULL
 CONSTRAINT Result_Percentage_Mark_Range
 CHECK (Percentage_Mark BETWEEN 0 AND 100),
 --
 CONSTRAINT Result_PK PRIMARY KEY (Assessment_ID, Enrolment_ID),
 CONSTRAINT Result_FK_to_Assessment
 FOREIGN KEY (Assessment_ID) REFERENCES Assessment,
 CONSTRAINT Result_FK_to_Enrolment
 FOREIGN KEY (Enrolment_ID) REFERENCES Enrolment
);
				</code-block>
				
				A lot of people got the sizes of the various <code>NUMBER</code> columns incorrect. Remember that the number of decimal places is included in the total number of digits, not in addition to.
				
				We also accepted <code>FLOAT</code> and <code>BINARY_FLOAT</code> for <code>Weighted_Mark</code>. Anything with a fixed number of decimal places was marked down, as this is a fixed point number, not a floating point number.
				
			</answer>
			
		</section>
	
	</section>

</document>

Ignore Space Show notes View UsedCars.xml 0 → 100755
<?xml version="1.0" standalone="yes"?> <document class="fragment"> <section label="sec:database-info"> <title>System specification and details</title> <p>Happy Joe’s Quality Used Cars is a national chain of used car dealers that sells a wide range of modern, quality used cars. The company has branches around the country and employs about one hundred people nationwide. Happy Joe’s are currently designing and implementing a new corporate database, which will be housed at the head office in Dunedin. The requirements analysis phase of the project is almost complete, and you have been brought in as a database developer. It will be your task to implement and test an initial prototype of the specification resulting from the requirements analysis phase. A design-level entity-relationship diagram of the proposed database is shown in <hyperlink label="fig-erd"><reference label="fig-erd"/></hyperlink>, and more detailed specifications of the database requirements may be found in the following sections.</p> <figure label="fig-erd" latex-placement="!hb"> <caption>Design-level ERD of Happy Joe’s database</caption> <image basename="UsedCars_IE" location="images" latex-options="scale=0.85"> <description>Design-level ERD of Happy Joe’s database</description> </image> </figure> <section label="sec-staff"> <title>The <tt>Staff</tt> entities</title> <tabular border="1" align="left"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row> <cell header="yes" columns="3" align="left"><tt>Staff</tt></cell> </row> <row-rule /> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt><hash/></tt></cell> <cell><code>Staff_ID</code></cell> <cell>Internally generated 4 digit identifier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Firstname</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Lastname</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Address</code></cell> <cell>Up to 150 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Phone</code></cell> <cell>New Zealand landline or mobile number</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Date_Hired</code></cell> <cell>Date employee was first hired, default to current date</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Date_of_Birth</code></cell> <cell>Employee’s date of birth (see below)</cell> </row> <row-rule /> </tabular-body> </tabular> <p indent="no">As noted above, Happy Joe’s has about one hundred employees. The usual details such as name, address and phone number will be recorded. Employees must be at least 16 years old at the time they are first hired.</p> <answer> <p indent="no"><strong>Staff</strong><left-brace /><underline>Staff<underscore />ID</underline>, Firstname, Lastname, Address, Phone, Date<underscore />Hired, Date<underscore />of<underscore />Birth<right-brace /></p> <code-block> CREATE SEQUENCE Staff_ID_Seq START WITH 1000 MAXVALUE 9999; CREATE TABLE Staff ( Staff_ID NUMBER(4), Firstname VARCHAR2(50) NOT NULL, Lastname VARCHAR2(50) NOT NULL, Address VARCHAR2(150) NOT NULL, -- Use VARCHAR2 for phone numbers in order to retain leading zeros. -- Format: leading 0 plus 2 digits for carrier plus up to 8 digits, e.g., -- 02187654321, longer if we assume punctuation is included. Phone VARCHAR2(11) NOT NULL, Date_Hired DATE DEFAULT SYSDATE NOT NULL, Date_of_Birth DATE NOT NULL, -- CONSTRAINT Staff_Valid_Age CHECK ( ( Date_Hired - TO_YMINTERVAL( '16-0' ) ) >= Date_of_Birth ), -- CONSTRAINT Staff_PK PRIMARY KEY ( Staff_ID ) ); </code-block> <p indent="no">This solution uses the discrete approach for transforming subtypes (i.e., one relation for the supertype, plus one relation for each of the subtypes). The reason for this is that the three <code>Staff</code> subtypes each have their own attributes and it’s easier to add more subtypes if necessary. You could probably also make a reasonable argument for the additive approach (one relation for each subtype, including the supertype attributes in each) if you assume that the subtypes are exclusive, i.e., a staff member can’t be two different types at once (this seems unlikely in practice, however). The integrated approach is inappropriate for this scenario because it would force us to make all the subtype attributes optional (allow nulls), where currently they are all mandatory (no nulls).</p> <p>There are several different ways to calculate the age: using <code>INTERVAL</code> types as shown above, using the <code>MONTHS_BETWEEN</code> function, or simply doing your own date arithmetic calculation based on the number of days between the two dates. However, when doing the latter, you need to take into account two things:</p> <enumerated-list> <item>The number of days per year. The actual number varies depending on how you measure it, but 365.25 is a close enough approximation for practical purposes <smiley />.</item> <item>Leap years. Usually there are at least four and at most five in any given sixteen year period. Occasionally there might be only three (for example, 1900 wasn’t a leap year), but this only happens at most once per century!</item> </enumerated-list> <p indent="no">If you work on the basis that “one year is 365 days”, then your age calculation could be off by up to a week! (Incidentally, using something like <code>TO_CHAR(date, 'YYYY')</code> is even worse; if <code>Date_of_Birth</code> is December 31 and <code>Date_Hired</code> is January 1, the calculation will be off by a whole year!) The built-in date functions already take these factors into account, so it's much safer to use them than to implement your own solution.</p> </answer> <tabular border="1" align="left"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row> <cell header="yes" columns="3" align="left"><tt>Service</tt></cell> </row> <row-rule /> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt></tt></cell> <cell><code>Hourly_Rate</code></cell> <cell>Hourly pay rate (see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Total_Hours</code></cell> <cell>Total hours worked to date this year, default to 0 (see below)</cell> </row> <row-rule /> </tabular-body> </tabular> <p indent="no"><code>Hourly_Rate</code> must meet minimum wage requirements: at least <dollar-sign />10.40 for those aged 16 or 17, and at least <dollar-sign />13.00 for those 18 or older. <code>Total_Hours</code> is measured to the nearest quarter hour and must be in the range 0–3500 (= 40 hours per week <times /> 52 weeks per year, plus a generous allowance for overtime).</p> <answer> <p indent="no"><strong>Service</strong><left-brace /><underline>Staff<underscore />ID</underline>, Hourly<underscore />Rate, Total<underscore />Hours<right-brace /> (foreign keys: Staff<underscore />ID <rightarrow /><space /><strong>Staff</strong>)</p> <code-block> CREATE TABLE Service ( Staff_ID NUMBER(4), -- Can't validate Hourly_Rate using a CHECK constraint, as we would need to -- access values from the Staff table. Hourly_Rate NUMBER(5,2) NOT NULL, Total_Hours NUMBER(6,2) DEFAULT 0 NOT NULL CONSTRAINT Service_Total_Hours_Range CHECK ( Total_Hours BETWEEN 0 AND 3500 ) CONSTRAINT Service_Total_Hours_Quarters CHECK ( TRUNC( Total_Hours * 4 ) = ( Total_Hours * 4 ) ), -- CONSTRAINT Service_PK PRIMARY KEY ( Staff_ID ), CONSTRAINT Service_FK_to_Staff FOREIGN KEY ( Staff_ID ) REFERENCES Staff ON DELETE CASCADE ); CREATE OR REPLACE TRIGGER Validate_Service_Hourly_Rate BEFORE INSERT OR UPDATE OF Hourly_Rate ON Service FOR EACH ROW DECLARE Minimum_Rate NUMBER; BEGIN -- Use the CASE feature of SELECT to make the query return the minimum -- rate based on age rather than just retrieving the dates and calculating -- the rate within the trigger. We assume that there are no employees with -- an age < 16 in the database, even though it's technically possible -- with the current schema; see if you can figure out how :). SELECT CASE WHEN ( ( SYSDATE - TO_YMINTERVAL( '18-0' ) ) < Date_of_Birth ) THEN 10.4 -- these two should be constants somewhere! ELSE 13 END INTO Minimum_Rate FROM Staff WHERE Staff.Staff_ID = :NEW.Staff_ID; IF ( :NEW.Hourly_Rate < Minimum_Rate ) THEN RAISE_APPLICATION_ERROR( -20000, 'Hourly pay rate of ' \|\| TO_CHAR( :NEW.Hourly_Rate, '$90.00' ) \|\| ' for employee ' \|\| :NEW.Staff_ID \|\| ' is less than their minimum rate of ' \|\| TO_CHAR( Minimum_Rate, '$90.00' ) ); END IF; END; </code-block> <p indent="no">It makes sense to include <code>ON DELETE CASCADE</code> on the foreign keys from subtypes to <code>Staff</code>, as subtype instances can’t exist independently of the corresponding supertype instance.</p> <p>We also accepted <code>Service_Staff</code> as a table name, on the theory that this is a reasonable transformation for the purposes of clarity.</p> </answer> <tabular border="1" align="left"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row> <cell header="yes" columns="3" align="left"><tt>Other</tt></cell> </row> <row-rule /> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt></tt></cell> <cell><code>Salary</code></cell> <cell>Total annual salary (see below)</cell> </row> <row-rule /> </tabular-body> </tabular> <p indent="no"><code>Salary</code> must meet minimum wage requirements: at least <dollar-sign />21<digitsep />632 (= <dollar-sign />10.40 <times /> 40 hours per week <times /> 52 weeks per year) for those aged 16 or 17, and at least <dollar-sign />27<digitsep />040 for those 18 or older.</p> <answer> <p indent="no"><strong>Other</strong><left-brace /><underline>Staff<underscore />ID</underline>, Salary<right-brace /> (foreign keys: Staff<underscore />ID <rightarrow /><space /><strong>Staff</strong>)</p> <code-block> CREATE TABLE Other ( Staff_ID NUMBER(4), -- Can't validate Salary using a CHECK constraint, as we would need to -- access values from the Staff table. Salary NUMBER(8,2) NOT NULL, -- CONSTRAINT Other_PK PRIMARY KEY ( Staff_ID ), CONSTRAINT Other_FK_to_Staff FOREIGN KEY ( Staff_ID ) REFERENCES Staff ON DELETE CASCADE ); CREATE OR REPLACE TRIGGER Validate_Other_Salary BEFORE INSERT OR UPDATE OF Salary ON Other FOR EACH ROW DECLARE Minimum_Salary NUMBER; BEGIN SELECT CASE WHEN ( ( SYSDATE - TO_YMINTERVAL( '18-0' ) ) < Date_of_Birth ) THEN 21632 -- these two should be constants somewhere! ELSE 27040 END INTO Minimum_Salary FROM Staff WHERE Staff.Staff_ID = :NEW.Staff_ID; IF ( :NEW.Salary < Minimum_Salary ) THEN RAISE_APPLICATION_ERROR( -20000, 'Salary of ' \|\| TO_CHAR( :NEW.Salary, '$999,990.00' ) \|\| ' for employee ' \|\| :NEW.Staff_ID \|\| ' is less than their minimum salary of ' \|\| TO_CHAR( Minimum_Salary, '$999,990.00' ) ); END IF; END; </code-block> <p indent="no">Similar to <code>Service_Staff</code> above. We also accepted <code>Other_Staff</code> as a table name.</p> </answer> <tabular border="1" align="left"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row> <cell header="yes" columns="3" align="left"><tt>Sales</tt></cell> </row> <row-rule /> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt></tt></cell> <cell><code>On_Commission</code></cell> <cell>“Boolean” (i.e., effectively true/false)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Commission_Rate</code></cell> <cell>Percentage as a fraction, 0.00–0.30 (see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Total_Earnings</code></cell> <cell>Total earnings to date this year, <ge /><space /><dollar-sign />0.00</cell> </row> <row-rule /> </tabular-body> </tabular> <p indent="no">Some sales staff are paid on commission (up to 30<percent-sign /> of the value of each sale), while others are paid a flat rate per sale that varies depending on the type of car sold (e.g., <dollar-sign />100 for a Toyota Corolla vs.<space /><dollar-sign />500 for a BMW M3; these rates are stored in <code>Car</code>—see <hyperlink label="sec-car"><reference label="sec-car"/></hyperlink>). If the salesrep is paid on commission then <code>On_Commission</code> is true and <code>Commission_Rate</code> must be greater than zero. If the salesrep is paid on flat rate then <code>On_Commission</code> is false and <code>Commission_Rate</code> must be zero.</p> <p><code>Total_Earnings</code> stores the total amount earned by a salesrep to date in the current financial year (1 April to 31 March). For salesreps who are on commission, this total is calculated from <code>Commission_Rate</code><space /><times /><space /><code>Sale.Amount</code>. For salesreps who are not on commission, the total is calculated from <code>Car.Flat_Rate</code> (via <code>Sale</code>—see <hyperlink label="sec-car"><reference label="sec-car"/></hyperlink> and <hyperlink label="sec-sale"><reference label="sec-sale"/></hyperlink>).</p> <answer> <p indent="no"><strong>Sales</strong><left-brace /><underline>Staff<underscore />ID</underline>, On<underscore />Commission, Commission<underscore />Rate, Total<underscore />Earnings<right-brace /> (foreign keys: Staff<underscore />ID <rightarrow /><space /><strong>Staff</strong>)</p> <code-block> CREATE TABLE Sales ( Staff_ID NUMBER(4), On_Commission CHAR(1) DEFAULT 'N' NOT NULL CONSTRAINT Sales_Valid_On_Commission CHECK ( On_Commission IN ( 'Y', 'N' ) ), Commission_Rate NUMBER(3,2) NOT NULL CONSTRAINT Sales_Valid_Commission_Rate CHECK ( Commission_Rate BETWEEN 0.00 AND 0.30 ), Total_Earnings NUMBER(8,2) NOT NULL CONSTRAINT Sales_Valid_Total_Earnings CHECK ( Total_Earnings >= 0.00 ), -- CONSTRAINT Sales_Check_Commission CHECK ( ( ( On_Commission = 'N' ) AND ( Commission_Rate = 0 ) ) OR ( ( On_Commission = 'Y' ) AND ( Commission_Rate > 0 ) ) ), -- CONSTRAINT Sales_PK PRIMARY KEY ( Staff_ID ), CONSTRAINT Sales_FK_to_Staff FOREIGN KEY ( Staff_ID ) REFERENCES Staff ON DELETE CASCADE ); </code-block> <p indent="no">Similar to <code>Service_Staff</code> above. We also accepted <code>Other_Staff</code> as a table name. Note that the paragraph above about <code>Total_Earnings</code> describes the <em>process</em> of how it is calculated, not a constraint on its possible values, so implementing this as a constraint is incorrect.</p> </answer> </section> <section label="sec-customer"> <title>The <tt>Customer</tt> entity</title> <tabular border="1" align="left"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row-rule /> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt><hash /></tt></cell> <cell><code>Customer_ID</code></cell> <cell>Internally generated 6 digit identifier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Firstname</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Lastname</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Address</code></cell> <cell>Up to 150 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Phone</code></cell> <cell>(see <code>Staff</code> in <hyperlink label="sec-staff"><reference label="sec-staff"/></hyperlink>)</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Email</code></cell> <cell>Up to 50 characters</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Credit_Rating</code></cell> <cell>One of “A”, “B”, “C” or “D”</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Comments</code></cell> <cell>Arbitrary text</cell> </row> <row-rule /> </tabular-body> </tabular> <p indent="no">The usual details will be recorded for each customer: name, address, phone and optionally an email address. The credit rating is also optional.</p> <answer> <p indent="no"><strong>Customer</strong><left-brace /><underline>Customer<underscore />ID</underline>, Firstname, Lastname, Address, Phone, Email, Credit<underscore />Rating, <newline />Comments<right-brace /></p> <code-block> CREATE SEQUENCE Customer_ID_Seq START WITH 100000 MAXVALUE 999999; CREATE TABLE Customer ( Customer_ID NUMBER(6), Firstname VARCHAR2(50) NOT NULL, Lastname VARCHAR2(50) NOT NULL, Address VARCHAR2(150) NOT NULL, Phone VARCHAR2(11) NOT NULL, Email VARCHAR2(50), -- optionally CHECK format if desired Credit_Rating CHAR(1) CONSTRAINT Customer_Valid_Credit_Rating CHECK ( Credit_Rating IN ( 'A', 'B', 'C', 'D' ) ), Comments CLOB, -- CONSTRAINT Customer_PK PRIMARY KEY ( Customer_ID ) ); </code-block> <p indent="no">Many people assigned the <code>Comments</code> a size of 500 characters or less, which is far too small for a general comments column. If we assume an average word length of five characters plus one for the inter-word space, then 500 characters can only hold about 83 words! 100 characters would be only 16 words! We accepted 500 characters as a bare minimum; anything below that lost marks. A better choice would be to use either the maximum allowable VARCHAR2 size of 4000, or just use a CLOB, which for most practical purposes is effectively unlimited in size. A similar argument applies to the <code>Details</code> columns in <code>Purchase</code> and <code>Sale</code>.</p> </answer> </section> <section label="sec-car"> <title>The <tt>Car</tt> entity</title> <tabular border="1" align="left"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row-rule/> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt><hash/></tt></cell> <cell><code>VIN</code></cell> <cell>17 character Vehicle Identification Number (VIN)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Registration</code></cell> <cell>Up to 6 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Make</code></cell> <cell>Up to 20 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Model</code></cell> <cell>Up to 30 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Year</code></cell> <cell>Year of manufacture, no earlier than 1980</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Colour</code></cell> <cell>Up to 20 characters</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Odometer</code></cell> <cell>Current odometer reading, 0.0–999<digitsep />999.9</cell> </row> <row> <cell><tt></tt></cell> <cell><code>First_Registered</code></cell> <cell>Date the car was first registered in New Zealand</cell> </row> <row> <cell><tt>o</tt></cell> <cell><code>Last_Serviced</code></cell> <cell>Date the car was last serviced</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Price</code></cell> <cell>List price of car, whole number <ge /><space /><dollar-sign />0</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Flat_Rate</code></cell> <cell>Flat rate paid to salesrep (where applicable), <gt /><space /><dollar-sign />0</cell> </row> <row-rule/> </tabular-body> </tabular> <p indent="no">Happy Joe’s sell only modern cars, and so will not purchase anything manufactured before 1980. The value of <code>Flat_Rate</code> is determined by how frequently each particular type of car is sold (this information is not stored in the database); the “easier” it is to sell a car, the lower the value of <code>Flat_Rate</code>. All cars have a value for <code>Flat_Rate</code> because we do not know in advance whether they will be sold by a salesrep on commission or on flat rate. The value of <code>Flat_Rate</code> is independent of the sale price, which is why it is stored here rather than in <code>Sale</code>.</p> <answer> <p indent="no"><strong>Car</strong><left-brace /><underline>VIN</underline>, Registration, Make, Model, Year, Colour, Odometer, First<underscore />Registered, Last<underscore />Serviced, Price, Flat<underscore />Rate<right-brace /></p> <code-block> CREATE TABLE Car ( VIN CHAR(17), -- optionally CHECK format if desired Registration VARCHAR2(6) NOT NULL, Make VARCHAR2(20) NOT NULL, Model VARCHAR2(30) NOT NULL, Year NUMBER(4) NOT NULL CONSTRAINT Car_Valid_Year CHECK ( Year >= 1980 ), Colour VARCHAR2(20) NOT NULL, Odometer NUMBER(7,1) NOT NULL CONSTRAINT Car_Valid_Odometer CHECK ( Odometer BETWEEN 0.0 AND 999999.9 ), First_Registered DATE NOT NULL, Last_Serviced DATE, Price NUMBER(6) NOT NULL CONSTRAINT Car_Valid_Price CHECK ( Price >= 0 ), Flat_Rate NUMBER(4) NOT NULL CONSTRAINT Car_Valid_Flat_Rate CHECK ( Flat_Rate > 0 ), -- CONSTRAINT Car_PK PRIMARY KEY ( VIN ) ); </code-block> <p indent="no">The statement of VIN as “17 characters” was obviously a little too subtle for some people, who implemented it as NUMBER(17) rather than CHAR(17). VINs contain both numbers and letters, and the format is well-documented if you weren’t sure (e.g., look up “VIN” on Wikipedia).</p> <p>There was a small typo in the original specification, which said that the value of <code>Odometer</code> should be “0.0–999,999.<underline>0</underline>”, when it should actually have been 0.0–999,999.<underline>9</underline> (this has been corrected above). We accepted either when marking.</p> <p>There is little point in storing <code>Year</code> as a <code>DATE</code>, as we won’t be using anything but the year part anyway. Storing it as a <code>DATE</code> means that we would need to do unnecessary extra work to extract the year part from the date. If you don’t need something, don’t store it, especially if it makes things more complicated!</p> </answer> </section> <section label="sec-feature"> <title>The <tt>Feature</tt> entity</title> <tabular border="1" align="left"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row-rule/> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt><hash/></tt></cell> <cell><code>Feature_Code</code></cell> <cell>5 character code</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Description</code></cell> <cell>Up to 100 characters</cell> </row> <row-rule/> </tabular-body> </tabular> <p indent="no">Cars may have any number of optional features, such as air conditioning, side airbags, body kit, iPod integration, cruise control, etc.</p> <answer> <p indent="no"><strong>Feature</strong><left-brace /><underline>Feature<underscore />Code</underline>, Description<right-brace /></p> <code-block> CREATE TABLE Feature ( Feature_Code VARCHAR2(5), Description VARCHAR2(100) NOT NULL, -- CONSTRAINT Feature_PK PRIMARY KEY ( Feature_Code ) ); </code-block> <p indent="no">At this point we also need to add an associative entity to resolve the many-to-many relationship between <strong>Car</strong> and <strong>Feature</strong>:</p> <p indent="no"><strong>Car<underscore />Feature</strong><left-brace /><underline>VIN, Feature<underscore />Code</underline><right-brace /> (foreign keys: VIN <rightarrow /><space /><strong>Car</strong>, Feature<underscore />Code <rightarrow /><space /><strong>Feature</strong>)</p> <code-block> CREATE TABLE Car_Feature ( VIN VARCHAR2(17), Feature_Code VARCHAR2(5), -- CONSTRAINT Car_Feature_PK PRIMARY KEY ( VIN, Feature_Code ), CONSTRAINT Car_Feature_FK_to_Car FOREIGN KEY ( VIN ) REFERENCES Car ON DELETE CASCADE, CONSTRAINT Car_Feature_FK_to_Feature FOREIGN KEY ( Feature_Code ) REFERENCES Feature ON DELETE CASCADE ); </code-block> <p indent="no">Again, it makes sense to include <code>ON DELETE CASCADE</code> on (both!) the foreign keys, as the rows in <code>Car_Feature</code> can’t exist independently of the cars and features that they are related to.</p> </answer> </section> <section label="sec-warranty"> <title>The <tt>Warranty</tt> entity</title> <tabular border="1" align="left"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row-rule/> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt><hash/></tt></cell> <cell><code>W_Code</code></cell> <cell>1 character warranty code (see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Duration</code></cell> <cell>In months (see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Distance</code></cell> <cell>In kilometres (see below)</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Description</code></cell> <cell>Up to 250 characters</cell> </row> <row-rule/> </tabular-body> </tabular> <p indent="no">The New Zealand government mandates four categories of dealer warranty for used cars. <code>Warranty</code> is a lookup table that records details of these warranty categories and enables them to be easily changed if the regulations change. An excerpt from a government discussion paper<footnote><em>Discussion Paper on Proposed Consumer Information Standard for Secondhand Motor Vehicles</em>, Ministry of Consumer Affairs, New Zealand Government, May 1998, ISBN 0-478-00075-8.</footnote> defining the different categories of warranty is included as “Appendix 4” at the end of this document; use these details to populate the table with appropriate data.</p> <answer> <p indent="no"><strong>Warranty</strong><left-brace /><underline>W<underscore />Code</underline>, Duration, Distance, Description<right-brace /></p> <code-block> CREATE TABLE Warranty ( W_Code CHAR(1), Duration NUMBER(1) NOT NULL, Distance NUMBER(4) NOT NULL, Description VARCHAR2(250) NOT NULL, -- CONSTRAINT Warranty_PK PRIMARY KEY ( W_Code ) ); INSERT INTO Warranty ( W_Code, Duration, Distance, Description ) VALUES ( 'A' , 3, 5000, 'Category A motor vehicle' ); INSERT INTO Warranty ( W_Code, Duration, Distance, Description ) VALUES ( 'B' , 2, 3000, 'Category B motor vehicle' ); INSERT INTO Warranty ( W_Code, Duration, Distance, Description ) VALUES ( 'C' , 1, 1500, 'Category C motor vehicle' ); INSERT INTO Warranty ( W_Code, Duration, Distance, Description ) VALUES ( 'D' , 0, 0, 'Category D motor vehicle' ); </code-block> <p indent="no">This is a lookup table that is intended to define the types of warranties allowed for vehicles. If the regulations change, it’s a simple matter to change the contents of the table to reflect this, which means that the table is effectively acting as a configurable constraint on warranty type. It would therefore be counterproductive to add constraints to the columns of this table based on the values specified in the Appendix, as the whole point of a lookup table is that the <em>contents</em> of the table effectively define a constraint. The values in the Appendix should therefore be used only to determine the data to be inserted into the table.</p> <p>On a similar note, there is little point in trying to enforce constraints between the specification of the warranty type and the <code>First_Registered</code> column in <code>Car</code>. There is no dedicated column in the table to store this information, so it could only be stored in <code>Description</code>, and it would probably be almost impossible in practice to extract anything useful from this column. It could be possible, however, to use a trigger to check that a car is assigned the correct warranty category for it’s odometer reading when it’s sold.</p> </answer> </section> <section label="sec-purchase"> <title>The <tt>Purchase</tt> entity</title> <tabular border="1" align="left"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row-rule/> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt><hash/></tt></cell> <cell><code>Purchase_ID</code></cell> <cell>Internally generated 8 digit identifier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Purchase_Date</code></cell> <cell>Date of purchase</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Details</code></cell> <cell>Arbitrary text</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Amount</code></cell> <cell>Price paid for the car, whole number <ge /><space /><dollar-sign />0</cell> </row> <row-rule/> </tabular-body> </tabular> <p indent="no">Purchases are for a single car only (i.e., no bulk purchases). Trade-ins are effectively treated as a special type of purchase (see <code>Sale</code> below).</p> <answer> <p indent="no"><strong>Purchase</strong><left-brace /><underline>Purchase<underscore />ID</underline>, Purchase<underscore />Date, Details, Amount, VIN, Customer<underscore />ID, Salesrep<underscore />ID<right-brace /> (foreign keys: VIN <rightarrow /><space /><strong>Car</strong>, Customer<underscore />ID <rightarrow /><space /><strong>Customer</strong>, Salesrep<underscore />ID <rightarrow /><space /><strong>Sales</strong>)</p> <code-block> CREATE SEQUENCE Purchase_ID_Seq START WITH 10000000 MAXVALUE 99999999; CREATE TABLE Purchase ( Purchase_ID NUMBER(8), Purchase_Date DATE NOT NULL, Details CLOB NOT NULL, Amount NUMBER(6) NOT NULL CONSTRAINT Purchase_Valid_Amount CHECK ( Amount >= 0 ), VIN CHAR(17) NOT NULL, Customer_ID NUMBER(6) NOT NULL, Salesrep_ID NUMBER(4) NOT NULL, -- CONSTRAINT Purchase_PK PRIMARY KEY ( Purchase_ID ), CONSTRAINT Purchase_FK_to_Car FOREIGN KEY ( VIN ) REFERENCES Car, CONSTRAINT Purchase_FK_to_Customer FOREIGN KEY ( Customer_ID ) REFERENCES Customer, CONSTRAINT Purchase_FK_to_Sales FOREIGN KEY ( Salesrep_ID ) REFERENCES Sales ); </code-block> <p indent="no">Note the absence of <code>ON DELETE CASCADE</code> on the foreign keys in this table. If we attempt to delete a salesrep, it makes little sense to delete all their associated purchases, especially if they are completed. This would cause a serious accounting problem for the company. A better solution might be to have a “dummy” salesrep that can have “orphaned” purchases assigned to it.</p> </answer> </section> <section label="sec-sale"> <title>The <tt>Sale</tt> entity</title> <tabular border="1" align="left"> <tabular-columns> <column align="center" left-border="\|" right-border="\|"/> <column align="left" right-border="\|"/> <column align="left" right-border="\|"/> </tabular-columns> <tabular-body> <row-rule/> <row> <cell header="yes"/> <cell header="yes">Column</cell> <cell header="yes">Description</cell> </row> <row-rule/> <row> <cell><tt><hash/></tt></cell> <cell><code>Sale_ID</code></cell> <cell>Internally generated 8 digit identifier</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Sale_Date</code></cell> <cell>Date of sale</cell> </row> <row> <cell><tt></tt></cell> <cell><code>Details</code></cell> <cell>Arbitrary text</cell> </row> <row> <cell><tt>*</tt></cell> <cell><code>Amount</code></cell> <cell>Price the car was sold for, whole number <ge /><space /><dollar-sign />0</cell> </row> <row-rule/> </tabular-body> </tabular> <p indent="no">Sales are for a single car only (i.e., no bulk sales). Some sales involve the trade-in of a single car, which is effectively treated as a special type of purchase that is linked to the corresponding sale.</p> <answer> <p indent="no"><strong>Sale</strong><left-brace /><underline>Sale<underscore />ID</underline>, Sale<underscore />Date, Details, Amount, VIN, Customer<underscore />ID, Salesrep<underscore />ID, Tradein<underscore />ID<right-brace /> (foreign keys: VIN <rightarrow /><space /><strong>Car</strong>, Customer<underscore />ID <rightarrow /><space /><strong>Customer</strong>, Salesrep<underscore />ID <rightarrow /><space /><strong>Sales</strong>, W<underscore />Code <rightarrow /><space /><strong>Warranty, Tradein<underscore />ID <rightarrow /><space /><strong>Purchase</strong></strong>)</p> <code-block> CREATE SEQUENCE Sale_ID_Seq START WITH 10000000 MAXVALUE 99999999; CREATE TABLE Sale ( Sale_ID NUMBER(8), Sale_Date DATE NOT NULL, Details CLOB NOT NULL, Amount NUMBER(6) NOT NULL CONSTRAINT Sale_Valid_Amount CHECK ( Amount >= 0 ), VIN CHAR(17) NOT NULL, Customer_ID NUMBER(6) NOT NULL, Salesrep_ID NUMBER(4) NOT NULL, W_Code CHAR(1) NOT NULL, Tradein_ID NUMBER(8), -- CONSTRAINT Sale_PK PRIMARY KEY ( Sale_ID ), CONSTRAINT Sale_FK_to_Car FOREIGN KEY ( VIN ) REFERENCES Car, CONSTRAINT Sale_FK_to_Customer FOREIGN KEY ( Customer_ID ) REFERENCES Customer, CONSTRAINT Sale_FK_to_Warranty FOREIGN KEY ( W_Code ) REFERENCES Warranty, CONSTRAINT Sale_FK_to_Sales FOREIGN KEY ( Salesrep_ID ) REFERENCES Sales, CONSTRAINT Sale_FK_to_Purchase FOREIGN KEY ( Tradein_ID ) REFERENCES Purchase ); </code-block> <p indent="no">Similar to <code>Purchase</code> above. While the foreign key for trade-ins could go in either table (or even both), it really makes most sense to place it here, since trade-ins only occur as part of a sale transaction.</p> </answer> </section> <newpage /> <p indent="no"> <image basename="UsedCarWarranties" location="images" latex-options="width=\columnwidth,keepaspectratio"> <description>Details of used car dealer warranties in New Zealand</description> </image> </p> </section> </document>

Ignore Space Show notes View

UsedCars.xml 0 → 100755

<?xml version="1.0" standalone="yes"?>

<section label="sec:database-info">
	
		<title>System specification and details</title>
		
		Happy Joe’s Quality Used Cars is a national chain of used car dealers that sells a wide range of modern, quality used cars. The company has branches around the country and employs about one hundred people nationwide. Happy Joe’s are currently designing and implementing a new corporate database, which will be housed at the head office in Dunedin. The requirements analysis phase of the project is almost complete, and you have been brought in as a database developer. It will be your task to implement and test an initial prototype of the specification resulting from the requirements analysis phase. A design-level entity-relationship diagram of the proposed database is shown in <hyperlink label="fig-erd"><reference label="fig-erd"/></hyperlink>, and more detailed specifications of the database requirements may be found in the following sections.

<figure label="fig-erd" latex-placement="!hb">
			<caption>Design-level ERD of Happy Joe’s database</caption>
			<image basename="UsedCars_IE" location="images" latex-options="scale=0.85">
				<description>Design-level ERD of Happy Joe’s database</description>
			</image>
		</figure>

<section label="sec-staff">
		
			<title>The <tt>Staff</tt> entities</title>

CREATE TABLE Staff
( Staff_ID NUMBER(4),
 Firstname VARCHAR2(50) NOT NULL,
 Lastname VARCHAR2(50) NOT NULL,
 Address VARCHAR2(150) NOT NULL,
 -- Use VARCHAR2 for phone numbers in order to retain leading zeros.
 -- Format: leading 0 plus 2 digits for carrier plus up to 8 digits, e.g.,
 -- 02187654321, longer if we assume punctuation is included.
 Phone VARCHAR2(11) NOT NULL,
 Date_Hired DATE DEFAULT SYSDATE
 NOT NULL,
 Date_of_Birth DATE NOT NULL,
 --
 CONSTRAINT Staff_Valid_Age
 CHECK ( ( Date_Hired - TO_YMINTERVAL( '16-0' ) ) &gt;= Date_of_Birth ),
 --
 CONSTRAINT Staff_PK PRIMARY KEY ( Staff_ID )
);
				</code-block>
				
				This solution uses the discrete approach for transforming subtypes (i.e., one relation for the supertype, plus one relation for each of the subtypes). The reason for this is that the three <code>Staff</code> subtypes each have their own attributes and it’s easier to add more subtypes if necessary. You could probably also make a reasonable argument for the additive approach (one relation for each subtype, including the supertype attributes in each) if you assume that the subtypes are exclusive, i.e., a staff member can’t be two different types at once (this seems unlikely in practice, however). The integrated approach is inappropriate for this scenario because it would force us to make all the subtype attributes optional (allow nulls), where currently they are all mandatory (no nulls).
				
				There are several different ways to calculate the age: using <code>INTERVAL</code> types as shown above, using the <code>MONTHS_BETWEEN</code> function, or simply doing your own date arithmetic calculation based on the number of days between the two dates. However, when doing the latter, you need to take into account two things:
				
				<enumerated-list>
				
					<item>The number of days per year. The actual number varies depending on how you measure it, but 365.25 is a close enough approximation for practical purposes <smiley />.</item>
					
					<item>Leap years. Usually there are at least four and at most five in any given sixteen year period. Occasionally there might be only three (for example, 1900 wasn’t a leap year), but this only happens at most once per century!</item>
					
				</enumerated-list>
				
				If you work on the basis that “one year is 365 days”, then your age calculation could be off by up to a week! (Incidentally, using something like <code>TO_CHAR(date, 'YYYY')</code> is even worse; if <code>Date_of_Birth</code> is December 31 and <code>Date_Hired</code> is January 1, the calculation will be off by a whole year!) The built-in date functions already take these factors into account, so it's much safer to use them than to implement your own solution.
				
			</answer>
				
			<tabular border="1" align="left">
				<tabular-columns>
					<column align="center" left-border="|" right-border="|"/>
					<column align="left" right-border="|"/>
					<column align="left" right-border="|"/>
				</tabular-columns>
				<tabular-body>
					<row>
						<cell header="yes" columns="3" align="left"><tt>Service</tt></cell>
					</row>
					<row-rule />
					<row>
						<cell header="yes"/>
						<cell header="yes">Column</cell>
						<cell header="yes">Description</cell>
					</row>
					<row-rule/>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Hourly_Rate</code></cell>
						<cell>Hourly pay rate (see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Total_Hours</code></cell>
						<cell>Total hours worked to date this year, default to 0 (see below)</cell>
					</row>
					<row-rule />
				</tabular-body>
			</tabular>
			
			<code>Hourly_Rate</code> must meet minimum wage requirements: at least <dollar-sign />10.40 for those aged 16 or 17, and at least <dollar-sign />13.00 for those 18 or older. <code>Total_Hours</code> is measured to the nearest quarter hour and must be in the range 0–3500 (= 40 hours per week <times /> 52 weeks per year, plus a generous allowance for overtime).
			
			<answer>
			
				Service<left-brace /><underline>Staff<underscore />ID</underline>, Hourly<underscore />Rate, Total<underscore />Hours<right-brace /> (foreign keys: Staff<underscore />ID <rightarrow /><space />Staff)
				
				<code-block>
CREATE TABLE Service
( Staff_ID NUMBER(4),
 -- Can't validate Hourly_Rate using a CHECK constraint, as we would need to
 -- access values from the Staff table.
 Hourly_Rate NUMBER(5,2) NOT NULL,
 Total_Hours NUMBER(6,2) DEFAULT 0 NOT NULL
 CONSTRAINT Service_Total_Hours_Range
 CHECK ( Total_Hours BETWEEN 0 AND 3500 )
 CONSTRAINT Service_Total_Hours_Quarters
 CHECK ( TRUNC( Total_Hours * 4 ) = ( Total_Hours * 4 ) ),
 --
 CONSTRAINT Service_PK PRIMARY KEY ( Staff_ID ),
 CONSTRAINT Service_FK_to_Staff
 FOREIGN KEY ( Staff_ID ) REFERENCES Staff ON DELETE CASCADE
);

CREATE OR REPLACE TRIGGER Validate_Service_Hourly_Rate
 BEFORE INSERT OR UPDATE OF Hourly_Rate ON Service
 FOR EACH ROW
DECLARE
 Minimum_Rate NUMBER;
BEGIN
 -- Use the CASE feature of SELECT to make the query return the minimum
 -- rate based on age rather than just retrieving the dates and calculating
 -- the rate within the trigger. We assume that there are no employees with
 -- an age &lt; 16 in the database, even though it's technically possible
 -- with the current schema; see if you can figure out how :).
 SELECT CASE WHEN ( ( SYSDATE - TO_YMINTERVAL( '18-0' ) ) &lt; Date_of_Birth )
 THEN 10.4 -- these two should be constants somewhere!
 ELSE 13
 END INTO Minimum_Rate
 FROM Staff
 WHERE Staff.Staff_ID = :NEW.Staff_ID;
 
 IF ( :NEW.Hourly_Rate &lt; Minimum_Rate ) THEN
 RAISE_APPLICATION_ERROR( -20000,
 'Hourly pay rate of ' || TO_CHAR( :NEW.Hourly_Rate, '$90.00' ) ||
 ' for employee ' || :NEW.Staff_ID || 
 ' is less than their minimum rate of ' ||
 TO_CHAR( Minimum_Rate, '$90.00' ) );
 END IF;
END;
				</code-block>
				
				It makes sense to include <code>ON DELETE CASCADE</code> on the foreign keys from subtypes to <code>Staff</code>, as subtype instances can’t exist independently of the corresponding supertype instance.
				
				We also accepted <code>Service_Staff</code> as a table name, on the theory that this is a reasonable transformation for the purposes of clarity.
				
			</answer>
				
			<tabular border="1" align="left">
				<tabular-columns>
					<column align="center" left-border="|" right-border="|"/>
					<column align="left" right-border="|"/>
					<column align="left" right-border="|"/>
				</tabular-columns>
				<tabular-body>
					<row>
						<cell header="yes" columns="3" align="left"><tt>Other</tt></cell>
					</row>
					<row-rule />
					<row>
						<cell header="yes"/>
						<cell header="yes">Column</cell>
						<cell header="yes">Description</cell>
					</row>
					<row-rule/>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Salary</code></cell>
						<cell>Total annual salary (see below)</cell>
					</row>
					<row-rule />
				</tabular-body>
			</tabular>
			
			<code>Salary</code> must meet minimum wage requirements: at least <dollar-sign />21<digitsep />632 (= <dollar-sign />10.40 <times /> 40 hours per week <times /> 52 weeks per year) for those aged 16 or 17, and at least <dollar-sign />27<digitsep />040 for those 18 or older.
			
			<answer>
			
				Other<left-brace /><underline>Staff<underscore />ID</underline>, Salary<right-brace /> (foreign keys: Staff<underscore />ID <rightarrow /><space />Staff)
				
				<code-block>
CREATE TABLE Other
( Staff_ID NUMBER(4),
 -- Can't validate Salary using a CHECK constraint, as we would need to
 -- access values from the Staff table.
 Salary NUMBER(8,2) NOT NULL,
 --
 CONSTRAINT Other_PK PRIMARY KEY ( Staff_ID ),
 CONSTRAINT Other_FK_to_Staff
 FOREIGN KEY ( Staff_ID ) REFERENCES Staff ON DELETE CASCADE
);

CREATE OR REPLACE TRIGGER Validate_Other_Salary
 BEFORE INSERT OR UPDATE OF Salary ON Other
 FOR EACH ROW
DECLARE
 Minimum_Salary NUMBER;
BEGIN
 SELECT CASE WHEN ( ( SYSDATE - TO_YMINTERVAL( '18-0' ) ) &lt; Date_of_Birth )
 THEN 21632 -- these two should be constants somewhere!
 ELSE 27040
 END INTO Minimum_Salary
 FROM Staff
 WHERE Staff.Staff_ID = :NEW.Staff_ID;
 
 IF ( :NEW.Salary &lt; Minimum_Salary ) THEN
 RAISE_APPLICATION_ERROR( -20000,
 'Salary of ' || TO_CHAR( :NEW.Salary, '$999,990.00' ) ||
 ' for employee ' || :NEW.Staff_ID || 
 ' is less than their minimum salary of ' ||
 TO_CHAR( Minimum_Salary, '$999,990.00' ) );
 END IF;
END;
				</code-block>
				
				Similar to <code>Service_Staff</code> above. We also accepted <code>Other_Staff</code> as a table name.
				
			</answer>
				
			<tabular border="1" align="left">
				<tabular-columns>
					<column align="center" left-border="|" right-border="|"/>
					<column align="left" right-border="|"/>
					<column align="left" right-border="|"/>
				</tabular-columns>
				<tabular-body>
					<row>
						<cell header="yes" columns="3" align="left"><tt>Sales</tt></cell>
					</row>
					<row-rule />
					<row>
						<cell header="yes"/>
						<cell header="yes">Column</cell>
						<cell header="yes">Description</cell>
					</row>
					<row-rule/>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>On_Commission</code></cell>
						<cell>“Boolean” (i.e., effectively true/false)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Commission_Rate</code></cell>
						<cell>Percentage as a fraction, 0.00–0.30 (see below)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Total_Earnings</code></cell>
						<cell>Total earnings to date this year, <ge /><space /><dollar-sign />0.00</cell>
					</row>
					<row-rule />
				</tabular-body>
			</tabular>
			
			Some sales staff are paid on commission (up to 30<percent-sign /> of the value of each sale), while others are paid a flat rate per sale that varies depending on the type of car sold (e.g., <dollar-sign />100 for a Toyota Corolla vs.<space /><dollar-sign />500 for a BMW M3; these rates are stored in <code>Car</code>—see <hyperlink label="sec-car"><reference label="sec-car"/></hyperlink>). If the salesrep is paid on commission then <code>On_Commission</code> is true and <code>Commission_Rate</code> must be greater than zero. If the salesrep is paid on flat rate then <code>On_Commission</code> is false and <code>Commission_Rate</code> must be zero.
			
			<code>Total_Earnings</code> stores the total amount earned by a salesrep to date in the current financial year (1 April to 31 March). For salesreps who are on commission, this total is calculated from <code>Commission_Rate</code><space /><times /><space /><code>Sale.Amount</code>. For salesreps who are not on commission, the total is calculated from <code>Car.Flat_Rate</code> (via <code>Sale</code>—see <hyperlink label="sec-car"><reference label="sec-car"/></hyperlink> and <hyperlink label="sec-sale"><reference label="sec-sale"/></hyperlink>).
		
			<answer>
			
				Sales<left-brace /><underline>Staff<underscore />ID</underline>, On<underscore />Commission, Commission<underscore />Rate, Total<underscore />Earnings<right-brace /> (foreign keys: Staff<underscore />ID <rightarrow /><space />Staff)
				
				<code-block>
CREATE TABLE Sales
( Staff_ID NUMBER(4),
 On_Commission CHAR(1) DEFAULT 'N' NOT NULL
 CONSTRAINT Sales_Valid_On_Commission
 CHECK ( On_Commission IN ( 'Y', 'N' ) ),
 Commission_Rate NUMBER(3,2) NOT NULL
 CONSTRAINT Sales_Valid_Commission_Rate
 CHECK ( Commission_Rate BETWEEN 0.00 AND 0.30 ),
 Total_Earnings NUMBER(8,2) NOT NULL
 CONSTRAINT Sales_Valid_Total_Earnings
 CHECK ( Total_Earnings &gt;= 0.00 ),
 --
 CONSTRAINT Sales_Check_Commission
 CHECK ( ( ( On_Commission = 'N' ) AND ( Commission_Rate = 0 ) )
 OR ( ( On_Commission = 'Y' ) AND ( Commission_Rate &gt; 0 ) ) ),
 --
 CONSTRAINT Sales_PK PRIMARY KEY ( Staff_ID ),
 CONSTRAINT Sales_FK_to_Staff
 FOREIGN KEY ( Staff_ID ) REFERENCES Staff ON DELETE CASCADE
);
				</code-block>
				
				Similar to <code>Service_Staff</code> above. We also accepted <code>Other_Staff</code> as a table name. Note that the paragraph above about <code>Total_Earnings</code> describes the process of how it is calculated, not a constraint on its possible values, so implementing this as a constraint is incorrect.
				
			</answer>
				
		</section>

<section label="sec-customer">
		
			<title>The <tt>Customer</tt> entity</title>

CREATE TABLE Customer
( Customer_ID NUMBER(6),
 Firstname VARCHAR2(50) NOT NULL,
 Lastname VARCHAR2(50) NOT NULL,
 Address VARCHAR2(150) NOT NULL,
 Phone VARCHAR2(11) NOT NULL,
 Email VARCHAR2(50), -- optionally CHECK format if desired
 Credit_Rating CHAR(1)
 CONSTRAINT Customer_Valid_Credit_Rating
 CHECK ( Credit_Rating IN ( 'A', 'B', 'C', 'D' ) ),
 Comments CLOB,
 --
 CONSTRAINT Customer_PK PRIMARY KEY ( Customer_ID )
);
				</code-block>
				
				Many people assigned the <code>Comments</code> a size of 500 characters or less, which is far too small for a general comments column. If we assume an average word length of five characters plus one for the inter-word space, then 500 characters can only hold about 83 words! 100 characters would be only 16 words! We accepted 500 characters as a bare minimum; anything below that lost marks. A better choice would be to use either the maximum allowable VARCHAR2 size of 4000, or just use a CLOB, which for most practical purposes is effectively unlimited in size. A similar argument applies to the <code>Details</code> columns in <code>Purchase</code> and <code>Sale</code>.
				
			</answer>
				
		</section>

<section label="sec-car">
		
			<title>The <tt>Car</tt> entity</title>

<tabular border="1" align="left">
				<tabular-columns>
					<column align="center" left-border="|" right-border="|"/>
					<column align="left" right-border="|"/>
					<column align="left" right-border="|"/>
				</tabular-columns>
				<tabular-body>
					<row-rule/>
					<row>
						<cell header="yes"/>
						<cell header="yes">Column</cell>
						<cell header="yes">Description</cell>
					</row>
					<row-rule/>
					<row>
						<cell><tt><hash/></tt></cell>
						<cell><code>VIN</code></cell>
						<cell>17 character Vehicle Identification Number (VIN)</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Registration</code></cell>
						<cell>Up to 6 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Make</code></cell>
						<cell>Up to 20 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Model</code></cell>
						<cell>Up to 30 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Year</code></cell>
						<cell>Year of manufacture, no earlier than 1980</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Colour</code></cell>
						<cell>Up to 20 characters</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Odometer</code></cell>
						<cell>Current odometer reading, 0.0–999<digitsep />999.9</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>First_Registered</code></cell>
						<cell>Date the car was first registered in New Zealand</cell>
					</row>
					<row>
						<cell><tt>o</tt></cell>
						<cell><code>Last_Serviced</code></cell>
						<cell>Date the car was last serviced</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Price</code></cell>
						<cell>List price of car, whole number <ge /><space /><dollar-sign />0</cell>
					</row>
					<row>
						<cell><tt>*</tt></cell>
						<cell><code>Flat_Rate</code></cell>
						<cell>Flat rate paid to salesrep (where applicable), <gt /><space /><dollar-sign />0</cell>
					</row>
					<row-rule/>
				</tabular-body>
			</tabular>
			
			Happy Joe’s sell only modern cars, and so will not purchase anything manufactured before 1980. The value of <code>Flat_Rate</code> is determined by how frequently each particular type of car is sold (this information is not stored in the database); the “easier” it is to sell a car, the lower the value of <code>Flat_Rate</code>. All cars have a value for <code>Flat_Rate</code> because we do not know in advance whether they will be sold by a salesrep on commission or on flat rate. The value of <code>Flat_Rate</code> is independent of the sale price, which is why it is stored here rather than in <code>Sale</code>.
			
			<answer>
			
				Car<left-brace /><underline>VIN</underline>, Registration, Make, Model, Year, Colour, Odometer, First<underscore />Registered, Last<underscore />Serviced, Price, Flat<underscore />Rate<right-brace />
				
				<code-block>
CREATE TABLE Car
( VIN CHAR(17), -- optionally CHECK format if desired
 Registration VARCHAR2(6) NOT NULL,
 Make VARCHAR2(20) NOT NULL,
 Model VARCHAR2(30) NOT NULL,
 Year NUMBER(4) NOT NULL
 CONSTRAINT Car_Valid_Year CHECK ( Year &gt;= 1980 ),
 Colour VARCHAR2(20) NOT NULL,
 Odometer NUMBER(7,1) NOT NULL
 CONSTRAINT Car_Valid_Odometer 
 CHECK ( Odometer BETWEEN 0.0 AND 999999.9 ),
 First_Registered DATE NOT NULL,
 Last_Serviced DATE,
 Price NUMBER(6) NOT NULL
 CONSTRAINT Car_Valid_Price CHECK ( Price &gt;= 0 ),
 Flat_Rate NUMBER(4) NOT NULL
 CONSTRAINT Car_Valid_Flat_Rate CHECK ( Flat_Rate &gt; 0 ),
 --
 CONSTRAINT Car_PK PRIMARY KEY ( VIN )
);
				</code-block>
				
				The statement of VIN as “17 characters” was obviously a little too subtle for some people, who implemented it as NUMBER(17) rather than CHAR(17). VINs contain both numbers and letters, and the format is well-documented if you weren’t sure (e.g., look up “VIN” on Wikipedia).
				
				There was a small typo in the original specification, which said that the value of <code>Odometer</code> should be “0.0–999,999.<underline>0</underline>”, when it should actually have been 0.0–999,999.<underline>9</underline> (this has been corrected above). We accepted either when marking.
				
				There is little point in storing <code>Year</code> as a <code>DATE</code>, as we won’t be using anything but the year part anyway. Storing it as a <code>DATE</code> means that we would need to do unnecessary extra work to extract the year part from the date. If you don’t need something, don’t store it, especially if it makes things more complicated!
				
			</answer>
				
		</section>

<section label="sec-feature">
		
			<title>The <tt>Feature</tt> entity</title>

At this point we also need to add an associative entity to resolve the many-to-many relationship between Car and Feature:
				
				Car<underscore />Feature<left-brace /><underline>VIN, Feature<underscore />Code</underline><right-brace /> (foreign keys: VIN <rightarrow /><space />Car, Feature<underscore />Code <rightarrow /><space />Feature)

<code-block>
CREATE TABLE Car_Feature
( VIN VARCHAR2(17),
 Feature_Code VARCHAR2(5),
 --
 CONSTRAINT Car_Feature_PK PRIMARY KEY ( VIN, Feature_Code ),
 CONSTRAINT Car_Feature_FK_to_Car
 FOREIGN KEY ( VIN ) REFERENCES Car ON DELETE CASCADE,
 CONSTRAINT Car_Feature_FK_to_Feature
 FOREIGN KEY ( Feature_Code ) REFERENCES Feature ON DELETE CASCADE
);
				</code-block>
				
				Again, it makes sense to include <code>ON DELETE CASCADE</code> on (both!) the foreign keys, as the rows in <code>Car_Feature</code> can’t exist independently of the cars and features that they are related to.
				
			</answer>
				
		</section>

<section label="sec-warranty">
		
			<title>The <tt>Warranty</tt> entity</title>

INSERT INTO Warranty ( W_Code, Duration, Distance, Description )
 VALUES ( 'A' , 3, 5000, 'Category A motor vehicle' );
INSERT INTO Warranty ( W_Code, Duration, Distance, Description )
 VALUES ( 'B' , 2, 3000, 'Category B motor vehicle' );
INSERT INTO Warranty ( W_Code, Duration, Distance, Description )
 VALUES ( 'C' , 1, 1500, 'Category C motor vehicle' );
INSERT INTO Warranty ( W_Code, Duration, Distance, Description )
 VALUES ( 'D' , 0, 0, 'Category D motor vehicle' );
				</code-block>
				
				This is a lookup table that is intended to define the types of warranties allowed for vehicles. If the regulations change, it’s a simple matter to change the contents of the table to reflect this, which means that the table is effectively acting as a configurable constraint on warranty type. It would therefore be counterproductive to add constraints to the columns of this table based on the values specified in the Appendix, as the whole point of a lookup table is that the contents of the table effectively define a constraint. The values in the Appendix should therefore be used only to determine the data to be inserted into the table.
				
				On a similar note, there is little point in trying to enforce constraints between the specification of the warranty type and the <code>First_Registered</code> column in <code>Car</code>. There is no dedicated column in the table to store this information, so it could only be stored in <code>Description</code>, and it would probably be almost impossible in practice to extract anything useful from this column. It could be possible, however, to use a trigger to check that a car is assigned the correct warranty category for it’s odometer reading when it’s sold.
				
			</answer>
				
		</section>

<section label="sec-purchase">
		
			<title>The <tt>Purchase</tt> entity</title>

<answer>
			
				Purchase<left-brace /><underline>Purchase<underscore />ID</underline>, Purchase<underscore />Date, Details, Amount, VIN, Customer<underscore />ID, Salesrep<underscore />ID<right-brace /> (foreign keys: VIN <rightarrow /><space />Car, Customer<underscore />ID <rightarrow /><space />Customer, Salesrep<underscore />ID <rightarrow /><space />Sales)
				
				<code-block>
CREATE SEQUENCE Purchase_ID_Seq START WITH 10000000 MAXVALUE 99999999;

CREATE TABLE Purchase
( Purchase_ID NUMBER(8),
 Purchase_Date DATE NOT NULL,
 Details CLOB NOT NULL,
 Amount NUMBER(6) NOT NULL
 CONSTRAINT Purchase_Valid_Amount CHECK ( Amount &gt;= 0 ),
 VIN CHAR(17) NOT NULL,
 Customer_ID NUMBER(6) NOT NULL,
 Salesrep_ID NUMBER(4) NOT NULL,
 --
 CONSTRAINT Purchase_PK PRIMARY KEY ( Purchase_ID ),
 CONSTRAINT Purchase_FK_to_Car FOREIGN KEY ( VIN ) REFERENCES Car,
 CONSTRAINT Purchase_FK_to_Customer 
 FOREIGN KEY ( Customer_ID ) REFERENCES Customer,
 CONSTRAINT Purchase_FK_to_Sales
 FOREIGN KEY ( Salesrep_ID ) REFERENCES Sales
);
				</code-block>
				
				Note the absence of <code>ON DELETE CASCADE</code> on the foreign keys in this table. If we attempt to delete a salesrep, it makes little sense to delete all their associated purchases, especially if they are completed. This would cause a serious accounting problem for the company. A better solution might be to have a “dummy” salesrep that can have “orphaned” purchases assigned to it.
				
			</answer>
				
		</section>

<title>The <tt>Sale</tt> entity</title>

Sales are for a single car only (i.e., no bulk sales). Some sales involve the trade-in of a single car, which is effectively treated as a special type of purchase that is linked to the corresponding sale.

<answer>
			
				Sale<left-brace /><underline>Sale<underscore />ID</underline>, Sale<underscore />Date, Details, Amount, VIN, Customer<underscore />ID, Salesrep<underscore />ID, Tradein<underscore />ID<right-brace /> (foreign keys: VIN <rightarrow /><space />Car, Customer<underscore />ID <rightarrow /><space />Customer, Salesrep<underscore />ID <rightarrow /><space />Sales, W<underscore />Code <rightarrow /><space />Warranty, Tradein<underscore />ID <rightarrow /><space />Purchase)
				
				<code-block>
CREATE SEQUENCE Sale_ID_Seq START WITH 10000000 MAXVALUE 99999999;

CREATE TABLE Sale
( Sale_ID NUMBER(8),
 Sale_Date DATE NOT NULL,
 Details CLOB NOT NULL,
 Amount NUMBER(6) NOT NULL
 CONSTRAINT Sale_Valid_Amount CHECK ( Amount &gt;= 0 ),
 VIN CHAR(17) NOT NULL,
 Customer_ID NUMBER(6) NOT NULL,
 Salesrep_ID NUMBER(4) NOT NULL,
 W_Code CHAR(1) NOT NULL,
 Tradein_ID NUMBER(8),
 --
 CONSTRAINT Sale_PK PRIMARY KEY ( Sale_ID ),
 CONSTRAINT Sale_FK_to_Car FOREIGN KEY ( VIN ) REFERENCES Car,
 CONSTRAINT Sale_FK_to_Customer 
 FOREIGN KEY ( Customer_ID ) REFERENCES Customer,
 CONSTRAINT Sale_FK_to_Warranty
 FOREIGN KEY ( W_Code ) REFERENCES Warranty,
 CONSTRAINT Sale_FK_to_Sales
 FOREIGN KEY ( Salesrep_ID ) REFERENCES Sales,
 CONSTRAINT Sale_FK_to_Purchase
 FOREIGN KEY ( Tradein_ID ) REFERENCES Purchase
);
				</code-block>
				
				Similar to <code>Purchase</code> above. While the foreign key for trade-ins could go in either table (or even both), it really makes most sense to place it here, since trade-ins only occur as part of a sale transaction.
				
			</answer>
				
		</section>
		
		<newpage />
		
		
			<image basename="UsedCarWarranties" location="images" latex-options="width=\columnwidth,keepaspectratio">
				<description>Details of used car dealer warranties in New Zealand</description>
			</image>

</section>

</document>

Show line notes below