8 ms·

> Relational databases get their name from the fact that relationships can be defined between tables. This is a widespread misconception. Relational databases

by taffer 7y ago

> Relational databases get their name from the fact that relationships can be defined between tables. This is a widespread misconception. Relational databases get their name from relations in the mathematical sense[1], i.e. sets of tuples containing facts. The basic idea of the relational model is that logical predicates can be used to query data flexibly without having to change the underlying data structures. The basic paper by Codd[2] is really worth reading and describes, among other things, the problems of hierarchical and network databases that the relational model is meant to solve. [1] https://en.wikipedia.org/wiki/Finitary_relation https://en.wikipedia.org/wiki/Finitary_relation [2] https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf

nikolasburk 7y ago
Thanks for the hint, we'll update the article! :)
- triska 7y ago
  Related to the logical view, it would also be great to include deductive databases: https://en.wikipedia.org/wiki/Deductive_database https://en.wikipedia.org/wiki/Deductive_database Deductive databases derive logical consequences based on facts and rules. Datalog and its superset Prolog are notable instances of this idea, and they make the connection between the relational model and predicate logic particularly evident. Codd's 1979 paper Extending the Database Relational Model to Capture More Meaning contains additional information about this connection. For example, quoting from Section 3 Relationship to Predicate Logic: "We now describe two distinct ways in which the relational model can be related to predicate logic. Suppose we think of a database initially as a set of formulas in first-order predicate logic. ..."
  - mitchtbaum 7y ago
    It seems these rules refine the data outside the database itself. But they're so tightly integrated between the database and the application that the lines separating them become blurred.
    - triska 7y ago
      Interestingly, when defining pure relations in Prolog, there is no "outside the database itself": Both rules and facts are instances of a single unifying language element, a logical clause, which is also terminology from predicate logic. This is useful from a conceptual perspective, and also for performance: Many automatic optimizations that deductive database systems perform apply equally to facts and rules. For instance, argument indexing is a notable feature of virtually all Prolog systems. It is similar to indices in relational databases, and can replace a linear scan of the knowledge base with a fast hash-based lookup that is performed in O(1).
      - mitchtbaum 7y ago
        > Both rules and facts are instances of a single unifying language element, a logical clause, which is also terminology from predicate logic. Yeah; I'd like to see these general application layers more seamless and united in simple semantic units. Like a higher level abstraction over code block elements, database record structures, and configuration setting ensambles; simply as phrases (..??) ....
        mitchtbaum 7y ago
        https://en.wikipedia.org/wiki/Seme_(semantics) https://en.wikipedia.org/wiki/Seme_(semantics) https://www.youtube.com/watch?v=AcU6qAmAqpI https://www.youtube.com/watch?v=AcU6qAmAqpI
tlarkworthy 7y ago
What is the relation? The table? (I.e. the tuples describing the rows). Or is it the joins? (In which case the article is correct). The columns?
- taffer 7y ago
  The table is the relation. A join is just an operation that combines two relations to a superrelation.
  - Pheebau 7y ago
    A join in an intersection in relational algebra
    - namanyayg 7y ago
      Not necessarily, it can be a union too? Depends on the type of join.
      - kthejoker2 7y ago
        A union is not a join at all - a union is a union. They're different concepts entirely.
    - Darkphibre 7y ago
      Oh, wow. I've been in the industry for over 20 years. I even worked on SQL Server Analysis Services for 5 years (up to 256-dimensional 'cubes' in the early 2000s)... and I never thought of joins in this way. Granted, MDX was a beast in its own right. Cue discussion about self-taught vs college educations. I've got advantages being self-driven learner... but I've definitely missed out in some regards.
      - greggyb 7y ago
        MDX isn't a relational language, though. It's a dimensional language. The best short description I can give about MDX is that it's the language your pedantic uncle would come up with after falling in love with Ralph Kimball, when all he knew to base it on was SQL. But the core operations in MDX operate upon hierarchical dimensions and facts that can be aggregated. SELECT ... FROM ... WHERE has no inherent relational semantic. It is simply a syntax that has been standardized upon for interacting with relational database systems. It was also, coincidentally, chosen as the syntax for another language, MDX. Funny enough, the successor to SSAS Multidimensional is SSAS Tabular, where the query language is DAX. DAX was designed with an explicit goal of looking like Excel's formula language, but it is in fact a relational language which is semantically very similar to SQL, despite looking nothing like it.

