Web Application Architectures

Module 3: Database Interactions Lecture 1: Relational Databases

c 2011-13 G.L. Heileman

Module 3, Lecture 1

1/9

Focus of our Attention

Script/ Service Web Client (Browser) 1: request Network 2: response

Connector Database

Web Server

Script/ Service Script/ Service

Connector Database

Client tier

Web tier

Presentation logic tier

Business logic tier

Data access tier

Data tier

c 2011-13 G.L. Heileman

Module 3, Lecture 1

2/9

Relational Databases
Relational databases are the most common way to persistently store data in web applications. A relational database is used to store a collection of relations. This involves storing records in tables. Each row in a table (or entity) corresponds to one record, and the columns correspond to elds (or attributes) of the record. Ex.
people id first_name Frank 1 2 John Jane 3 4 John last_name Furter Doe Doe Doe address 1 Wiener Way 30 Smith PL 30 Smith PL 30 Smith PL phone 212-555-1234 505-555-1234 505-463-4321 505-463-1234

c 2011-13 G.L. Heileman

Module 3, Lecture 1

3/9

Relational Databases
Whats the point of the id eld in the previous table? It is used to form relationships to other tables. Its referred to as the primary key of the table. For example, John Doe appeared in the previous table twice. Why? Because he has two phones. More specically, there is a one-to-many relationship between people and phones one person can have many phones. We can normalize the database by creating two tables, one for people and a separate table for phones:
Each record in the phone table will hold the id of a person. In the phone table, this person_id is referred to as a foreign key. Given the id of a person, we can now search the phone table for all of the phones that belong to a person. This is typically done using the structured query language (SQL), but in Rails well by-pass this using the methods provided with Active Records.

c 2011-13 G.L. Heileman

Module 3, Lecture 1

4/9

Relational Databases Normalization

Ex. A one-to-many relationship between tables:
people id first_name Frank 1 2 John Jane 3 last_name Furter Doe Doe address 1 Wiener Way 30 Smith PL 30 Smith PL

phones id person_id 1 2 3 4 1 2 3 2

number 212-555-1234 505-555-1234 505-463-4321 505-463-1234

c 2011-13 G.L. Heileman

Module 3, Lecture 1

5/9

Schema and Entity-Relationship Models

The structure/organization of the tables in a database is referred to as a schema. An entity-relationship model is a common way of abstractly capturing a database schema.

c 2011-13 G.L. Heileman

Module 3, Lecture 1

6/9

Relational Databases
Notice that we could further normalize the database by creating an address table. However, in this case, the one-to-many relationship is in the other direction, i.e., we have one address for many people in the table. You can imagine a situation where one person also has many addresses, e.g., one for work, one for home, etc. Thus, we really need to create a many-to-many relationship between people and addresses. This is done by creating a join table its called this because it joins the people and addresses tables. The join table in the following example is called addresses_people. Notice that it only stores foreign keys, and has no primary keys.

c 2011-13 G.L. Heileman

Module 3, Lecture 1

7/9

Relational Databases Join Tables

Ex. A many-to-many relationship using a join table:
people id first_name Frank 1 2 John Jane 3 last_name Furter Doe Doe addresses_people person_id address_id 1 2 3 1 2 2

phones id person_id 1 2 3 4 1 2 3 2

number 212-555-1234 505-555-1234 505-463-4321 505-463-1234

addresses id street 1 2 1 Wiener Way 30 Smith PL

city Ketchup Bland

state OR NE

c 2011-13 G.L. Heileman

Module 3, Lecture 1

8/9

Entity-Relationship Model

c 2011-13 G.L. Heileman

Module 3, Lecture 1

9/9

Web Application Architectures

Module 3: Database Interactions Lecture 2: Databases in Rails

c 2011-13 G.L. Heileman

Module 3, Lecture 2

1/5

Focus of our Attention

Script/ Service Web Client (Browser) 1: request Network 2: response

Connector Database

Web Server

Script/ Service Script/ Service

Connector Database

Client tier

Web tier

Presentation logic tier

Business logic tier

Data access tier

Data tier

c 2011-13 G.L. Heileman

Module 3, Lecture 2

2/5

Database Migrations
Each time we ran the scaold generator in our blog application, Rails created a database migration le and placed it in the db/migrate directory. Rails uses the rake command to run these migrations, which creates a schema, from which appropriate databases can then be created. Because migrations can also be used to undo the work of previous migrations (e.g., to make corrections), they are timestamped, and executed in the order they were created. The lename contains the timestamp.

c 2011-13 G.L. Heileman

Module 3, Lecture 2

3/5

Rails Environments
Rails automatically sets up applications to run in one of three prebuilt environments (you can also add your own):
Development Used when youre developing the application. Test Used when your run tests. Production Used when you deploy your application.

By default, when you run: $ rails server Rails runs in the development environment. To force rails to run in a dierent environment, use: $ rails server -e production

