Learning PostgreSQL

Chapter 1. Relational Databases

This chapter will provide a high-level overview of topics related to database development. Understanding the basic relational database concepts enables the developers to not only come up with clean designs, but also to master relational databases. This chapter is not restricted to learning PostgreSQL, but covers all relational databases.

The topics covered in this chapter include the following:

Database management systems: Understanding the different database categories enables the developer to utilize the best in each world.
Relational algebra: Understanding relational algebra enables the developers to master the SQL language, especially, SQL code rewriting.
Data modeling: Using data modeling techniques leads to better communication.

Database management systems

Different database management systems support diverse application scenarios, use cases, and requirements. Database management systems have a long history. First we will quickly take a look at the recent history, and then explore the market-dominant database management system categories.

A brief history

Broadly, the term database can be used to present a collection of things. Moreover, this term brings to mind many other terms including data, information, data structure, and management. A database can be defined as a collection or a repository of data, which has a certain structure, managed by a database management system (DBMS). Data can be structured as tabular data, semi-structured as XML documents, or unstructured data that does not fit a predefined data model.

In early days, databases were mainly aimed at supporting business applications; this led us to the well-defined relational algebra and relational database systems. With the introduction of object-oriented languages, new paradigms of database management systems appeared such as object-relational databases and object-oriented databases. Also, many businesses as well as scientific applications use arrays, images, and spatial data; thus, new models such as raster, map, and array algebra are supported. Graph databases are used to support graph queries such as the shortest path from one node to another along with supporting traversal queries easily.

With the advent of web applications such as social portals, it is now necessary to support a huge number of requests in a distributed manner. This has led to another new paradigm of databases called NoSQL (Not Only SQL) which has different requirements such as performance over fault tolerance and horizontal scaling capabilities.

In general, the timeline of database evolution was greatly affected by many factors such as:

Functional requirements: The nature of the applications using a DBMS has led to the development of extensions on top of relational databases such as PostGIS (for spatial data) or even dedicated DBMS such as SCI-DB (for scientific data analytics).
Nonfunctional requirements: The success of object-oriented programming languages has created new trends such as object-oriented databases. Object relational database management systems have appeared to bridge the gap between relational databases and the object-oriented programming languages. Data explosion and the necessity to handle terabytes of data on commodity hardware have led to columnar databases, which can easily scale up horizontally.

Database categories

Many database models have appeared and vanished such as the network model and hierarchal model. The predominant categories now in the market are relational, object-relational databases, and NoSQL databases. One should not think of NoSQL and SQL databases as rivals; they are complementary to each other. By utilizing different database systems, one can overcome many limitations, and get the best of different technologies.

The NoSQL databases

The NoSQL databases are affected by the CAP theorem, also known as Brewer's theorem. In 2002, S. Gilbert and N. Lynch published a formal proof of the CAP theorem in their article: "Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services". In 2009, the NoSQL movement began. Currently, there are over 150 NoSQL databases (nosql-database.org).

The CAP theorem

The CAP theorem states that it is impossible for a distributed computing system to simultaneously provide all three of the following guarantees:

Consistency: All clients see (immediately) the latest data even in the case of updates.
Availability: All clients can find a replica of some data even in the case of a node failure. That means even if some part of the system goes down, the clients can still access the data.
Partition tolerance: The system continues to work regardless of arbitrary message loss or failure of part of the system.

The choice of which feature to discard determines the nature of the system. For example, one could sacrifice consistency to get a scalable, simple, and high-performance database management system.

Often, the main difference between a relational database and a NoSQL database is consistency. A relational database enforces ACID. ACID is the acronym for the following properties: Atomicity, Consistency, Isolation, and Durability. In contrast, many NoSQL databases adopt the basically available soft-state, eventual-consistency (BASE) model.

NoSQL motivation

A NoSQL database provides a means for data storage, manipulation, and retrieval for non-relational data. The NoSQL databases are distributed, open source and horizontally scalable. NoSQL often adopts the BASE model, which prizes availability over consistency, and informally guarantees that if no new updates are made on a data item, eventually all access to that data item will return the latest version of that data item. The advantages of this approach include the following:

Simplicity of design
Horizontal scaling and easy replication
Schema free
Huge amount of data support

We will now explore a few types of NoSQL databases.

Key value databases

The key value store is the simplest database store. In this database model, the storage, as its name suggests, is based on maps or hash tables. Some key-value databases allow complex values to be stored as lists and hash tables. Key-value pairs are extremely fast for certain scenarios, but lack the support for complex queries and aggregation. Some of the existing open source key-value databases are Riak, Redis, Memebase, and MemcacheDB.

Columnar databases

Columnar or column-oriented databases are based on columns. Data in a certain column in a two dimensional relation is stored together. Unlike relational databases, adding columns is inexpensive, and is done on a row-by-row basis. Rows can have a different set of columns. Tables can benefit from this structure by eliminating the storage cost of the null values. This model is best suited for distributed databases. HBase is one of the most famous columnar databases. It is based on the Google big table storage system. Column-oriented databases are designed for huge data scenarios, so they scale up easily. For small datasets, HBase is not a suitable architecture. First, the recommended hardware topology for HBase is a five-node or server deployment. Also, it needs a lot of administration, and is difficult to master and learn.

Document databases

A document-oriented database is suitable for documents and semi-structured data. The central concept of a document-oriented database is the notion of a document. Documents encapsulate and encode data (or information) in some standard formats or encodings such as XML, JSON, and BSON. Documents do not adhere to a standard schema or have the same structure; so, they provide a high degree of flexibility. Unlike relational databases, changing the structure of the document is simple, and does not lock the clients from accessing the data.

Document databases merge the power of relational databases and column-oriented databases. They provide support for ad-hoc queries, and can be scaled up easily. Depending on the design of the document database, MongoDB is designed to handle a huge amount of data efficiently. On the other hand, CouchDB provides high availability even in the case of hardware failure.

Graph databases

