3 ms·

No, you are confusing convention and simplifications for convenience for fundamental properties.. What is generally considered Standard set theory today is typ

No, you are confusing convention and simplifications for convenience for fundamental properties.. What is generally considered Standard set theory today is typically ZF(C), which can be viewed and was intentionally developed as what is not called a "material set theory" or sometimes a "membership based set theory" In ZF(C), sets are characterized only by the binary “∈” operation and propositional equality of sets. It is actually the less common schools like the Elementary Theory of the Category of Sets (ETCS), where individual elements have no identity and must be unique. There are well documented disagreements between Zermelo and Frege vs Cantor and Lawvere, was the former was for membership and the later were against it. With ∈ or "is a member of" both of the following hold: Given a set A={1,2,3,4}; 3 ∈ A Given a set A={1,1,2,2,3,3,4,4}; 3 ∈ A There is value in defining things like multisets/bags and accessing concepts like multiplicity, but you could use a function you defined for a multiset and discard that information and it would fit the axioms of ZF. In computer science and databases, this is less than just a trivial factoid depending how deep you get, it will directly relate to how you can trade space for time or reduce communication costs to save on time. And yes even historically there were very popular network protocols where they would append the same element to a set and shift the complexity from insert time to read time. To be clear I am not asserting any claim of better outside of local context to doing so. You are absolutely correct that no production quality RDBMs are based on Codd's rules. That absolutely doesn't change the fact of what the term 'relational model' means, nor does it remove the reality that they follow enough of it so that where it breaks, even from a set centric perspective, is directly related to that origin. Especially in parallel, distributed systems that are the norm now. And the fact that things moved, doesn't change the reality that the 'relation' in the 'relational model' is as described in previous posts.

9rx 1y ago
No. You are getting confused by semantics. It is understood that definitions are just made up on the spot and anyone can define anything however they like. That was never in question. However, we are specifically talking about Codd. His definition for the relational model does not match anything we use today. Tablational databases are something quite different. So, sure, you can call what I call dynamically-typed languages statically-typed if you want. You're not wrong. Definitions cannot be wrong, fundamentally. But it is different, and since we're not talking about your definition and never were...
- nyrikki 1y ago
  From [0] which is Codd justifying it explicitly. > The term relation is used here in its accepted mathematical sense. Given sets S_1, S_2, ..., S_n (not necessarily distinct), R is a relation on these n sets if it is a set of ntuples each of which has its first element from S_1, its second element from S_z , and so on.’ We shall refer to S_i as the jth domain of R. Note the "(not necessarily distinct)" part and how he uses a table to describe it on the same page. From what is called the "Alice book" Foundations of Databases - Abiteboul, Hull, Vianu[1] the seminal textbook in database theory. > In the 1970s, Codd’s relational model revolutionized the field. In this model, humans view the data as organized in relations (tables), and more “declarative” languages are provided for data access. Unfortunately I can't find chapter 3, where the relational model is described in detail online. But for more concrete SQL as defined in ISO/IEC 9075-2:1999 (E)[2]....calls them "tables" Outside of didactic simplifications or domain specific conventions I am not finding anything. I could be convinced otherwise...but as every real world practical RDBMS has to impose order of often multple tables to scale, through logs, cache etc...and as what everyone agrees is SQL has to support various transaction isolation levels which ensures that on a concrete implementation detail, that rows aren't unique, but that the special case of a membership function, expressly being an 'element' is supported in them all. Plus you only get DISTINCT with a candidate key, and by default SQL is using bags/multisets anyway...there is just to much undefined behavior with indistinct rows and so we avoid them but they are allowed. In fact, while useful for teaching and day to day use, you are actually violating the axiom of pairing, which is also used to construct the singleton's in modern ZFC. In fact AC is called the well-ordering axiom by some, expressly because it allows it. I think you are possibly confusing the absence of ordering from the users perspective? Either way I have provided actual cites and would appreciate the same, because I would rather learn where I am wrong than prove myself right. [0] https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf [1] http://webdam.inria.fr/Alice/pdfs/Chapter-1.pdf http://webdam.inria.fr/Alice/pdfs/Chapter-1.pdf [2] https://web.cecs.pdx.edu/~len/sql1999.pdf https://web.cecs.pdx.edu/~len/sql1999.pdf
  - 9rx 1y ago
    > Either way I have provided actual cites and would appreciate the same You did, but I am not sure why. Best to come to a discussion to discuss it yourself. If you have to rely on third-parties to write for you, why bother participating at all? But, for the sake of trying to demonstrate good faith, I'll break my rule of not providing citations this once and give you this: Codd, E.F. (1988) Fatal Flaws in SQL: "Relations in the relational model and in mathematics do not have duplicate rows." In contrast, SQL does have duplicate rows, as Codd defines that. Hence why we call what SQL has "tables" instead of "relations", even though at the end of the day they serve the same purpose. SQL is unquestionably inspired by the relational model, but it, itself, is not relational as Codd saw it. If you want to still call it as such, go nuts! You can call it a "flying monkey" for all anyone cares. But, if you do call SQL relational, I am interested in what you would call a database that does adhere strictly to Codd's model since also calling it relational wouldn't paint an accurate picture. There are clear differences, as you even told earlier.

