C. J. Date - Type Inheritance and Relational Theory: Subtypes, Supertypes, and Substitutability

Subtypes, Supertypes, and Substitutability

Inheritance in The Third Manifesto

C. J. Date

Type Inheritance and Relational Theory

by C. J. Date

Copyright 2016 C. J. Date. All rights reserved.

Printed in the United States of America.

Published by OReilly Media, Inc.,

1005 Gravenstein Highway North, Sebastopol, CA 95472.

OReilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (.

Revision History:
2016-08-31 First release.

See http://oreilly.com/catalog/errata.csp?isbn=0636920051589 for release details.

Nutshell Handbook, the Nutshell Handbook logo, and the OReilly logo are registered trademarks of OReilly Media, Inc. Type Inheritance and Relational Theory and related trade dress are trademarks of OReilly Media, Inc.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and OReilly Media, Inc., was aware of a trademark claim, the designations have been printed in caps or initial caps.

While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.

ISBN: 978-1-491-95999-2

[LSI]

Without [geometric figures],
one is wandering about in a dark labyrinth

Galileo: Il Saggiatore (1623)

For he by geometric scale
Could take the size of pots of ale

Samuel Butler: Hudibras (1663)

On a cloth untrue
With a twisted cue
And elliptical billiard balls

W. S. Gilbert: The Mikado (1885)

To the memory of my brother Robert and to the inheritors

C. J. Date is an independent author, lecturer, researcher, and consultant, specializing in relational database technology. He is best known for his book An Introduction to Database Systems (8th edition, Addison-Wesley, 2004), which has sold some 900,000 copies at the time of writing and is used in several hundred colleges and universities worldwide. He is also the author of many other books on database management, the following among them:

• From Addison-Wesley: Databases, Types, and the Relational Model: The Third Manifesto (3rd edition, with Hugh Darwen, 2007)

• From Trafford: Logic and Databases: The Roots of Relational Theory (2007) and Database Explorations: Essays on The Third Manifesto and Related Topics (with Hugh Darwen, 2010)

• From Ventus: Go Faster! The TransRelationalTM Approach to DBMS Implementation (2002, 2011)

• From OReilly: Database Design and Relational Theory: Normal Forms and All That Jazz (2012); View Updating and Relational Theory: Solving the View Update Problem (2013); Relational Theory for Computer Professionals: What Relational Databases Are Really All About (2013); SQL and Relational Theory: How to Write Accurate SQL Code (3rd edition, 2015); and The New Relational Database Dictionary (2016)

• From Morgan Kaufmann: Time and Relational Theory: Temporal Data in the Relational Model and SQL (with Hugh Darwen and Nikos A. Lorentzos, 2014)

Mr. Date was inducted into the Computing Industry Hall of Fame in 2004. He enjoys a reputation that is second to none for his ability to explain complex technical subjects in a clear and understandable fashion.

This book will tell you more than you might have wanted to know about the subject of type inheritance (inheritance for short). Now, if youre reading these remarks, youre already rather special; most people dont bother to read prefaces at all. For that reason, the kind of thing that usually goes into a prefacebackground material, motivation underlying the work described, reasons for writing the book, what you will learn, and so forthIve deliberately deferred, mostly, to the body of the book (to in particular). In any case, theres really too much of that general nature that I want to say, and its too involved and interwoven, to fit comfortably into a conventional preface. But this is still a convenient place to take care of a few boilerplate items.

Right at the outset, I must make it clear that this is a book with an attitude. My friend and colleague, Hugh Darwen, and I have been working for many years on the theory on which this book is based: namely, our inheritance model. As a consequence, we have some very definite opinions about the subject matter, andspeaking purely for myself herethose opinions have had a major influence on the style and content of the writing. In some respects, in fact, the book isnt so much a textbook as it is a plea for the community at large to take a careful look at what weve done: a careful look, in fact, at what we consider to be a logical, sensible, and pragmatically useful approach to the subject. That said, however, the book does resemble a textbook in that most of the chapters include a set of exercises (as well as answers, in most cases); thus, you can test your own understanding of the material as you proceed, if you have a mind to.

Heres what Ill be assuming by way of background on your part:

• First, I assume you have some professional knowledge of data management: what it is, what data itself is, how data can be represented to make it suitable for formal manipulation, what such formal manipulations might look like, and so on. In other words, I assume youre interested in what some people like to call data modelingpossibly but not necessarily including comparatively advanced aspects of that subject, such as the notions of generalization and specialization.

• Second, I assume you have a good working knowledge of the relational model. Of course, if you really are interested in data modeling as Ive said I assume you are, then this second prerequisite goes (or should go) without sayingthough as a matter of fact I think most if not all of the book should make sense even to someone without a detailed background in relational theory.

• Third, I assume you also have some familiarity with at least one conventional programming languageincluding, preferably, at least one language thats not object oriented. Note: I dont mean to be offensive here; I mean, I dont intend the foregoing remarks to be taken as disparaging object languages as such. Rather, the reason I think it might be desirable for you to be familiar with at least one language thats not an object language is the following. Suppose the only languages you know do in fact happen all to be object languages. Then Im afraid you might find you need to do some unlearningand as we all know, unlearning can often be quite difficult to do. For example, in object languages, an object of, say, type NAME typically doesnt contain a name as such; rather, it contains a pointer, or reference, to such a name. By contrast, in the type theory described in and embraced by the present book, the counterpart of such an object would contain a name as such. (The reasons for this difference in approach are discussed in detail in the body of the book, in in particular.)