Graph databases are based on the graph theory, where a database consists of nodes and edges. The nodes as well as the edges can be assigned data. Graph databases allow traversing between the nodes using edges. Since a graph is a generic data structure, graph databases are capable of representing different data. A famous implementation of an open source commercially supported graph databases is Neo4j.

Relational and object relational databases

Relational database management systems are one of the most-used DBMSs in the world. It is highly unlikely that any organization, institution, or personal computer today does not have or use a piece of software that does not rely on RBDMS. Software applications can use relational databases via dedicated database servers or via lightweight RDBMS engines, embedded in the software applications as shared libraries.

The capabilities of a relational database management system vary from one vendor to another, but most of them adhere to the ANSI SQL standards. A relational database is formally described by relational algebra, and is modeled on the relational model. Object-relational database (ORD) are similar to relational databases. They support object-oriented model concepts such as:

User defined and complex data types
Inheritance

ACID properties

In a relational database, a single logical operation is called a transaction. The technical translation of a transaction is a set of database operations, which are create, read, update, and delete (CRUD). The simplest example for explaining a transaction is money transfer from one bank account to another, which normally involves debiting one account and crediting another. The ACID properties in this context could be described as follows:

Atomicity: All or nothing, which means that if a part of a transaction fails, then the transaction fails as a whole.
Consistency: Any transaction gets the database from one valid state to another valid state. Database consistency is governed normally by data constraints and the relation between data and any combination thereof. For example, imagine if one would like to completely purge his account on a shopping service. In order to purge his account, his account details, such as list of addresses, will also need to be purged. This is governed by foreign key constraints, which will be explained in detail in the next chapter.
Isolation: Concurrent execution of transactions results in a system state that would be obtained if the transactions were executed serially.
Durability: The transactions which are committed, that is executed successfully, are persistent even with power loss or some server crashes. This is done normally by a technique called write-ahead log (WAL).

The SQL Language

Relational databases are often linked to the Structured Query Language (SQL). SQL is a declarative programming language, and is the standard relational database language. American National Standard Institute (ANSI) and International standard organization (ISO) published the SQL standard for the first time in 1986, followed by many versions such as SQL:1999, SQL:2003, SQL:2006, SQL:2008, and so on.

The SQL language has several parts:

Data definition language (DDL): It defines and amends the relational structure.
Data manipulation language (DML): It retrieves and extracts information from the relations.
Data control language (DCL): It controls the access rights to relations.

Basic concepts

A relational model is a first-order predicate logic, which was first introduced by Edgar F. Codd. A database is represented as a collection of relations. The state of the whole database is defined by the state of all the relations in the database. Different information can be extracted from the relations by joining and aggregating data from different relations, and by applying filters on the data.

In this section, the basic concepts of the relational model are introduced using the top-down approach by first describing the relation, tuple, attribute, and domain.

Note

The terms relation, tuple, attribute, and unknown, which are used in the formal relational model, are equivalent to table, row, column, and null in the SQL language.

Relation

Think of a relation as a table with a header, columns, and rows. The table name and the header help in interpreting the data in the rows. Each row represents a group of related data, which points to a certain object.

A relation is represented by a set of tuples. Tuples should have the same set of ordered attributes. Attributes have a domain, that is, a type and a name.

Customer relation
	`customer_id`	`first_name`	`last_name`	`Email`	`Phone`
Tuple →	`1`	`Thomas`	`Baumann`		`6622347`
Tuple →	`2`	`Wang`	`Kim`	`kim@wang_kim.com`	`6622345`
Tuple →	`3`	`Christian`	`Bayer`		`6622919`
Tuple →	`4`	`Ali`	`Ahmad`		`3322123`
	↑ Attribute	↑ Attribute	↑ Attribute	↑ Attribute	↑ Attribute

The relation schema is denoted by the relation name and the relation attributes. For example, customer (customer_id, first_name, last_name, and Email) is the relation schema for the customer relation. Relation state is defined by the set of relation tuples; thus, adding, deleting, and amending a tuple will change the relation to another state.

Tuple order or position in the relation is not important, and the relation is not sensitive to tuple order. The tuples in the relation could be ordered by a single attribute or a set of attributes. Also, a relation cannot have duplicate tuples.

A relation can represent entities in the real world, such as a customer, or can be used to represent an association between relations. For example, the customer could have several services, and a service can be offered to several customers. This could be modeled by three relations: customer, service, and customer_service. The customer_service relation associates the customer and the service relations. Separating the data in different relations is a key concept in relational database modeling. This concept called normalization is the process of organizing relation columns and relations to reduce data redundancy. For example, let us assume a collection of services is stored in the customer relation. If a service is assigned to multiple customers, that would result in data redundancy. Also, updating a certain service would require updating all its copies in the customer table.

Tuple

A tuple is a set of ordered attributes. They are written by listing the elements within parentheses () and separated by commas, such as (john, smith, 1971). Tuple elements are identified via the attribute name. Tuples have the following properties:

(a1,a2, a3, …an) = (b1, b2,b3,…,bn ) if and only if a1 = ba , a2=b2, … an= bn
A tuple is not a set, the order of attributes matters.
- (a1, a2) ≠(a2, a1)
- (a1, a1) ≠(a1)
- A tuple has a finite set of attributes

In the formal relational model, multi-valued attributes as well as composite attributes are not allowed. This is important to reduce data redundancy and increasing data consistency. This isn't strictly true in modern relational database systems because of the utilization of complex data types such as JSON and key-value stores. There is a lot of debate regarding the application of normalization; the rule of thumb is to apply normalization unless there is a good reason not to do so.

Another important concept is that of the unknown values, that is, NULL values. For example, in the customer relation, the phone number of a customer might be unknown. Predicates in relational databases uses three-valued logic (3VL), where there are three truth values: true, false, and unknown. In a relational database, the third value, unknown, can be interpreted in many ways, such as unknown data, missing data, or not applicable. The three-valued logic is used to remove ambiguity. Imagine two tuples in the customer relation with missing phone values; does that mean both have the same phone, that is, NULL=NULL? The evaluation of the expression NULL=NULL is also NULL.

