This chapter deals with physical database organization in its broadest sense. A primary focus is on physical database design – the translation of a logical data model into an internal data model, including the design of indexes to speed up data access. In this respect, this chapter builds on the insights gained from Chapter 12 in relation to physical record and file organization. However, we also zoom out to other concerns of physical data storage, such as technological and management aspects, as well as the important area of business continuity.

First, we discuss the concepts of tablespaces and index spaces, as well as other basic building blocks of physical database organization. The principles of file organization acquired in the previous chapter are then applied in the context of database organization. Here, we deal with the role of the query optimizer and how the latter uses indexes and other techniques to determine the optimal access plan to execute a query. We also pay particular attention to different alternatives for join implementation. In the second half of this chapter, we return to storage hardware, but now from a more global perspective than in Chapter 12. We deal with RAID technology and different approaches to networked storage, such as SAN and NAS. We conclude with a discussion on how these techniques can be applied in the context of business continuity. By no means do we claim exhaustiveness with respect to the topics covered in this chapter. Rather, we aim to provide the reader with a broad perspective on the many angles and concerns of physical data storage and management.

Relational databases implement the relational model, which is one of the most popular logical and internal data models in use nowadays. It was first formalized by Edgar F. Codd in his seminal paper “A relational model of data for large shared data banks”, which appeared in the well-respected journal Communications of the ACM in 1970. In this chapter we first introduce the basic concepts of the relational model and then formally define them in the next section. This is followed by an overview of the different types of keys, which are an essential building block of the relational model. The relational constraints are summarized next, followed by an example of a relational data model. Normalization will also be reviewed as a procedure to remove redundancies and anomalies from a relational data model. After having introduced the need for normalization and some informal guidelines, we zoom into functional dependencies and prime attribute types and discuss how both can be used during a multi-step normalization procedure. To conclude, we discuss how to map both ER and EER conceptual data models to a logical relational data model. The next chapter then zooms into SQL, which is the DDL and DML used by relational databases.

The majority of databases in actual organizational settings are multi-user databases. This implies that many applications and users can access the data in the database in parallel. This concurrent access to the same data, if not managed properly, may induce different types of anomalies or unexpected problems. Moreover, various kinds of errors or calamities may occur in the respective DBMS components or its environment – such as the operating system, the applications interacting with the DBMS, or the storage subsystem – possibly rendering the database data into an inconsistent state. Fortunately, most database systems provide a realm of transparent, although often configurable, solutions to avoid or otherwise deal with such problems. In this way, the DBMS supports the ACID (Atomicity, Consistency, Isolation, Durability) properties already mentioned in Chapter 1. At the heart of these solutions are the concepts of transactions and transaction management, recovery, and concurrency control. In this chapter, we first introduce each of these concepts. Then, we focus in more detail on transaction management and the DBMS components involved. After that, we discuss recovery and the different techniques to deal with calamities in the DBMS or application program, as well as the storage media. Finally, we describe in detail how concurrency control techniques, in interplay with transaction management and recovery, guarantee seamless concurrent access by multiple users to shared data.

Until this point, we have largely focused on storing data in the most optimal way, ensuring their integrity, as much as possible, at all times. A next obvious question is what can we do with these data from a business perspective? In this chapter, we discuss how to take data and extract valuable new business insights from it. We start by zooming into the various levels of corporate decisionmaking and how this relates to data requirements that support these decisions. This will bring us to the concept of a data warehouse, a massive consolidated data store that we formally define and extensively discuss in terms of data model, design, and development. We contrast data warehousing with some newer developments, such as virtualization, data lakes, and indicate synergies.

The object-oriented (OO) paradigm was first introduced by programming languages such as C++, Eiffel, and Smalltalk. Due to its expressive modeling power and formal semantics, the principles of OO have also been widely used in software development methodologies. However, for data storage and management, the adoption of OO proved less straightforward. In this chapter, we discuss various approaches to object persistence. First, we refresh the basic concepts of OO, many of which have been covered in Chapter 3. This will be followed by a discussion of advanced OO concepts such as method overloading, inheritance, method overriding, polymorphism, and dynamic binding. Next, we review the basic principles of object persistence. We then discuss object-oriented database management systems (OODBMSs), which is the core of this chapter. We conclude with evaluating OODBMSs and demonstrating their impact on the emergence of object-relational mapping (ORM) frameworks, which facilitate the persistence of objects into RDBMSs. Due to its popularity and ease of use, we use Java as the OO language for the examples.

Recap: Basic Concepts of OO

In object-oriented (OO) programming, an application consists of a series of objects that request services from each other. Each object is an instance of a class that contains a blueprint description of all the object's characteristics. Contrary to procedural programming, an object bundles both its variables (which determine its state) and its methods (which determine its behavior) in a coherent way.