c 2011-13 G.L. Heileman

Module 3, Lecture 2

4/5

Rails Databases
One of the architectural elements most likely to dier between development and production environments is the database: During development, you (the developer) are the only one accessing the database. Rails automatically sets up the development environment to use SQLite, a simple easy-to-use le-based relational database that runs in memory. SQLite is not a production grade database. When an application goes into production, it may receive 100s or 1000s of hits in a matter of seconds, and the database needs be able to handle the data requests associated with these hits. Popular production database include: PostgreSQL and MySQL. The databases that Rails will use in dierent environments is specied in: db/database.yml.
c 2011-13 G.L. Heileman Module 3, Lecture 2 5/5

Web Application Architectures

Module 3: Database Interactions Lecture 3: The Active Record Design Pattern

c 2011-13 G.L. Heileman

Module 3, Lecture 3

1/9

Focus of our Attention

Script/ Service Web Client (Browser) 1: request Network 2: response

Connector Database

Web Server

Script/ Service Script/ Service

Connector Database

Client tier

Web tier

Presentation logic tier

Business logic tier

Data access tier

Data tier

c 2011-13 G.L. Heileman

Module 3, Lecture 3

2/9

Active Record Design Pattern

The Active Record design pattern was named by Martin Fowler in 2003 in his book Patterns of Enterprise Application Architecture. Active Records are commonly used in Ruby as a means of persisting data, i.e., of saving data persistently, so that it can be recalled for later use, even after youve closed the program that created the data, and turned o your computer. More specically, the Active Record pattern is used to access data stored in relational databases it allows you to perform CRUD operations without worrying about the specic underlying database technology (e.g., SQLite, MySQL, PostgreSQL, SQL Server, Oracle, etc).

c 2011-13 G.L. Heileman

Module 3, Lecture 3

3/9

Active Record Design Pattern

Most software applications today are written using some OO language, and often it is necessary to persist (i.e., save and later retrieve) the objects associated with these applications. Theres a big problem: The classes and objects associated with an OO language are incompatible with the structure of relational databases. Active Records to the Rescue: This design pattern encapsulates that notion an object-relational mapping (ORM), i.e., a mapping between OO language constructs and relational databases constructs. The ORM provided by Active Records automatically converts object into constructs that can be stored in a database (and converts them back upon retrieval). This creates, in eect, a virtual object database that can be used from within an OO language.

c 2011-13 G.L. Heileman

Module 3, Lecture 3

4/9

ORM How Its Done

Active Records use the following ORM: OO Language Feature Classes Objects Relations DB Item Tables Records (Rows in a Table) Record Values (Columns in a Table)

Attributes

c 2011-13 G.L. Heileman

Module 3, Lecture 3

5/9

Active Records in Ruby

The Active Record design pattern is provided in a Ruby module called ActiveRecord. Using the functionality provided by this module you can:
Establish a connection to a database. Create database tables. Specify associations between tables that correspond to associations between the Ruby classes. Establish an ORM between Ruby classes/objects/attributes and the tables/rows/columns in the underlying database. Peform CRUD operations on Ruby ActiveRecord objects.

The ActiveRecord module is built into Rails the functionalities above are utilized when you create a Rails app and run scaold and model generators.
c 2011-13 G.L. Heileman Module 3, Lecture 3 6/9

Active Records in Rails

The ActiveRecord::Base.establish_connection method uses the information in ./conifg/database.yml in order to connect a Rails application to a database. The ActiveRecord::Migration object is used to incrementally evolve your database schema over time migrations update the ./db/schema.rb le. The ActiveRecord::Schema.define method, in ./db/schema.rb, is created by inspecting the database and then expressing its structure programmatically using a portable (database-independent) DSL. This can be loaded into any database that ActiveRecord supports.

c 2011-13 G.L. Heileman

Module 3, Lecture 3

7/9

ActiveRecord Module
If you create a new class by inheriting ActiveRecord::Base, and call it Post, it is assumed a database table will exist that is called posts. I.e., it pluaralizes the name of the class, and then looks for a table with that name. The Base class in the ActiveRecord module will inspect the posts database, and determine that it has title and body elds, and it will automatically add member variables (and accessors) with these same names in the Post class. I.e., it takes care of the ORM! Furthermore, a query interface is also provided in most cases, ActiveRecord insulates you from the need to use SQL. Post.all Ex. Post.first Post.find_by(1) Post.find_by_title("My First Post")
c 2011-13 G.L. Heileman Module 3, Lecture 3 8/9

The Interactive Ruby Shell

The interactive Ruby shell (IRB) is an interpreter that is provided with Ruby, and allows for real-time experimentation through interactive sessions great for debugging. To use it, in a terminal window type: $ irb The Rails console allows you to interact with a Rails application through the IRB command line i.e., it starts IRB and loads the Rails environment. To use it, from the root of a Rails application directory type: $ rails console