Logical operator OR truth table

Logical AND truth table

Logical NOT truth table

Attribute

Each attribute has a name and a domain, and the name should be distinct within the relation. The domain defines the possible set of values that the attribute can have. One way to define the domain is to define the data type and a constraint on this data type. For example, hourly wage should be a positive real number and bigger than five if we assume the minimum hourly wage is five dollars. The domain could be continuous, such as salary which is any positive real number, or discrete, such as gender.

The formal relational model puts a constraint on the domain: the value should be atomic. Atomic means that each value in the domain is indivisible. For instance, the name attribute domain is not atomic, because it can be divided into first name and last name. Some examples of domains are as follows:

Phone number: Numeric text with a certain length.
Country code: Defined by ISO 3166 as a list of two letter codes (ISO alpha-2) and three letter codes (ISO alpha-3). The country codes for Germany are DE and DEU for alpha-2 and alpha-3 respectively.
Tip
It is good practice if you have lookup tables such as country code, currency code, and languages to use the already defined codes in ISO standards, instead of inventing your own codes.

Constraint

The relational model defines many constraints in order to control data integrity, redundancy, and validity.

Redundancy: Duplicate tuples are not allowed in the relation.
Validity: Domain constraints control data validity.
Integrity: The relations within a single database are linked to each other. An action on a relation such as updating or deleting a tuple might leave the other relations in an invalid state.

We could classify the constraints in a relational database roughly into two categories:

Inherited constraints from the relational model: Domain integrity, entity integrity, and referential integrity constraints.
Semantic constraint, business rules, and application specific constraints: These constraints cannot be expressed explicitly by the relational model. However, with the introduction of procedural SQL languages such as PL/pgsql for PostgreSQL, relational databases can also be used to model these constraints.

Domain integrity constraint

The domain integrity constraint ensures data validity. The first step in defining the domain integrity constraint is to determine the appropriate data type. The domain data types could be integer, real, boolean, character, text, inet, and so on. For example, the data type of first name and e-mail address is text. After specifying the data type, check constraints, such as the mail address pattern, need to be defined.

Check constraint: A check constraint can be applied to a single attribute or a combination of many attributes in a tuple. Let us assume that customer_service schema is defined as (customr_id, service_id, start_date, end _date, order_date). For this relation, we can have a check constraint to make sure that start_date and end_date are entered correctly by applying the following check (start_date<end_date).
Default constraint: The attribute can have a default value. The default value could be a fixed value such as the default hourly wage of the employees , for example, $10. It may also have a dynamic value based on a function such as random, current time, and date. For example, in the customer_service relation, order_date can have a default value which is the current date.
Unique constraint: A unique constraint guarantees that the attribute has a distinct value in each tuple. It allows null values. For example, let us assume we have a relation player defined as player (player_id, player_nickname). The player uses his ID to play with others; he can also pick up a nickname which is not used by someone else.
Not null constraint: By default, the attribute value can be null. The not null constraint restricts an attribute from having a null value. For example, each person in the birth registry record should have a name.

Entity integrity constraint

In the relational model, a relation is defined as a set of tuples. By definition, the element of the set is distinct. This means that all the tuples in a relation must be distinct. The entity integrity constraint is enforced by having a primary key which is an attribute/set of attributes having the following characteristics:

The attribute should be unique
The attributes should be not null

Each relation must have only one primary key, but can have many unique keys. A candidate key is a minimal set of attributes which can identify a tuple. All unique, not null attributes can be candidate keys. The set of all attributes form a super key. In practice, we often pick up a single attribute to be a primary key instead of a compound key (key that consists of two or more attributes that uniquely identify a tuple) to reduce data redundancy, and to ease the joining of the relations with each other.

If the primary key is generated by the DBMS, then it is called a surrogate key. Otherwise, it is called a natural key. The surrogate key candidates can be sequences and universal unique identifiers (UUID). A surrogate key has many advantages such as performance, requirement change tolerance, agility, and compatibility with object relational mappers. More on surrogate keys will be covered in the following chapters.

Referential integrity constraints

Relations are associated with each other via common attributes. Referential integrity constraints govern the association between two relations, and ensure data consistency between tuples. If a tuple in one relation references a tuple in another relation, then the referenced tuple must exist. In the customer service example, if a service is assigned to a customer, then the service and the customer must exist as shown in the following example. For instance, in the customer_service relation, we cannot have a tuple with values (5, 1,01-01-2014, NULL), because we do not have a customer with customer_id equal to 5.

Association between customer and service

The lack of referential integrity constraints can lead to many problems such as:

Invalid data in the common attributes
Invalid information during joining of data from different relations.

Referential integrity constraints are achieved via foreign keys. A foreign key is an attribute or a set of attributes that can identify a tuple in the referenced relation. Since the purpose of a foreign key is to identify a tuple in the referenced relation, foreign keys are generally primary keys in the referenced relation. Unlike a primary key, a foreign key can have a null value. It can also reference a unique attribute in the referenced relation. Allowing a foreign key to have a null value enables us to model different cardinality constraints. Cardinality constraints define the participation between two different relations. For example, a parent can have more than one child; this relation is called one-to-many relationship, because one tuple in the referenced relation is associated with many tuples in the referencing relation. Also, a relation could reference itself. This foreign key is called a self-referencing or recursive foreign key. For example, a company acquired by another company:

`company_id`	`Name`	`acquisitioned_by`
`1`	`Facebook`
`2`	`WhatsApp`	`1`
Primary key		Foreign key

Recursive foreign key

To ensure data integrity, foreign keys can be used to define several behaviors when a tuple in the referenced relation is updated or deleted. The following behaviors are called referential actions:

