Difference between revisions of "Module 3"

From CSE330 Wiki
Jump to: navigation, search
(Created page with 'In Module 3, you will learn about MySQL, a web application database. This article contains your assignments for Module 3. == Individual Assignments == You will create a simple…')
 
(Individual Assignments)
Line 8: Line 8:
  
 
'''IMPORTANT:''' The individual assignment is to be done by writing queries by hand.  (You can use phpMyAdmin to run the queries, but '''do not let phpMyAdmin write your queries for you!''')  Writing your own queries gives you a greater understanding of the underlying mechanisms and databases in general.  Additionally, having SQL knowledge and experience is a very marketable trait.
 
'''IMPORTANT:''' The individual assignment is to be done by writing queries by hand.  (You can use phpMyAdmin to run the queries, but '''do not let phpMyAdmin write your queries for you!''')  Writing your own queries gives you a greater understanding of the underlying mechanisms and databases in general.  Additionally, having SQL knowledge and experience is a very marketable trait.
 +
 +
=== Install MySQL and phpMyAdmin ===
 +
 +
Before you start, '''you need to install MySQL''' on your EC2 instance.  You may also install phpMyAdmin, a web frontend to MySQL, if you choose to do so.
 +
 +
You will probably find the following article to be very helpful: [[Introduction to MySQL]]
  
 
=== Set Up a Database ===
 
=== Set Up a Database ===
  
You will probably find the following article to be very helpful:
+
You will probably find the following article to be very helpful: [[Introduction to MySQL]]
 
 
* [[Introduction to MySQL]]
 
  
 
# Create a database named '''wustl'''  
 
# Create a database named '''wustl'''  
Line 19: Line 23:
  
 
=== Create Tables ===
 
=== Create Tables ===
 +
 +
You will probably find the following article to be very helpful: [[MySQL Schema and State]]
  
 
When creating tables, keep the following items in mind:
 
When creating tables, keep the following items in mind:
Line 35: Line 41:
 
# Create a table named '''departments''' with the following fields:
 
# Create a table named '''departments''' with the following fields:
 
#* '''school_code''' of type '''ENUM''' (e.g. "L" for ArtSci and "E" for Engineering).  The options are as follows:
 
#* '''school_code''' of type '''ENUM''' (e.g. "L" for ArtSci and "E" for Engineering).  The options are as follows:
#** 'L', 'B', 'A', 'F', 'E', 'T', 'I', 'W', 'S', 'U', 'M'
+
#*: 'L', 'B', 'A', 'F', 'E', 'T', 'I', 'W', 'S', 'U', 'M'
 
#* '''dept_id''' of an appropriately-sized unsigned integer type (in the foreseeable future there will never be more than 200 departments in a school)
 
#* '''dept_id''' of an appropriately-sized unsigned integer type (in the foreseeable future there will never be more than 200 departments in a school)
 
#* '''abbreviation''' of type '''VARCHAR(9)''' (e.g. CSE, ChemE, etc)
 
#* '''abbreviation''' of type '''VARCHAR(9)''' (e.g. CSE, ChemE, etc)
Line 41: Line 47:
 
#: The primary key should be on two fields: '''school_code''' and '''dept_id'''
 
#: The primary key should be on two fields: '''school_code''' and '''dept_id'''
 
#: '''Note:''' Why not just use the department ID? The ID numbers are sometimes reused across schools. For instance, department 33 in The School of Arts and Sciences is Psychology while department 33 in The School of Engineering and Applied Sciences is Energy, Environmental and Chemical Engineering. Thus we must also include the school code to differentiate them  such that the record for  E33 is distinct from that of L33.
 
#: '''Note:''' Why not just use the department ID? The ID numbers are sometimes reused across schools. For instance, department 33 in The School of Arts and Sciences is Psychology while department 33 in The School of Engineering and Applied Sciences is Energy, Environmental and Chemical Engineering. Thus we must also include the school code to differentiate them  such that the record for  E33 is distinct from that of L33.
 +
# Create a table named '''courses''' with the following fields:
 +
#* '''school_code''' of type '''ENUM'''
 +
#*: This should have the same letters in the same order as the '''school_code''' '''ENUM''' field in the '''departments''' table.
 +
#* '''dept_id''' of the same size of integer as in the '''departments''' table
 +
#* '''course_code''' of type '''CHAR(5)''' (this will hold course codes; e.g., '330S', '131', '2960')
 +
#* '''name''' of type '''VARCHAR(150)'''
 +
#: The appropriate fields in this table should make a foreign key reference to the corresponding fields in '''department'''.
 +
#: In addition, it is up to you to determine the field(s) for the primary key.
 +
#: '''Note:''' If you are unsure which fields to make the foreign keys and feel the need to beg your friends or the TAs to give you the answer, bang your head on your desk whilst repeating "I WILL EXERCISE REASON AND COMMON SENSE AND I WILL CURTAIL MY DESIRE TO BLINDLY FOLLOW DIRECTIONS"
 +
#: ''Disclaimer: don't actually bang your head on your desk, the resulting head trauma may in fact make it harder for you to determine which fields should have associated foreign keys.''
 +
# Create a table named '''grades''' with the following fields:
 +
#* '''pk_grade_ID''' of an appropriately-sized unsigned integer type (should be larger than the one you chose for the '''students''' table)
 +
#*: You should declare this field to be '''auto_increment'''
 +
#*: This is called a ''surrogate key'' as opposed to a ''natural key'' because it doesn't arise "naturally" from the data; that is to say that it is not derived from application data. The use of surrogate keys vs. natural keys is a polemic issue amongst database designers.  For a decently unbiased take on the issue, see this page: http://www.agiledata.org/essays/keys.html#Comparison
 +
