A photoblog is like a regular blog except that the principal content is not text but photographs. The main reason for choosing a photoblog is that the range of features to be implemented is small enough so that we can concentrate on their design and implementation.

The goals behind going through this application are as follows:

• To see how to slice the development of a web application into meaningful layers and therefore show that a web application is not very different from a rich application sitting on your desktop.
• To show that the separation of concerns can also be applied to the web interface itself by using principles grouped under the name of Ajax.
• To introduce common Python packages for dealing with common aspects of web development such as database access, HTML templating, JavaScript handling, etc.

Photoblog Entities

As mentioned earlier, the photoblog will try to stay as simple as possible in order to focus on the other aspects of developing a web application. In this section, we will briefly describe the entities our photoblog will manipulate as well as their attributes and relations with each other.

In a nutshell our photoblog application will use the following entities and they will be associated as shown in the following figure:

This figure is not what our application will look like but it shows the entities our application will manipulate. One photoblog will contain several albums, which in turn will host as many films as required, which will carry the photographs.

In other words, we will design our application with the following entity structure:

Entity: Photoblog

Role: This entity will be the root of the application.

Attributes:

• name: A unique identifier for the blog
• title: A public label for the blog

Relations:

• One photoblog will have zero to many albums

Entity: Album

Role: An album carries a story told by the photographs as an envelope.

Attributes:

• name: A unique identifier for the album
• title: A public label for the album
• author: The name of the album’s author
• description: A simple description of the album used in feeds
• story: A story attached to the album
• created: A timestamp of when the album is being created
• modified: A timestamp of when the album is being modified
• blog_id: A reference to the blog handling the album

Relations:

• One album will reference zero to several films

Entity: Film

Role: A film gathers a set of photographs.

Attributes:

• name: A unique identifier for the film
• title: A public label for the film
• created: A timestamp of when the film is being created
• modified: A timestamp of when the film is being modified
• album_id: A reference to the album

Relations:

• A film will reference zero to several photographs

Entity: Photo

Role: The unit of our application is a photograph.

Attributes:

• name: A unique identifier for the photo
• legend: A legend associated with the photograph
• filename: The base name of the photograph on the hard-disk
• filesize: The size in bytes of the photograph
• width: Width of the photograph in pixels
• height: Height of the photograph in pixels
• created: A timestamp of when the photograph is being created
• modified: A timestamp of when the photograph is being modified
• film_id: A reference to the film carrying the photograph

Relations: None

Functionally, the photoblog application will provide APIs to manipulate those entities via the traditional CRUD interface: Create, Retrieve, Update, and Delete.

Vocabulary

Here is a list of the terms we will be using:

• Persistence: Persistence is the concept of data items outliving the execution of programs manipulating them. Simply put, it is the process of storing data in long lasting memory medium such as a disk.
• Database: A database is a collection of organized data. There are different organization models: hierarchical, network, relational, object-oriented, etc. A database holds the logical representation of its data.
• Database Management System (DBMS): A DBMS is a group of related software applications to manipulate data in a database. A DBMS platform should offer the following among other features:
  • Persistence of the data
  • A query language to manipulate data
  • Concurrency control
  • Security control
  • Integrity control
  • Transaction capabilities

We will use DBMSes as the plural of DBMS.

DBMSes Overview

In this section, we will quickly review the different kinds of existing DBMSes. The goal is to quickly introduce their main characteristics.

Relational Database Management System (RDBMS)

Of all DBMSes, the RDBMS is the most common, whether it is in small applications or multi-national infrastructure. An RDBMS comes with a database based on the concepts of the relational model, a mathematical model that permits the logical representation of a collection of data through relations. A relational database should be a concrete implementation of the relational model. However, modern relational databases follow the model only to a certain degree.

The following table shows the correlation between the terms of the relational model and the relational database implementation.

Relational databases support a set of types to define the domain of scope a column can use. However, there are only a limited number of supported types, which can be an issue with complex data types as allowed in objected-oriented design.

Structure Query Language more commonly known as SQL is the language used to define, manipulate, or control data within a relational database.

The following table is a quick summary of SQL keywords and their contexts.

A construction of these keywords is called an SQL statement. When executed, an SQL statement returns a collection of rows of the data matching the query or nothing.

The relational model algebra uses the relation composition to compose operations across different sets; this is translated in the relational database context by joins. Joining tables allows complex queries to be shaped to filter out data.

SQL provides the following three kinds of joins:

 

Union Type	Description
INNER JOIN	Intersection between two tables.
LEFT OUTER JOIN	Limits the result set by the left table. So all results from the left table will be returned with their matching result in the right table. If no matching result is found, it will return a NULL value.
RIGHT OUTER JOIN	Same as the LEFT OUTER JOIN except that the tables are reversed.