Abstract
You’re supposed to be a database professional, by which I mean someone who (a) is a database practitioner and (b) has a reasonable degree of familiarity with relational theory. Please note that—I’m sorry to have to say this, but it’s true—a knowledge of SQL, no matter how deep, is not sufficient to satisfy part (b) of this requirement. As I said in SQL and Relational Theory:
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
It might be more appropriate to define QTY to be of type NONNEGATIVE_INTEGER (with the obvious semantics), but few DBMSs if any currently support such a type. Of course, we could introduce it as a user defined type, but I don’t want to get into the complications of user defined types in this book.
- 2.
I say “any” relation having that body, but actually two distinct relations can have the same body if and only if the body in question is empty. If it isn’t, then there’s exactly one relation that has the body in question (see the formal definition of relation in Chapter 5).
- 3.
Actually Tutorial D (note the boldface!) has been revised and extended somewhat since that book was published. A description of the revised version, which is the version I’ll be using throughout the present book, can be found in Database Explorations: Essays on The Third Manifesto and Related Topics, by C. J. Date and Hugh Darwen (Trafford, 2010), as well as on the website www.thethirdmanifesto.com.
- 4.
See the website mentioned in the previous footnote, www.thethirdmanifesto.com, for further information.
- 5.
I mustn’t give the impression that headings and (relation) schemas are exactly the same thing. Rather, a schema is the combination of a heading together with certain dependencies (see the next footnote), including but not necessarily limited to functional and join dependencies as discussed in detail later in this book.
- 6.
Also known as functional dependence. The terms dependence and dependency are used more or less interchangeably in the literature. However, dependence seems slightly better for the concept in general and dependency seems slightly better for a specific instance of the concept (and when a plural is needed—as it is in connection with instances of the concept but not with the concept as such—dependencies seems to trip off the tongue a little better than dependences does).
- 7.
This example of what FDs mean also serves to show why such dependencies are called functional. To elaborate: A function in mathematics is a mapping from one set A to another set B, not necessarily distinct from A, with the property that each element in A maps to just one element in B (but any number of distinct elements in A can map to the same element in B). In the example, therefore, we could say there’s a mapping from the set of CITY values in S to the set of STATUS values in S, and that mapping is indeed a mathematical function.
- 8.
One reason it doesn’t is that if the design recommendations discussed in the present book are followed, there should rarely be a need to declare FDs explicitly anyway.
- 9.
The first exception here is a logical necessity. The second isn’t but is, rather, a deliberate limitation imposed by the relational model.
- 10.
To illustrate what I mean by “stated or implied” here, consider the shipment tuple (S1, P1,300) shown in Figure 1-1. (Re the lack of quotes around S1 and P1 here, see footnote 12 later in this chapter.) That tuple states the proposition “Supplier S1 supplies part P1 in quantity 300.” However, it also implies several further propositions─for example, the propositions “Supplier S1 supplies some part in quantity 300”; “Supplier S1 supplies some part in some quantity”; “Some supplier supplies some part in quantity 300”; and even “Some supplier supplies some part in some quantity.” (To pursue the point a moment longer, in fact that tuple (S1, P1,300) implies exactly seven such “further propositions.” Why exactly seven, do you think?)
- 11.
By contrast, the answer has to be yes if relvar S has no tuple for supplier S6 (in logic, “if p then q” is true if p is false—again, regardless of whether we’re talking about the CWA or the OWA).
- 12.
Actually it’s a simplified form of that shorthand, because I haven’t even bothered to show the single quotes that really ought to enclose character string values such as ‘S1’ and ‘London’. Please note that I’ll be making heavy use of this simplified shorthand in the pages ahead, at least in regular text.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2019 C. J. Date
About this chapter
Cite this chapter
Date, C.J. (2019). Prerequisites. In: Database Design and Relational Theory. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-5540-7_2
Download citation
DOI: https://doi.org/10.1007/978-1-4842-5540-7_2
Published:
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4842-5539-1
Online ISBN: 978-1-4842-5540-7
eBook Packages: Professional and Applied ComputingProfessional and Applied Computing (R0)Apress Access Books