So here we are, the starting chapter with the obligatory introductory material that I hope people will read, digest, memorize and really take to heart.  I also realize that that is pretty unlikely. In fact, the first two chapters are kind of like that. First I introduce concepts, and in the next chapter I show how to draw pretty pictures of those concepts. Then comes normalization and after that we really start doing some modeling.

In this chapter I am going to cover the basic stuff that you ought to have at least been introduced to before you get started in relational database. Theory more or less for a history lesson to get you going and understand from whence all of the stuff came from. The chapter will include the following sections:

• History: Where did all of this relational database stuff come from? In this section I will present some history, largely based on Codd’s 12 Rules as an explanation for why the RDBMs is what it is.
• Relational Programming: This section will cover the differences between functional programming using C# or VB and relational programming using SQL.
• Relational data structures: This section will provide concise introductions of some of the fundamental database objects, including the database itself, as well as tables, columns, and keys. These objects are likely familiar to most, but there are some common misunderstandings in their usage that can make the difference between a mediocre design and a high-class, professional design. In particular, misunderstanding the vital role of keys in the database can lead to severe data integrity issues and to the mistaken belief that such keys and constraints can be effectively implemented outside the database. (Here is a subtle clue: they can’t.)
• Relationships: We will briefly survey the different types of relationships that can exist between relational the relational data structures introduced in the relational data structures section.
• Dependencies: The concept of dependencies between values and how they shape the process of designing databases later in the book will be discussed
• Database design phases: The next section provides an overview of the major phases of relational database design: conceptual/logical, relational and physical mapping phases. For time and budget reasons, it is often tempting to skip the earlier database design phases and move straight to the implementation phase. This chapter will explain why skipping any or all of these phases can lead to an incomplete and/or incorrect design, as well as one that does not support high-performance querying and reporting.
• The importance of requirements: No matter what your project management methodology might be, agile or waterfall, getting written requirements to work from in the design process is extremely important

If you have any of the previous editions of the book, this will be one of the least modified chapters of the book. The history of the relational database hasn’t really changed since 2005 when I wrote the last edition, nor has it really changed all that much in many years. It is however, still really important to at least have some basic knowledge of the relational model and what it means do you when you are designing your masterpiece of a database…