Chapter 2. Data Models

The flexibility of any database depends on the architecture and design of its data models. A data model fundamentally decides how data is stored, organized, and can be manipulated. When it comes to typical a RDBMS, we tend to provide the information in terms of hierarchical, relational, and network data models. SQL was designed to interact with an end user assuming he/she will use SQL to run queries that would aggregate data at one place, giving all information together. But it takes a lot of effort to maintain this user-oriented approach. Later, people realized that most of the time is being spent on creating database schemas, maintaining referential integrity, and providing transactional guarantees even though they are not using these things much. This thought ultimately resulted in the implementation of schema-less, relation-free databases, that is, NoSQL databases.

Relational data modeling starts with all the data that you have and the answers you can provide with...

Primary key

DynamoDB, being a key-value pair database, does not index on all given attributes for a given item; it only indexes on the primary key, which is a mandatory attribute for each item of the table.

DynamoDB supports two types of primary keys:

• Hash primary key

• Hash and range primary key

Hash primary key

Each DynamoDB table must have a hash primary key that is unique for each item. DynamoDB builds an unordered hash index on this key that allows us to uniquely identify any given item for a given table. So, while designing your table, you must choose an attribute that would have a unique value for each attribute. For example, while creating Person table, choosing Social Security Number (SSN) as a hash key would be a better option as compared to selecting a person's name as hash key, as there might be more than one person having the same name.

Hash and range primary key

Along with the hash key, DynamoDB also supports another primary key called range key, which can be used in combination with...

Secondary indexes

A primary key attribute allows us to create, maintain, and access data efficiently. To do so, DynamoDB creates indexes on those primary attributes as we have seen in the previous section. However, sometimes there might be a need to search and access items from attributes that are not part of the primary key. For all such needs, DynamoDB supports secondary indexes that can be created on attributes other than the primary key and can be accessed and searched in a manner similar to the primary key.

A secondary index contains a subset of attributes from the given table having an alternative key to support query operations. Secondary index allows users to search attributes other than the primary key, which makes DynamoDB useful for a varied set of applications. We can create multiple secondary indexes for a given table. If we don't create secondary indexes, the only option to get the item for a certain non-primary key attribute is to scan the complete table, which is a very expensive...

Data types

DynamoDB supports various data types, broadly classified into the following two types:

• Scalar data types (string, number, and binary)

• Multivalued data types (string set, number set, and binary set)

Scalar data types

Scalar data types are simply single-value, simple data types. DynamoDB supports the following three scalar data types:

• String

• Number

• Binary

String

The string is a multipurpose, useful data type that is similar to what we use in various programming languages. DynamoDB strings support UTF-8 binary encoding. DynamoDB does not put restrictions on the string size limit, but it specifies that the total attribute size should not be greater than 64 KB and we already know that attribute value is calculated considering the attribute name (key) plus attribute value together. When it comes to ordered query results, DynamoDB does the comparison using ASCII character code value, which means smaller letters (a,b,c,...) are greater than capital letters (A,B,C,…). One thing to note here is...

Operations on tables

A table in DynamoDB is quite easy to create and operate. With a few clicks on the DynamoDB management console, you can have your table created in a couple of minutes. To do so, you just need a suitable table name, primary key attributes, their data types, and read and write throughput provisioning units, and you are done. DynamoDB allows us to use the characters a-z, A-Z, 0-9, - (dash), .(dot), and _(underscore) in table names.

We have already seen how to create a table using the AWS management console in the previous chapter. Now, let's try to do table operations using the AWS SDK.

Using the AWS SDK for Java

In this section, we are going to see how to use the AWS SDK for Java to perform operations.

Create table

Before creating a table, you should have thought about how the user is going to use that table in his/her application. Data modeling in DynamoDB should be application oriented in order to get the maximum benefit of the NoSQL features. You should also have a proper...

Operations on items

Items in DynamoDB are simply collections of attributes. Attributes can be in the form of strings, numbers, binaries, or a set of scalar attributes. Each attribute consists of a name and a value. An item must have a primary key. As we have already seen, a primary key can have a hash key or a combination of hash and range keys. In addition to the primary key, items can have any number of attributes except for the fact that item size cannot exceed 64 KB.

While doing various item operations, you should have be aware of following DynamoDB features.

Strong versus eventual consistency

In Chapter 1, Getting Started, we had talked about the durability feature of DynamoDB. To provide this durability, DynamoDB keep copies of items in various availability zones. When a certain item gets updated, DynamoDB needs to make sure that it updates all other copies as well. However, it takes time to make any write consistent on all servers; that's why the operation is called eventually consistent...

Query and scan operations

The query operation is a very important operation that allows us to fetch specific items from the given table. It needs a primary input and an optional start key to compare with the list of items. The query fetches all matching entries to the input from a given table. You can also use comparison operations, such as greater than, less than, contains, between, and so on to narrow down the result set. Data returned from a query or scan operation is limited to 1 MB. If it does not find any matching items with respect to a given input key, it returns an empty set.

Query results are always sorted in the order of the range key value. By default, the order of sorting is ascending. If a table has secondary index, then the query operation can be performed on it as well.

The scan operation checks every individual item for a given table. We can specify the filter criteria in order to manage the search results after the scan gets completed. A scan filter normally consists of the...

Modeling relationships

Like any other database, modeling relationships is quite interesting even though DynamoDB is a NoSQL database. Now that we have learned about the DynamoDB's data model, we can start looking at how to use them in your application. Most of the time, people get confused on how to model the relationships between various tables. In this section, we are trying to make an effort to simplify this problem.

Let's try to understand the relationships better using our example of the bookstore, where we have entities, such as book, author, publisher, and so on.

One to one

In this type of relationship, a one-entity record of a table is related to only a one-entity record of the other table. In our bookstore application, we have the BookInfo and BookDetails tables. The BookInfo table can have information in brief about the book, which can be used to display book information on web pages, whereas the BookDetails table would be used when someone explicitly needs to see all the details...

Summary

In this chapter, we talked in detail about various aspects of the DynamoDB data model. We started with understanding the hash key, the range key, and their usage: secondary indexes, and how to use them in your application; and then we talked about various data types used in DynamoDB. We also discussed how to perform various operations on tables, items, and attributes using Java, .NET, and PHP APIs.

Now that we have learned how to use DynamoDB, it's time to understand how things work in the actual background. In the next chapter, we will discuss the architectural details of DynamoDB.