Cascade: When a tuple is deleted or updated in the referenced relation, the tuples in the referencing relation are also updated or deleted.
Restrict: The tuple cannot be deleted or the referenced attribute cannot be updated if it is referenced by another relation.
No action: Similar to restrict, but it is deferred to the end of the transaction.
Set default: When a tuple in the referenced relation is deleted or the referenced attribute is updated, then the foreign key value is assigned the default value.
Set null: The foreign key attribute value is set to null when the referenced tuple is deleted.

Semantic constraints

Semantic integrity constraints or business logic constraints describe the database application constraints in general. Those constraints are either enforced by the business logic tier of the application program or by SQL procedural languages. Trigger and rule systems can also be used for this purpose. For example, the customer should have at most one active service at a time. Based on the nature of the application, one could favor using an SQL procedural language or a high-level programming language to meet the semantic constraints. The advantages of using the SQL programming language are:

Performance: RDBMSs often have complex analyzers to generate efficient execution plans. Also, in some cases such as data mining, the amount of data that needs to be manipulated is very large. Manipulating the data using procedural SQL language eliminates the network data transfer. Finally, some procedural SQL languages utilize clever caching algorithms.
Last minute change: For the SQL procedural languages, one could deploy bug fixes without service disruption.

Relational algebra

Relational algebra is the formal language of the relational model. It defines a set of closed operations over relations, that is, the result of each operation is a new relation. Relational algebra inherits many operators from set algebra. Relational algebra operations could be categorized into two groups:

The first one is a group of operations which are inherited from set theory such as UNION, INTERSECTION, SET DIFFERENCE, and CARTESIAN PRODUCT, also known as CROSS PRODUCT.
The second is a group of operations which are specific to the relational model such as SELECT and PROJECT.

Relational algebra operations could also be classified as binary and unary operations. Primitive relational algebra operators have ultimate power of reconstructing complex queries. The primitive operators are:

SELECT (): A unary operation written as where is a predicate. The selection retrieves the tuples in R, where holds.
PROJECT (): A unary operation used to slice the relation in a vertical dimension, that is, attributes. This operation is written as , where are a set of attribute names.
CARTESIAN PRODUCT (): A binary operation used to generate a more complex relation by joining each tuple of its operands together. Let us assume that R and S are two relations, then , where and .
UNION (): Appends two relations together; note that the relations should be union compatible, that is, they should have the same set of ordered attributes. Formally,, where and .
DIFFERENCE ( or -): A binary operation in which the operands should be union compatible. Difference creates a new relation from the tuples, which exist in one relation but not in the other. The set difference for the relation R and S can be given as , where and .
RENAME (): A unary operation that works on attributes. It simply renames an attribute. This operator is mainly used in JOIN operations to distinguish the attributes with the same names but in different relation tuples. Rename is expressed as .

In addition to the primitive operators, there are aggregation functions such as sum, count, min, max, and average aggregates. Primitive operators can be used to define other relation operators such as left-join, right-join, equi-join, and intersection. Relational algebra is very important due to its expressive power in optimizing and rewriting queries. For example, the selection is commutative, so . A cascaded selection may also be replaced by a single selection with a conjunction of all the predicates, that is, .

The SELECT and PROJECT operations

SELECT is used to restrict tuples from the relation. If no predicate is given then the whole set of tuples is returned. For example, the query "give me the customer information where the customer_id equals to 2" is written as:

The selection is commutative; the query "give me all customers where the customer mail is known, and the customer first name is kim" is written in three different ways, as follows:

The selection predicates are certainly determined by the data types. For numeric data types, the comparison operator might be ( The SELECT and PROJECT operations ). The predicate expression can contain complex expressions and functions.

The equivalent SQL statement for the SELECT operator is the SELECT * statement, and the predicate is defined in the WHERE clause. Finally, the * means all the relation attributes; note that in the production environment, it is not recommended to use *. Instead, one should list all the relation attributes explicitly.

SELECT * FROM customer WHERE customer_id=2

The project operation could be visualized as vertical slicing of the table. The query: "give me the customer names" is written in relational algebra as follows:

first_name	last_name
Thomas	Baumann
Wang	Kim
Christian	Bayer
Ali	Ahmad

The result of project operation

Duplicate tuples are not allowed in the formal relational model; the number of returned tuples from the project operator is always equal to or less than the number of total tuples in the relation. If a project operator's attribute list contains a primary key, then the resulting relation has the same number of tuples as the projected relation.

Cascading projections could be optimized as the following expression:

The SQL equivalent for the PROJECT operator in SQL is SELECT DISTINCT. The DISTINCT keyword is used to eliminate duplicates. To get the result shown in the preceding expression, one could execute the following SQL statement:

SELECT DISTINCT first_name, last_name FROM customers;

The sequence of the execution of the PROJECT and SELECT operations can be interchangeable in some cases.

The query "give me the name of the customer with customer_id equal to 2" could be written as:

In other cases, the PROJECT and SELECT operators must have an explicit order as shown in the following example; otherwise, it will lead to an incorrect expression. The query "give me the last name of the customers where the first name is kim" could be written as the following expression:

The RENAME operation

The Rename operation is used to alter the attribute name of the resultant relation, or to give a specific name to the resultant relation. The Rename operation is used to:

Remove confusion if two or more relations have attributes with the same name
Provide user-friendly names for attributes, especially when interfacing with reporting engines
Provide a convenient way to change the relation definition, and still be backward compatible

The AS keyword in SQL is the equivalent of the RENAME operator in relational algebra. the following SQL example creates a relation with one tuple and one attribute, which is renamed PI.

SELECT 3.14::real AS PI;

The Set theory operations

The set theory operations are union, intersection, and minus (difference). Intersection is not a primitive relational algebra operator, because it is can be written using the union and difference operators:

The intersection and union are commutative:

For example, the query "give me all the customer IDs where the customer does not have a service assigned to him" could be written as:

The CROSS JOIN (Cartesian product) operation

