At the SQL prompt, you can begin typing any SQL command. Upon hitting return (i.e., enter key) the SQL prompt will change to line number prompts. When you are finished typing a command, type / or RUN to execute the SQL command. Also, a semicolon at the end of the SQL command will execute the command immediately after hitting return. In addition to SQL commands, /, and RUN, other commands can be issued at the SQL prompt (a semicolon does not have to follow the nonSQL commands).

• DESCRIBE tablename--lists the attributes and their specifications of tablename
• EDIT--Places you in an editor (Notepad). The buffer contents are put into the editor
• GET filename--Retrieves a file and places it into the buffer
• SAVE filename--Saves the buffer to the name file
• CLEAR BUFFER--Clears the buffer

You can use the SQL Command interface to perform updates as well as to control your transaction. The SQL Command interface allows you to enter an UPDATE statement. You can enter only one statement at a time. However, you can use one UPDATE statement to modify multiple records in a table based on a specific condition. When a condition is not specified, the entire table is updated.

Watch Sheila update rows in the EMPLOYEES table.

You may have already heard about Ruby on Rails, the new application framework that seems to be taking the Web development community, in particular J2EE and PHP programmers, by storm.

Rails is a capable Web application platform and has, in less than two years, gained significant traction among J2EE and PHP programmers. The attraction of both J2EE and PHP programmers makes a lot of sense when you look at the strengths of Rails. For one thing, it uses a strict model-view-controller architecture that any self-respecting design-patterns wonk would admire—this explains its attraction to J2EE developers. Second, it’s easy to build basic systems with Rails—which is attractive to PHP developers.

However, Rails has some pretty significant limitations from a database perspective. Rails makes a lot of assumptions about your database layout and application needs. For example, Rails assumes that all tables use a single, non-compound, primary key. Compound primary keys are not supported! In addition, Rails does not support two-phase commit; it supports multiple databases, but cannot coordinate transactions among them.

We will start with the widely used Oracle example of an employee information database. We can store all the information in a table like the one below where each row will represent an employee, and each column will represent employee attributes.

The concept of functional dependencies is the basis for the first three normal forms. A column, Y, of the relational table R is said to be functionally dependent upon column X of R if and only if each value of X in R is associated with precisely one value of Y at any given time. X and Y may be composite. Saying that column Y is functionally dependent upon X is the same as saying the values of column X identify the values of column Y. If column X is a primary key, then all columns in the relational table R must be functionally dependent upon X.

A short-hand notation for describing a functional dependency is:

R.x —>; R.y

which can be read as in the relational table named R, column x functionally determines (identifies) column y.

Full functional dependence applies to tables with composite keys. Column Y in relational table R is fully functional on X of R if it is functionally dependent on X and not functionally dependent upon any subset of X. Full functional dependence means that when a primary key is composite, made of two or more columns, then the other columns must be identified by the entire key and not just some of the columns that make up the key.