Rdb Domain

I'm trying to understand TheThirdManifesto. I don't have a background in databases so I'm trying to bootstrap by first clearly expressing the fundamental terms and concepts. If you see that I'm making an error in my descriptions, please jump in and help me better understand. Thanks a mil. --BrandonCsSanders

Rdb is short for RelationalDatabase.

An RdbDomain is a named set of "atomic" values.

It is true that a domain may be described in terms of a set of values, but to be a type the set must be static. If it is dynamic, i.e., can change at run-time, then it is a collection (such as an array or relvar) rather than a domain. -- DaveVoorhis

This distinction is difficult for me to understand. It appears to me that TheThirdManifesto allows domains such as "the set of all 1D-arrays of integers". Such a set is static but infinite. Indeed, the set of all possible values for any arbitrary DataStructure could serve as an RdbDomain --- including a DataStructure that represents an entire database. That set is also static but infinite. Correct? --BrandonCsSanders

Yes, the set of all 1D-arrays of integers could be a domain, as is the set of all integers. Both of these are conceptually infinite, but a domain is an abstract description of a set of possible values; it does not actually maintain every value! In practice, memory and performance constraints will restrict values to finite limits, and the Rdb only needs to deal with the values you actually use. This is not unique to Rdbs, but is true in general of programming languages that support types. In other words, at a purely pragmatic level an INTEGER in TheThirdManifesto is no different from an int in C, C++, Java, and so on, and the same applies to more complex data structures.

What is unique about an Rdb is the explicit notion that collections of values are represented by tuples and relations and manipulated by relational algebra, instead of, or at least in addition to, (for example) the use of container class instances (eg., queues, lists, arrays, bags, sets, dictionaries, etc.) and imperative code. Internally, tuples and relations may well be implemented by containers and imperative code, but the relational model simplifies ad-hoc querying, eases schema alteration when the data is persistent, and allows the selection of physical implementation strategies to be automated, provably, by a run-time optimiser. By the way, this should not be interpreted as a poke at OO approaches, because it is not. In fact, relational and OO approaches are highly complementary. -- DaveVoorhis

Thanks for the help Dave ... this notion has clicked for me now :) The bit about the distinction between the Rdb and imperative abstract models did it for me.

One can imagine complex domains such as "users", "webpages", "orders", etc. (When naming a domain is the convention to use the singular?)

I would suggest that domains always be named in the singular, to reflect the fact that they name types rather than collections. -- DaveVoorhis

RdbDomains are the types that are used as attributes in RdbTuples and RdbHeadings.

The terms "Domain" and "Type" are synonyms. See TypeTheory. -- DaveVoorhis