The CROSS JOIN operation is used to combine tuples from two relations into a single relation. The number of attributes in a single relation equals the sum of the number of attributes of the two relations. The number of tuples in the single relation equals the product of the number of tuples in the two relations. Let us assume A and B are two relations, and The CROSS JOIN (Cartesian product) operation . Then:

The following image shows the cross join of customer and customer service, that is, The CROSS JOIN (Cartesian product) operation :

customer.customer_id	first_name	last_name	Email	phone	customer_service.customer_id	service_id	start_date	end_date
`1`	`Thomas`	`Baumann`		`6622347`	`1`	`1`	`01-01-2014`
`2`	`Wang`	`Kim`	`kim@kim_wang.com`	`6622345`	`1`	`1`	`01-01-2014`
`3`	`Christian`	`Bayer`		`6622919`	`1`	`1`	`01-01-2014`
`4`	`Ali`	`Ahmad`	`ahmad@ali.com`	`3322123`	`1`	`1`	`01-01-2014`
`1`	`Thomas`	`Baumann`		`6622347`	`1`	`2`	`01-01-2014`
`2`	`Wang`	`Kim`	`kim@kim_wang.com`	`6622345`	`1`	`2`	`01-01-2014`
`3`	`Christian`	`Bayer`		`6622919`	`1`	`2`	`01-01-2014`
`4`	`Ali`	`Ahmad`	`ahmad@ali.com`	`3322123`	`1`	`2`	`01-01-2014`
`1`	`Thomas`	`Baumann`		`6622347`	`3`	`1`	`12-04-2014`	`12-05-2014`
`2`	`Wang`	`Kim`	`kim@kim_wang.com`	`6622345`	`3`	`1`	`12-04-2014`	`12-05-2014`
`3`	`Christian`	`Bayer`		`6622919`	`3`	`1`	`12-04-2014`	`12-05-2014`
`4`	`Ali`	`Ahmad`	`ahmad@ali.com`	`3322123`	`3`	`1`	`12-04-2014`	`12-05-2014`
`1`	`Thomas`	`Baumann`		`6622347`	`4`	`1`	`01-06-2014`
`2`	`Wang`	`Kim`	`kim@kim_wang.com`	`6622345`	`4`	`1`	`01-06-2014`
`3`	`Christian`	`Bayer`		`6622919`	`4`	`1`	`01-06-2014`
`4`	`Ali`	`Ahmad`	`ahmad@ali.com`	`3322123`	`4`	`1`	`01-06-2014`

CROSS JOIN of customer and customer_service relations

For example, the query "for the customer with customer_id equal to 3, retrieve the customer name and the customer service IDs" could be written in SQL as follows:

SELECT first_name, last_name, service_id
FROM customer AS c CROSS JOIN customer_service AS cs
WHERE c.customer_id=cs.customer_id AND c.customer_id = 3;

In the preceding example, one can see the relationship between relational algebra and the SQL language. It shows how relational algebra could be used to optimize query execution. This example could be executed in several ways, such as:

Execution plan 1:

Select the customer where customer_id = 3.
Select the customer service where customer_id = 3.
Cross JOIN the relations resulting from steps 1 and 2.
Project first_name, last_name, and service_id from the relation resulting from step 3

Execution plan 2:

Cross JOIN customer and customer_service
Select all the tuples where
Customer_service.customer_id=customer.customer_id and customer.customer_id = 3
Project first_name, last_name, and service_id from the relation resulting from step 2.

Each execution plan has a cost in terms of CPU and hard disk operations. The RDBMS picks the one with the lowest cost. In the preceding execution plans, the RENAME operator was ignored for simplicity.

Data modeling

Data models describe real-world entities such as customer, service, products, and the relation between these entities. Data models provide an abstraction for the relations in the database. Data models aid the developers in modeling business requirements, and translating business requirements to relations in the relational database. They are also used for the exchange of information between the developers and business owners.

In the enterprise, data models play a very important role in achieving data consistency across interacting systems. For example, if an entity is not defined, or is poorly defined, then this will lead to inconsistent and misinterpreted data across the enterprise. For instance, if the semantics of the customer entity is not defined clearly, and different business departments use different names for the same entity such as customer and client, this may lead to confusion in the operational departments.

Another common bad practice is to define business rules that describe how things should be done at the database level. This contradicts the "abstraction of concerns" and leads to fixed complex data structures. The business departments should define what needs to be done but not how.

Data model perspectives

Data model perspectives are defined by ANSI as follows:

Conceptual data model: Describes the domain semantics, and is used to communicate the main business rules, actors, and concepts. It describes the business requirements at a high level and is often called a high-level data model. The conceptual model is the chain between developers and business departments in the application development life cycle.
Logical data model: Describes the semantics for a certain technology, for example, the UML class diagram for object-oriented languages.
Physical data model: Describes how data is actually stored and manipulated at the hardware level such as storage area network, table space, CPUs, and so on.

According to ANSI, this abstraction allows changing one part of the three perspectives without amending the other parts. One could change both the logical and the physical data models without changing the conceptual model. To explain, sorting data using bubble or quick sort is not of interest for the conceptual data model. Also, changing the structure of the relations could be transparent to the conceptual model. One could split one relation into many relations after applying normalization rules, or by using enum data types in order to model the lookup tables.

The entity-relation model

The entity-relation (ER) model falls in the conceptual data model category. It captures and represents the data model for both business users and developers. The ER model can be transformed into the relational model by following certain techniques.

Conceptual modeling is a part of the Software development life cycle (SDLC). It is normally done after the functional and data requirements-gathering stage. At this point, the developer is able to make the first draft of the ER diagram as well as describe functional requirements using data flow diagrams, sequence diagrams, user case scenarios, user stories, and many other techniques.

During the design phase, the database developer should give great attention to the design, run a benchmark stack to ensure performance, and validate user requirements. Developers modeling simple systems could start coding directly. However, care should be taken when making the design, since data modeling involves not only algorithms in modeling the application but also data. The change in design might lead to a lot of complexities in the future such as data migration from one data structure to another.

