





















































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:
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:
Relations:
Entity: Album
Role: An album carries a story told by the photographs as an envelope.
Attributes:
Relations:
Entity: Film
Role: A film gathers a set of photographs.
Attributes:
Relations:
Entity: Photo
Role: The unit of our application is a photograph.
Attributes:
Relations: None
Functionally, the photoblog application will provide APIs to manipulate those entities via the traditional CRUD interface: Create, Retrieve, Update, and Delete.
Here is a list of the terms we will be using:
We will use DBMSes as the plural of DBMS.
In this section, we will quickly review the different kinds of existing DBMSes. The goal is to quickly introduce their main characteristics.
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.
|