Are inclusion dependencies reducible to foreign-key dependencies?
Quote from AntC on October 21, 2019, 6:05 amQuote from dandl on October 21, 2019, 12:11 amYou can easily find a paid edition (if you have budget to spend)and there is a link on the TTM site to O'Reilly, but I found a free one here: https://www.allitebooks.in/type-inheritance-relational-theory/.
Thank you David. I'm not engaging with Brian's pet peeve. On an oblique 'never mind the quality, feel the width': can it really take over 500 pages to explore Date's Inheritance Model? Even given Date's usual prolixity, that seems way beyond anything reasonable. By comparison, how much would it take to explain Java's inheritance and contrast it with C++? Haskell's inheritance (which is not inheritance of types, but achieves the same objectives) takes a couple of pages in the Language Report, and maybe half a dozen pages to explore the consequences in an introductory text. Maybe another half dozen pages in documentation of compiler extensions.
We ad idem. I have frequently despaired at making sense of page after page of dense prose where a few succinct sentences would suffice. I read standards, RFCs, Law etc as a hobby and the only ones that come close are those that deliberately intend to ofuscate (like EULAs and PDSs). If obfuscation is not the aim, one has to wonder what is.
Date's preface says " the book isn’t so much a textbook as it is a plea for the community at large to take a careful look at what we’ve done: a careful look, in fact, at what we consider to be a logical, sensible, and pragmatically useful approach to the subject."
If I count as part of the 'community at large', wading through DBE Ch 19 was bad enough; I'm not going to take a "careful look" at 500+ pages unless I can see WIIFM. But AFAICT looking at the index entries, nothing on: sum types, product types, sum-of-product types, tagged unions, abstract types, parametric types, ... (I'm not saying the IM is without equivalents to those; I am saying that if Date wants to engage 'the community' he should try to explain in the community's language. OTOH I'm not asking for another 100 pages.)
Much of it is there, but under different names. As you say, that makes it really hard to be sure whether an idea is original in concept or merely original in naming. And that perhaps does the entire work a great disservice.
My view FWIW is that the TTM approach to scalar types, including those with components, are just variations on a familiar theme. POSSREPs are an oddity of little value, but would gain value if they were allowed explicitly as a basis for a union type. [I still think struct/record and union rather than product and sum.] And I would like type aliases.
But there is no type system in any language I know to correspond to the tuple type in TTM. The basic idea of named attributes and natural join on them is unique AFAICT. I guess the relation types are just a collection parameterised on its tuple type.
So does the IM add anything of comparable value? I really have no idea. The IM does provide a basis for tagged union types, but it shouldn't be needed for that. There is so much complexity in this document that I just don't know whether it's a useful thing or not. If I had inheritance of scalar types (value types in C#), would I use it, and when? I have no idea.
Quote from dandl on October 20, 2019, 11:38 pmQuote from Brian S on October 20, 2019, 12:48 pmYou're making my point. What reasons are there for declaring the type of any literal? The only literals in TTM with or without the IM that require such declaration denote empty relations.
Not so. In many languages literals can be ambiguous. The value 987 could be a small integer, large integer, decimal, single or double precision float, and used to initialise a variable or attribute declared to be of that type. IOW: in some languages the values REL { INT X, INT Y }{ 0,0 } and REL { INT X, FLOAT Y }{ 0,0 } are valid and different. The type has to be specified.
Well, I think the types of literals should be determined by their contents. I would expect the following to either fail to compile, or include an implicit conversion of the integer value 5 to floating point:
INT X; FLOAT Y; X := 5; Y := 5;
Small integer, integer and large integer all effectively have the same root type, and there is a direct conversion from whole decimal values and that same root type. Decimals are effectively fractions of integers whose denominators are powers of 10. One could even argue that decimal is in fact a union type consisting of the integers and fractions of integers having denominators that are a power of 10 > 0.
Brian