While designing a database schema, avoiding design pitfalls is not enough. There are alternative designs, where one could be chosen. The following pitfalls should be avoided:

Data redundancy: Bad database designs elicit redundant data. Redundant data can cause several other problems including data inconsistency and performance degradation. When updating a tuple which contains redundant data, the changes on the redundant data should be reflected in all the tuples that contain this data.
Null saturation: By nature, some applications have sparse data, such as medical applications. Imagine a relation called diagnostics which has hundreds of attributes for symptoms like fever, headache, sneezing, and so on. Most of them are not valid for certain diagnostics, but they are valid in general. This could be modeled by utilizing complex data types like JSON, or by using vertical modeling like entity-attribute-value (EAV).
Tight coupling: In some cases, tight coupling leads to complex and difficult-to-change data structures. Since business requirements change with time, some requirements might become obsolete. Modeling generalization and specialization (for example a part-time student is a student) in a tightly coupled way may cause problems.

Sample application

In order to explain the basics of the ER model, an online web portal to buy and sell cars will be modeled. The requirements of this sample application are listed as follows, and an ER model will be developed step-by-step:

The portal provides the facility to register the users online, and provide different services for the users based on their categories.
The users might be sellers or normal users. The sellers can create new car advertisements; other users can explore and search for cars.
All users should provide there full name and a valid e-mail address during registration. The e-mail address will be used for logging in.
The seller should also provide an address.
The user can rate the advertisement and the seller's service quality.
All users' search history should be maintained for later use.
The sellers have ranks and this affects the advertisement search; the rank is determined by the number of posted advertisements and the user's rank.
The car advertisement has a date and the car can have many attributes such as color, number of doors, number of previous owners, registration number, pictures and so on.

Entities, attributes, and keys

The ER diagram represents entities, attributes, and relationships. An entity is a representation of a real-world object such as car or a user. An attribute is a property of an object and describes it. A relationship represents an association between two or more entities.

The attributes might be composite or simple (atomic). Composite attributes can be divided into smaller subparts. A subpart of a composite attribute provides incomplete information that is semantically not useful by itself. For example, the address is composed of street name, building number, and postal code. Any one of them isn't useful alone without its counterparts.

Attributes could also be single-valued or multi-valued. The color of a bird is an example of a multi-valued attribute. It can be red and black, or a combination of any other colors. A multi-valued attribute can have a lower and upper bound to constrain the number of values allowed. In addition, some attributes can be derived from other attributes. Age can be derived from the birth date. In our example, the final rank of a seller is derived from the number of advertisements and the user ratings.

Finally, key attributes can identify an entity in the real world. A key attribute should be marked as a unique attribute, but not necessarily as a primary key, when physically modeling the relation. Finally, several attribute types could be grouped together to form a complex attribute.

Attribute symbol	Meaning
	Key attribute Example: E-mail address
	Attribute Example: Date of birth
	Derived attribute Example: Age
	Multi-valued attribute Example: Car color
	Composite attribute Example: Address

Summary of the attribute notation for ER diagrams.

Entities should have a name and a set of attributes. They are classified into the following:

Weak entity: Does not have key attributes of its own
Strong entity or regular entity: Has a key attribute.

A weak entity is usually related to another strong entity. This strong entity is called the identifying entity. Weak entities have a partial key, aka "discriminator", which is an attribute that can uniquely identify the weak entity, and it is related to the identifying entity. In our example, if we assume that the search key is distinct each time the user searches for cars, then the search key is the partial key. The weak entity symbol is distinguished by surrounding the entity box with a double line.

Entity symbol	Meaning
	Weak entity
	Strong entity

ER entities symbols

The next image shows the preliminary design of the online. The user entity has several attributes. The name attribute is a composite attribute, and e-mail is a key attribute. The seller entity is a specialization of the user entity. The total rank is a derived attribute calculated by aggregating the user ratings and the number of advertisements. The color attribute of the car is multi-valued. The seller can be rated by the users for certain advertisements; this relation is a ternary relation, because the rating involves three entities which are car, seller, and user. The car picture is a subpart attribute of the advertisement. The following diagram shows that the car can be advertised more than once by different sellers. In the real world, this makes sense, because one could ask more than one seller to sell his car.

The entity design of the car portal database.

When an attribute of one entity refers to another entity, some relationships exist. In the ER model, these references should not be modeled as attributes but as relationships or weak entities. Similar to entities, there are two classes of relationships: weak and strong. Weak relationships associate the weak entities with other entities. Relationships can have attributes as entities. In our example, the car is advertised by the seller; the advertisement date is a property of the relationship.

Relationships have cardinality constraints to limit the possible combinations of entities that participate in a relationship. The cardinality constraint of car and seller is 1:N; the car is advertised by one seller, and the seller can advertise many cars. The participation between seller and user is called total participation, and is denoted by a double line. This means that a seller cannot coexist alone, and he must be a user.

Tip

The many-to-many relationship cardinality constraint is denoted by N:M to emphasize different participation from the entities.

Car web portal ER diagram.

Up until now, only the basic concepts of ER diagrams have been covered. Some concepts such as (min, max) cardinality notation, ternary/n-ary relationships, generalization, specialization, and Enhanced Entity relation diagrams (EER) have not been discussed.

Mapping ER to Relations

The rules for mapping an ER diagram to a set of relations (that is, the database schema) are almost straightforward but not rigid. One could model an entity as an attribute, and then refine it to a relationship. An attribute which belongs to several entities can be promoted to be an independent entity. The most common rules are listed as follows (note that only basic rules have been covered, and the list is not exhaustive):