#*: '''Food for thought:''' Aside from simply exposing you to the concept, can you think of any reasons why a surrogate key might be preferable for this table?  Alternatively, what attributes, if any, could you use as a natural key, and what might be the drawbacks of doing so?
 +
#* '''student_id''' of the same integer (unsigned) type that you chose in the '''students''' table
 +
#* '''grade''' of type '''decimal'''
 +
#* '''school_code''' of type '''ENUM'''
 +
#*: Can you guess what entries to use for the enum?
 +
#* '''dept_id''' of the same integer type that you've used for this field in other tables
 +
#* '''course_code''' of the same type you chose for the course code in the '''courses''' table
  
 
== Group Project ==
 
== Group Project ==

Revision as of 22:45, 26 August 2012

In Module 3, you will learn about MySQL, a web application database.

This article contains your assignments for Module 3.

Individual Assignments

You will create a simple grades database containing four tables.

IMPORTANT: The individual assignment is to be done by writing queries by hand. (You can use phpMyAdmin to run the queries, but do not let phpMyAdmin write your queries for you!) Writing your own queries gives you a greater understanding of the underlying mechanisms and databases in general. Additionally, having SQL knowledge and experience is a very marketable trait.

Install MySQL and phpMyAdmin

Before you start, you need to install MySQL on your EC2 instance. You may also install phpMyAdmin, a web frontend to MySQL, if you choose to do so.

You will probably find the following article to be very helpful: Introduction to MySQL

Set Up a Database

You will probably find the following article to be very helpful: Introduction to MySQL

  1. Create a database named wustl
  2. Create a user named wustl_inst and give them the password wustl_pass

Create Tables

You will probably find the following article to be very helpful: MySQL Schema and State

When creating tables, keep the following items in mind:

  • You should create all tables such that they use the InnoDB storage engine, since we wish to make use of its support of foreign keys. In other database engines, foreign key constraints are not enforced. (If you mess up, you can use ALTER TABLE to change the storage engine.)
  • Where it is appropriate, you should take advantage of the ability to define fields NOT NULL so that you do not inadvertently insert incomplete data for a row.

Create the following tables:

  1. Create a table named students with the following fields:
    • id of an appropriately-sized unsigned integer type (we will never need to process more than a million students)
    • first_name of type VARCHAR(50)
    • last_name of type VARCHAR(50)
    • email_address of type VARCHAR(50)
    The primary key should be on the id field.
  2. Create a table named departments with the following fields:
    • school_code of type ENUM (e.g. "L" for ArtSci and "E" for Engineering). The options are as follows:
      'L', 'B', 'A', 'F', 'E', 'T', 'I', 'W', 'S', 'U', 'M'
    • dept_id of an appropriately-sized unsigned integer type (in the foreseeable future there will never be more than 200 departments in a school)
    • abbreviation of type VARCHAR(9) (e.g. CSE, ChemE, etc)
    • dept_name of type VARCHAR(200) (e.g. Computer Science and Engineering)
    The primary key should be on two fields: school_code and dept_id
    Note: Why not just use the department ID? The ID numbers are sometimes reused across schools. For instance, department 33 in The School of Arts and Sciences is Psychology while department 33 in The School of Engineering and Applied Sciences is Energy, Environmental and Chemical Engineering. Thus we must also include the school code to differentiate them such that the record for E33 is distinct from that of L33.
  3. Create a table named courses with the following fields:
    • school_code of type ENUM
      This should have the same letters in the same order as the school_code ENUM field in the departments table.
    • dept_id of the same size of integer as in the departments table
    • course_code of type CHAR(5) (this will hold course codes; e.g., '330S', '131', '2960')
    • name of type VARCHAR(150)
    The appropriate fields in this table should make a foreign key reference to the corresponding fields in department.
    In addition, it is up to you to determine the field(s) for the primary key.
    Note: If you are unsure which fields to make the foreign keys and feel the need to beg your friends or the TAs to give you the answer, bang your head on your desk whilst repeating "I WILL EXERCISE REASON AND COMMON SENSE AND I WILL CURTAIL MY DESIRE TO BLINDLY FOLLOW DIRECTIONS"
    Disclaimer: don't actually bang your head on your desk, the resulting head trauma may in fact make it harder for you to determine which fields should have associated foreign keys.
  4. Create a table named grades with the following fields:
    • pk_grade_ID of an appropriately-sized unsigned integer type (should be larger than the one you chose for the students table)
      You should declare this field to be auto_increment
      This is called a surrogate key as opposed to a natural key because it doesn't arise "naturally" from the data; that is to say that it is not derived from application data. The use of surrogate keys vs. natural keys is a polemic issue amongst database designers. For a decently unbiased take on the issue, see this page: http://www.agiledata.org/essays/keys.html#Comparison
      Food for thought: Aside from simply exposing you to the concept, can you think of any reasons why a surrogate key might be preferable for this table? Alternatively, what attributes, if any, could you use as a natural key, and what might be the drawbacks of doing so?
    • student_id of the same integer (unsigned) type that you chose in the students table
    • grade of type decimal
    • school_code of type ENUM
      Can you guess what entries to use for the enum?
    • dept_id of the same integer type that you've used for this field in other tables
    • course_code of the same type you chose for the course code in the courses table

Group Project

You will work in pairs on this project.

Important Reminder: frequently commit your work to your subversion repository as a backup!


Web Security

Your project needs to demonstrate that thought was put into web security. For more information, see this week's Web Application Security guide: Web Application Security, Part 2


Grading

Due Date: _____ (both individual and group)

Assignment Points
Birthday Card 2
Group Portion:
Multi-User Login 1