DOMAINS: The Database Glue (PRACTICAL DATABASE FOUNDATIONS Book 6)
Book Details
Author(s)Fabian Pascal
PublisherDATABASE DEBUNKINGS
ISBN / ASINB00XVP831Y
ISBN-13978B00XVP8312
Sales Rank3,151,913
MarketplaceUnited States 🇺🇸
Description
Note: This paper assumes familiarity with the concepts and terminology introduced in paper #1, Business Modeling For Database Design in this series, which is recommended as preamble.
Domains are a fundamental database feature. Mathematical relations are defined on domains—they are subsets of Cartesian products of domains. In other words, no domains, no relations. Codd, the inventor of the relational data model (RDM), referred to them as the "glue that holds the database together"—only the values of columns defined on the same domains are meaningfully comparable e.g. for joins, because they represent the same attributes—they mean the same thing.
Yet they are one of the least understood database features. This is both a cause and a consequence of lack of domain support in SQL—both the standard and commercial implementations. The consequences, such as, for example, lack or poor support of user-defined domains of arbitrarily complexity, are erroneously blamed on the RDM when, in fact, domains are orthogonal to the model, which places no restrictions on them whatsoever.
This paper covers
· The domain concept;
· Distinctions from data type;
· Kinds of domains;
· SQL domain support;
· Implications for database practice and DBMS design.
Table of Contents
Introduction
1. Domains and Types
1.1. Meaning and Representation
2. Kinds of Domains
2.1. “Simple” Domains
2.2. “Complex” Domains
2.3. User-Defined Domains and System-Defined Types
3. Domains and SQL
4. Some Practical Implications
4.1. “Universal” DBMS
4.2. Database Design
4.3. ODBMS
4.4. NoSQL
4.5 Tackling Complexity
Conclusion
Domains are a fundamental database feature. Mathematical relations are defined on domains—they are subsets of Cartesian products of domains. In other words, no domains, no relations. Codd, the inventor of the relational data model (RDM), referred to them as the "glue that holds the database together"—only the values of columns defined on the same domains are meaningfully comparable e.g. for joins, because they represent the same attributes—they mean the same thing.
Yet they are one of the least understood database features. This is both a cause and a consequence of lack of domain support in SQL—both the standard and commercial implementations. The consequences, such as, for example, lack or poor support of user-defined domains of arbitrarily complexity, are erroneously blamed on the RDM when, in fact, domains are orthogonal to the model, which places no restrictions on them whatsoever.
This paper covers
· The domain concept;
· Distinctions from data type;
· Kinds of domains;
· SQL domain support;
· Implications for database practice and DBMS design.
Table of Contents
Introduction
1. Domains and Types
1.1. Meaning and Representation
2. Kinds of Domains
2.1. “Simple” Domains
2.2. “Complex” Domains
2.3. User-Defined Domains and System-Defined Types
3. Domains and SQL
4. Some Practical Implications
4.1. “Universal” DBMS
4.2. Database Design
4.3. ODBMS
4.4. NoSQL
4.5 Tackling Complexity
Conclusion