Map regular entities to relations: If entities have composite attributes, then include all the subparts of the attributes. Pick one of the key attributes as a primary key.
Map weak entities to relations, include simple attributes and the subparts of the composite attributes. Add a foreign key to reference the identifying entity. The primary key is normally the combination of the partial key and the foreign key.
If a relationship has an attribute, and the relation cardinality is 1:1, then the relation attribute can be assigned to one of the participating entities.
If a relationship has an attribute, and the relation cardinality is 1:N, then the relation attribute can be assigned to the participating entity on the N side. For example, the advertisement_date can be assigned to the car relation.
Map many-to-many relationships, also known as N:M, to a new relation. Add foreign keys to reference the participating entities. The primary key is the composition of foreign keys. The customer_service relation is an example of many-to-many relationship.
Map a multi-valued attribute to a relation. Add a foreign key to reference the entity that owns the multi-valued attribute. The primary key is the composition of the foreign key and the multi-valued attribute.

UML class diagrams

Unified modeling language (UML) is a standard developed by Object Management Group (OMG). UML diagrams are widely used in modeling software solutions, and there are several types of UML diagrams for different modeling purposes including class, use case, activity, and implementation diagrams.

A class diagram can represent several types of associations, that is, the relationship between classes. They can depict attributes as well as methods. An ER diagram can be easily translated into a UML class diagram. UML class diagrams also have the following advantages:

Code reverse engineering: The database schema can be easily reversed to generate a UML class diagram.
Modeling extended relational database objects: Modern relational databases have several object types such as sequences, views, indexes, functions, and stored procedures. UML class diagrams have the capability to represent these objects types.

Summary

The design of a database management system is affected by the CAP theorem. Relational databases and NoSQL databases are not rivals but complementary. One can utilize different database categories in a single software application. In certain scenarios, one can use the key-value store as a cache engine on top of the relational database to gain performance.

Relational and object-relational databases are the market-dominant databases. Relational databases are based on the concept of relation, and have a very robust mathematical model. Object-relational databases such as PostgreSQL overcome the limitations of relational databases by introducing complex data types, inheritance, and rich extensions.

Relational databases are based on the relation, tuple, and the attribute concepts. They ensure data validity and consistency by employing several techniques such as entity integrity, constraints, referential integrity, and data normalization.

Modern RDBMS can capture semantic constraints by using SQL procedural languages, triggers, and rule systems. PostgreSQL can support several procedural languages including C, PL/pgSQL, PL/Python, and so on.

Relational algebra enables the developer to rewrite the SQL code in alternative ways. It also enables the RDBMS to generate, compare, and choose an execution plan from different execution plans. Relational algebra provides a closed set of operations which can be combined together to answer complex queries.

SQL is the standard relational database language. SQL standards are maintained by ISO, and SQL code is often compatible with different relational databases.

Data modeling is very important for communicating business requirements; it can help in achieving the concept of separation of concerns. There are several data modeling perspectives, namely, conceptual, logical, and physical perspectives.

In the next chapter, an overview of PostgreSQL will be introduced. The next chapter will discuss the advantages, history, capabilities, and forks of PostgreSQL. It also will show how one can install PostgreSQL on different platforms including Linux and Windows.

Tip

Downloading the example code

You can download the example code fies from your account at http://www. packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

Zoltan Dec 31, 2015