c 2011-13 G.L. Heileman

Module 3, Lecture 3

9/9

Web Application Architectures

Module 3: Database Interactions Lecture 4: The Blog App Iteration 2 (Associations)

c 2011-13 G.L. Heileman

Module 3, Lecture 4

1/4

Associations in Rails
Because we used the scaold generator for the posts and comments in our blog application, the Active Record design pattern is pre-wired. This means: A SQLite database able to store posts and comments was created when we ran the migrations. A connection to this database was established. The ORM for Post and Comment objects was set up the M in MVC. However, theres one thing missing we need to ensure that any comments entered for a particular post are permanently linked to that post.

c 2011-13 G.L. Heileman

Module 3, Lecture 4

2/4

Associations in Rails
We did make the connection between posts and comments in the database recall that a post_id can be stored with each comment. To make our models in Rails fully functional we need to add associations each post needs to know the list of comments associated with it, and each comment needs to know which post it belongs to. Theres a many-to-one relationship between comments and posts a post has many comments, and a comment belongs to a post:

c 2011-13 G.L. Heileman

Module 3, Lecture 4

3/4

Associations in Rails
The ActiveRecord module contains a set of class methods for tying objects together through foreign keys. To enable these, you must declare associations within your models using the following: Relationship one-to-one many-to-one many-to-many Model with no foreign key has_one has_many has_and_belongs_to_many Model with foreign key belongs_to belongs_to

The foreign keys for each model are stored in a join table.

c 2011-13 G.L. Heileman

Module 3, Lecture 4

4/4

Web Application Architectures

Module 3: Database Interactions Lecture 5: The Blog App Iteration 3 (Validations)

c 2011-13 G.L. Heileman

Module 3, Lecture 5

1/6

Data Validations in Web Apps

Data validation is the process of ensuring your web application operates on clean, correct and useful data. Ex.
Ensure a user provides a valid email address, phone number, etc. Ensure that inputs (505) 255-1234, 505-255-1234 and 5052551234 are all treated the same. Ensure that business rules are not being violated, e.g., a comment cannot be stored without a post ID.

The most common web application security weakness is failure to validate client-side input SQL injection, cross-site scripting and buer overow attacks are enabled.

c 2011-13 G.L. Heileman

Module 3, Lecture 5

2/6

Data Validations in Web Apps

Script/ Service Web Client (Browser) 1: request Network 2: response
Connector Database

Web Server

Script/ Service Script/ Service

Connector Database

JavaScript HTML5

Controller-level Model-level

Databasestored procedure

c 2011-13 G.L. Heileman

Module 3, Lecture 5

3/6

Data Validations in Web Apps

Client-side Involves checking that HTML forms are lled out correctly. JavaScript, running in the browser, has traditionally been used. HTML5 now has more specic input types that can be checked, along with a required attribute. Works best when combined with server-side validations. Server-side Checks made after an HTML form has been submitted. Database (stored procedures) Database-dependent, so not portable. Useful if many applications are using the database. Controller-level Well see later that you dont want to put too much logic in the controller (keep them skinny). Model-level A good way to ensure that only valid data is stored in your database, in a database agnostic way.

c 2011-13 G.L. Heileman

Module 3, Lecture 5

4/6

ActiveRecord Callbacks
We can think of the objects in an OO system as having a lifecycle they are rst created, can later be updated and also destroyed. ActiveRecord objects have methods that can be called in order to ensure their integrity at the various stages of their lifecycle. Ex.
Dont create a new user object if the user already exists in the database. Ensure that all of an objects attributes are valid before allowing it to be saved to the database. When destroying an object, destroy all of the objects that depend on it.

Callbacks are methods that get called at certain points in an ActiveRecord objects lifecycle they are hooks into the lifecycle, allowing you to trigger logic before or after the state of an object changes.
c 2011-13 G.L. Heileman Module 3, Lecture 5 5/6

ActiveRecord Validations
Validations are a type of ActiveRecord callback that can be used to ensure only valid data is stored in your Rails databases. The create, save and update methods trigger validations, and will only allow a valid ActiveRecord object to be saved to the database. Validations are dened in your models. Ex.
class Person < ActiveRecord::Base validates_presence_of :name validates_numericality_of :age, :only_integer => true validates_ confirmation_of :email validates_length_of :password, :in => 8..20 end

c 2011-13 G.L. Heileman

Module 3, Lecture 5

6/6

Web Application Architectures

Module 3: Database Interactions Module Overview

c 2011-13 G.L. Heileman

Module 3: Overview

1/2

Module Overview
Relational Databases Databases in Rails The Active Record Design Pattern The Blog App Iteration 2 (Associations) The Blog App Iteration 3 (Validations)

c 2011-13 G.L. Heileman

Module 3: Overview

2/2