9rx 1y ago

No. You are getting confused by semantics. It is understood that definitions are just made up on the spot and anyone can define anything however they like. That was never in question. However, we are specifically talking about Codd. His definition for the relational model does not match anything we use today. Tablational databases are something quite different. So, sure, you can call what I call dynamically-typed languages statically-typed if you want. You're not wrong. Definitions cannot be wrong, fundamentally. But it is different, and since we're not talking about your definition and never were...

nyrikki 1y ago
From [0] which is Codd justifying it explicitly. > The term relation is used here in its accepted mathematical sense. Given sets S_1, S_2, ..., S_n (not necessarily distinct), R is a relation on these n sets if it is a set of ntuples each of which has its first element from S_1, its second element from S_z , and so on.’ We shall refer to S_i as the jth domain of R. Note the "(not necessarily distinct)" part and how he uses a table to describe it on the same page. From what is called the "Alice book" Foundations of Databases - Abiteboul, Hull, Vianu[1] the seminal textbook in database theory. > In the 1970s, Codd’s relational model revolutionized the field. In this model, humans view the data as organized in relations (tables), and more “declarative” languages are provided for data access. Unfortunately I can't find chapter 3, where the relational model is described in detail online. But for more concrete SQL as defined in ISO/IEC 9075-2:1999 (E)[2]....calls them "tables" Outside of didactic simplifications or domain specific conventions I am not finding anything. I could be convinced otherwise...but as every real world practical RDBMS has to impose order of often multple tables to scale, through logs, cache etc...and as what everyone agrees is SQL has to support various transaction isolation levels which ensures that on a concrete implementation detail, that rows aren't unique, but that the special case of a membership function, expressly being an 'element' is supported in them all. Plus you only get DISTINCT with a candidate key, and by default SQL is using bags/multisets anyway...there is just to much undefined behavior with indistinct rows and so we avoid them but they are allowed. In fact, while useful for teaching and day to day use, you are actually violating the axiom of pairing, which is also used to construct the singleton's in modern ZFC. In fact AC is called the well-ordering axiom by some, expressly because it allows it. I think you are possibly confusing the absence of ordering from the users perspective? Either way I have provided actual cites and would appreciate the same, because I would rather learn where I am wrong than prove myself right. [0] https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf [1] http://webdam.inria.fr/Alice/pdfs/Chapter-1.pdf http://webdam.inria.fr/Alice/pdfs/Chapter-1.pdf [2] https://web.cecs.pdx.edu/~len/sql1999.pdf https://web.cecs.pdx.edu/~len/sql1999.pdf
- 9rx 1y ago
  > Either way I have provided actual cites and would appreciate the same You did, but I am not sure why. Best to come to a discussion to discuss it yourself. If you have to rely on third-parties to write for you, why bother participating at all? But, for the sake of trying to demonstrate good faith, I'll break my rule of not providing citations this once and give you this: Codd, E.F. (1988) Fatal Flaws in SQL: "Relations in the relational model and in mathematics do not have duplicate rows." In contrast, SQL does have duplicate rows, as Codd defines that. Hence why we call what SQL has "tables" instead of "relations", even though at the end of the day they serve the same purpose. SQL is unquestionably inspired by the relational model, but it, itself, is not relational as Codd saw it. If you want to still call it as such, go nuts! You can call it a "flying monkey" for all anyone cares. But, if you do call SQL relational, I am interested in what you would call a database that does adhere strictly to Codd's model since also calling it relational wouldn't paint an accurate picture. There are clear differences, as you even told earlier.