The book starts out with a nice and conveniently brief but concise summary of all the main terms and concepts of database theory, including NoSQL and (object)relational databases. One does well to read up on the former (NoSQL) concept on the web since there are more than 225 of them as of today (nosql-database.org), whereas the book will focus on the SQL concepts afterwards. I really liked the fact that the authors do not shy away from explaining even the most basic terms in significant detail; this way absolute beginners will also fully benefit from the book, whereas more experienced programmers and administrators can simply just skim through these parts for a quick refresher. As an example, the often problematic concept of "unknown" (NULL) values and their relationship with TRUE and FALSE values is very nicely handled, including the truth tables for OR, AND and NOT.The basic concepts are also put into context via a well-detailed example application of a car web-portal, including detailed flow- and relationship charts (ER diagrams), which will help even the very beginners to understand the way of thinking required in database design. All code is available from the publisher, which saves the programmer a lot of typing time and typos.The detailed description of PostgreSQL is very complete, with history, concepts and sample applications. I would add to their "Success stories" the very popular and well established image database application OMERO (http://www.openmicroscopy.org/site), which has been around for 10 years and is being used by hundreds of research labs and institutions around the world, as well as by scientific journals. I personally installed OMERO, and thus PostgreSQL, many times and always found installing PostgreSQL very straightforward. The book will also guide the readers through these steps, including server settings, adding users, administration, etc. The setting up of clients is described in great detail, rightly so since this is the key concept for main users of databases once the installation is done.The book does a great job in explaining all the details of setting up the database, editing and acquiring its data, at the same time pointing out the most typical mistakes that users and administrators will encounter. Special emphasis is given to the various data types in relation not only to fitting the task at hand, but also to maintain and adjust the database to future demands. E.g., the great flexibility of the "text" type is given properly detailed description in Chapter 3. Using the same database example of the car web-portal throughout the book helps the reader to relate all new theoretical information easily to practicality.The later chapters (from Chapter 4) deal with more advanced concepts. These are crucial for those developing more demanding database applications and thus are very useful for the more experienced developers as well. For example, VIEWS are especially nicely described, which demand-dependent web application developers will certainly appreciate. Similarly well treated are the details of the very important concept of indexing.Those who want to go even further and extend the default functionality of PostgreSQL, may do so by writing their own FUNCTIONs in various languages. This is a difficult concept even for experienced developers, but the book does a great job by presenting these via simple yet realistic examples, including concrete code snippets in C and SQL (PL/pgSQL is described in Chapter 7). For me this came very handy with the OMERO database system, where I often needed to add server functionality for various research applications.Naturally, the book also handles the more generic advanced concepts that are used to automate databases, most importantly TRIGGERs.In Chapters 5 and 6 the readers will get a nice summary of the SQL language itself, and of advanced query writing. These concepts may already be familiar to many advanced readers, who may wish to give these chapters just a quick read.In Chapter 7 the authors describe PostgreSQL's default server-side programming language, PL/pgSQL. The advantage of using PL/pgSQL instead of SQL becomes clear very quickly and then the reader is happily immersed in the details of this powerful yet simple language. This chapter is quite long, but worth the effort.No such book would be complete without discussing the subject of data security, and Chapter 8 takes care of this in great detail. Especially nowadays, when hacking is exceptionally common, every database application developer needs to be very careful about security, and this chapter covers this task very well. Those readers who are completely new to the subject may also want to read a more detailed work on general web security, or rely on the experience of professional IT personnel when setting up their servers that will be open to the Internet.When administering a database, we face a certain group of standard tasks, and the book teaches the reader this subject in a cookbook format in Chapter 9. I love this, because here one really appreciates a well described and concrete action plan, rather than lots of theory. Find the task, follow the steps in this chapter, done! For those who want to know more, "There is more..." as the extra paragraphs at the end of each recipe are called; these describe additional ways to achieve the goal, or give more details.For more demanding applications, database optimization is especially important. This may not be a developer's favorite task, but the material in Chapter 10 will help us through it. Lots of ideas about common mistakes, streamlining queries, finding bottlenecks, these are all there. I found many new ideas here, even though I've been coding for databases for many years.The chapter on unconventional data types (Chapter 11) really helps those who customize their database applications heavily. The OMERO example cited above comes to mind here, especially in relation to XML and JSON data handling.A very important but often (somewhat) overlooked part of a developer's job is testing the application. This will be greatly helped by reading Chapter 12 for PostgreSQL coders. Once again a difficult subject, but handled well and smoothly here.Accessing your PostgreSQL database from external applications will be made much easier by Chapter 13, which describes JDBC, a platform that allows communication with PostgreSQL from a Java application. The examples are well structured and cover the most common users' needs.On the related subject of Object-relational mapping, Chapter 14 gives a nice review, including an introduction to the Hibernate framework. This a very advanced subject, but great to have for those on a more advanced level, or those who are aiming for this level.Overall, a well written book with a very wide range of subjects within the realm of PostgreSQL database management and development. Easy to read, free source code for the samples (this is automatic if one buys the book from the publisher, which is what I do; otherwise easily received via e-mail per request), which saves a lot of typing, and great examples throughout.

Amazon Verified review

O. COSTA Dec 18, 2015

After a quick read and practicing some sample code, I can say this is a great learning guide for database programming with PostgreSQL.Some valuable information well explained as :relational database compared with others (graph, NoSQL, ...), relational algebra, installation, using client tools, objects in PostgreSQL as SQL components (tables, views, ...) and Object in PostgreSQL as an ORDBMS, DDL, DML and DCL, advanced queries, Common Table Expressions, window functions, UDF in C, encryption (one-way and two-way), unit testing, queries rewriting, optimization in many aspects, user datatypes, benchmark ... java with JDBC api (install, connect, static statement, prepared statements, cursors, calling stored functions) and finally ORM and Hibernate.Authors present an overview of PostgreSQL for developers. Each topic is clearly explained and accompanied by functional and realistic examples, some based on a case study (The car web portal database). This example follows the reader through chapters.Reading this book is pleasant. I enjoyed an easy and very smooth reading for non-English-speaking people. Examples are numerous and facilitate understanding of concepts.It would have been nice to explain inheritance not only for partitioning but also with an example of a specialized child table from a generic table ... as in OOP.Finally, a great book if you are student or professional developer who want to start learning PostgreSQL.

Oleg Okun Jan 16, 2016

PostgreSQL is an open source object relational database management system and as open source it is popular in academia and industry. This book provides a solid description of PostgreSQL in one volume that covers many topics that beginners and experienced users likely face at their daily work. At the same time, authors succeeded to put a lot of material into a not too lengthy book. The book is useful for both a BI engineer whose bread-and-butter is SQL programming and a system administrator maintaining, monitoring, and tuning databases. Advanced topics such as views, functions, user-defined data types, database security, database performance optimization, and unit tests for databases are described in sufficient details.

Andrea Dec 31, 2015

Book purpose is clear: Create, develop, and manage relational databases in real-world applications using PostgreSQL. And the author has over 10 years of experience in industry and academia (you can notice in the first chapter, with a great overview of relational databases).For sure the book is rich of information (with 464 pages and 14 chapters) useful both for admins and developers.Admins can use the first chapters (from 2) to better understand PostgreSQL, but the installation part remain little poor, and some parts, like system related optimization (chapter 10 is dedicated to the optimization aspects, but more at developer level) or high availability deployment are totally missed. Security is covered in chapter 8, both for admins and developers point of view.For sure will be more useful for a developer, also at a beginner level on this DMBS, with lot of information on the SQL and the PL/pgSQL languages and how writing better and advanced queries.There is also a chapter dedicated on Server-Side Programming with PL/pgSQL, useful for complex applications.

C. Barker Apr 26, 2016

I have no idea how this book got 5 stars. The book is a non-stop string of informational tidbits with no coherent direction. There seems to be no plan to progress the reader through learning PostgreSQL in any sort of structured way. You'd be better off downloading the PostgreSQL code and trying to understand PostgreSQL that way.

Learning PostgreSQL: Create, develop and manage relational databases in real world applications using PostgreSQL

What do you get with Print?

Contact Details

Shipping Address

Billing Address

A brief history

Database categories

The NoSQL databases

The CAP theorem

NoSQL motivation

Key value databases

Columnar databases

Document databases

Graph databases

Relational and object relational databases

ACID properties

The SQL Language

Basic concepts

Note

Relation

Tuple

Attribute

Tip

Constraint

Domain integrity constraint

Entity integrity constraint

Referential integrity constraints

Semantic constraints

Sample application

Entities, attributes, and keys

Mapping ER to Relations

Key benefits

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Product Details

Packt Subscriptions

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

People who bought this also bought

About the 3 authors

FAQs