by taffer 7y ago

nikolasburk 7y ago

Thanks for the hint, we'll update the article! :)

triska 7y ago
Related to the logical view, it would also be great to include deductive databases: https://en.wikipedia.org/wiki/Deductive_database https://en.wikipedia.org/wiki/Deductive_database Deductive databases derive logical consequences based on facts and rules. Datalog and its superset Prolog are notable instances of this idea, and they make the connection between the relational model and predicate logic particularly evident. Codd's 1979 paper Extending the Database Relational Model to Capture More Meaning contains additional information about this connection. For example, quoting from Section 3 Relationship to Predicate Logic: "We now describe two distinct ways in which the relational model can be related to predicate logic. Suppose we think of a database initially as a set of formulas in first-order predicate logic. ..."
- mitchtbaum 7y ago
  It seems these rules refine the data outside the database itself. But they're so tightly integrated between the database and the application that the lines separating them become blurred.
  - triska 7y ago
    Interestingly, when defining pure relations in Prolog, there is no "outside the database itself": Both rules and facts are instances of a single unifying language element, a logical clause, which is also terminology from predicate logic. This is useful from a conceptual perspective, and also for performance: Many automatic optimizations that deductive database systems perform apply equally to facts and rules. For instance, argument indexing is a notable feature of virtually all Prolog systems. It is similar to indices in relational databases, and can replace a linear scan of the knowledge base with a fast hash-based lookup that is performed in O(1).
    - mitchtbaum 7y ago
      > Both rules and facts are instances of a single unifying language element, a logical clause, which is also terminology from predicate logic. Yeah; I'd like to see these general application layers more seamless and united in simple semantic units. Like a higher level abstraction over code block elements, database record structures, and configuration setting ensambles; simply as phrases (..??) ....
      - mitchtbaum 7y ago
        https://en.wikipedia.org/wiki/Seme_(semantics) https://en.wikipedia.org/wiki/Seme_(semantics) https://www.youtube.com/watch?v=AcU6qAmAqpI https://www.youtube.com/watch?v=AcU6qAmAqpI

tlarkworthy 7y ago

What is the relation? The table? (I.e. the tuples describing the rows). Or is it the joins? (In which case the article is correct). The columns?

taffer 7y ago
The table is the relation. A join is just an operation that combines two relations to a superrelation.
- Pheebau 7y ago
  A join in an intersection in relational algebra
  - namanyayg 7y ago
    Not necessarily, it can be a union too? Depends on the type of join.
    - kthejoker2 7y ago
      A union is not a join at all - a union is a union. They're different concepts entirely.
  - Darkphibre 7y ago
    Oh, wow. I've been in the industry for over 20 years. I even worked on SQL Server Analysis Services for 5 years (up to 256-dimensional 'cubes' in the early 2000s)... and I never thought of joins in this way. Granted, MDX was a beast in its own right. Cue discussion about self-taught vs college educations. I've got advantages being self-driven learner... but I've definitely missed out in some regards.
    - greggyb 7y ago
      MDX isn't a relational language, though. It's a dimensional language. The best short description I can give about MDX is that it's the language your pedantic uncle would come up with after falling in love with Ralph Kimball, when all he knew to base it on was SQL. But the core operations in MDX operate upon hierarchical dimensions and facts that can be aggregated. SELECT ... FROM ... WHERE has no inherent relational semantic. It is simply a syntax that has been standardized upon for interacting with relational database systems. It was also, coincidentally, chosen as the syntax for another language, MDX. Funny enough, the successor to SSAS Multidimensional is SSAS Tabular, where the query language is DAX. DAX was designed with an explicit goal of looking like Excel's formula language, but it is in fact a relational language which is semantically very similar to SQL, despite looking nothing like it.