4 ms·

No, the real meaning of a relation is the intended interpretation it was given when it was designed (and which is also the criterion by which the database user

No, the real meaning of a relation is the intended interpretation it was given when it was designed (and which is also the criterion by which the database user decides whether a tuple should be present or not, thus by which the database user decides which updates to carry through).

catnaroek 10y ago
> intended interpretation The DBMS doesn't read your mind before interpreting relations. It interprets relations according to its own data integrity enforcement rules. Most programmers are used to expecting language constructs to mean what a human would mean (“I called my class `Customer`, so of course its instances are customers, right?”), but the formal semantics of the language in question seldom, if ever, justifies this. If you want to establish that your code means what you mean, you have to prove it. For more information: https://en.wikipedia.org/wiki/Semantics_(computer_science) https://en.wikipedia.org/wiki/Semantics_(computer_science)
- dragonwriter 10y ago
  > The DBMS doesn't read your mind before interpreting relations. The DBMS doesn't interpret relations at all. It performs relational operations on them; humans interpret them (often using other software as a tool to present an interpretation.) > Most programmers are used to expecting language constructs to mean what a human would mean (“I called my class `Customer`, so of course its instances are customers, right?”), but the formal semantics of the language in question seldom, if ever, justifies this. Which "language in question". If you mean the DB query language, that's true. OTOH, in a sense, most programming involves creating specialized languages (often layered on top of existing languages) with their own (in the layered case, additional) semantics. In the constructed language of a particular library or database, that the instances of a Customer class or members of a Customer relation are representations of customers is part of the semantics of that language, even if it isn't part of the semantics of the host language.
  - catnaroek 10y ago
    > The DBMS doesn't interpret relations at all. It performs relational operations on them; humans interpret them (often using other software as a tool to present an interpretation.) A database schema is a multisorted axiomatic system (each base relation is its own sort), of which the database's state is a model (in the logician's sense: a concrete interpretation of a theory). Unlike the interpretation in your head, whose only justification is your personal wishes, the DBMS' interpretation is backed by a concrete formal system: the language in which your database schema is expressed. > In the constructed language of a particular library or database, that the instances of a Customer class or members of a Customer relation are representations of customers is part of the semantics of that language, even if it isn't part of the semantics of the host language. This is only true if you can actually prove that your database or program's “Customers” actually behave like customers in your problem domain.
- ErwinSmout 10y ago
  The DBMS doesn't read your mind before interpreting relations. Which is why the real interpretation happens outside the DBMS. And which is also why the DBMS needs "help" from its users when deciding whether TUPLE{} represents "The shop is closed" and should go in THE_SHOP_IS_CLOSED rather than "The alarm is set" and should go in THE_ALARM_IS_SET. It interprets relations according to its own data integrity enforcement rules. If this is your way of saying that the only thing a DBMS does (and can ever be expected to do) is algebraic computation (e.g. to verify constraint satisfaction of a given update to a given existing db state), completely devoid of any form of "interpretation" in the sense of "human interpretation", I agree. Hell, it's why those things were called "computers". They compute. Nothing more.
  - catnaroek 10y ago
    > Which is why the real interpretation happens outside the DBMS. Unfortunately, computer programs mean what they actually do, not what you wish they did. The field of formal semantics of programming languages exists to study the real meaning of programming languages, not the “intended” one, whatever the latter might be. > If this is your way of saying that the only thing a DBMS does (and can ever be expected to do) is algebraic computation (e.g. to verify constraint satisfaction of a given update to a given existing db state) The programmer is expected to make the DBMS enforce business rules. A database schema is a model (in the informal, everyday sense of the word) of the real world to the extent the real world's rules are enforced constraints in the schema. Otherwise, it's just wishful thinking.
    - ErwinSmout 10y ago
      I thought it was the database designer. But OK, maybe that's just semantics and I'm not very good at those.
      - catnaroek 10y ago
        The database designer is a programmer, and the DBMS's data definition language is a programming language.
sgeneris 10y ago
Unless it is possible for a RDBMS to make that decision instead of relying on the users as we know them to be. Which it is, but just because people are working in the db field without an ounce of introduction to logic is not good enough reason to defend reliance on user discipline.

catnaroek 10y ago

> intended interpretation The DBMS doesn't read your mind before interpreting relations. It interprets relations according to its own data integrity enforcement rules. Most programmers are used to expecting language constructs to mean what a human would mean (“I called my class `Customer`, so of course its instances are customers, right?”), but the formal semantics of the language in question seldom, if ever, justifies this. If you want to establish that your code means what you mean, you have to prove it. For more information: https://en.wikipedia.org/wiki/Semantics_(computer_science) https://en.wikipedia.org/wiki/Semantics_(computer_science)

dragonwriter 10y ago
> The DBMS doesn't read your mind before interpreting relations. The DBMS doesn't interpret relations at all. It performs relational operations on them; humans interpret them (often using other software as a tool to present an interpretation.) > Most programmers are used to expecting language constructs to mean what a human would mean (“I called my class `Customer`, so of course its instances are customers, right?”), but the formal semantics of the language in question seldom, if ever, justifies this. Which "language in question". If you mean the DB query language, that's true. OTOH, in a sense, most programming involves creating specialized languages (often layered on top of existing languages) with their own (in the layered case, additional) semantics. In the constructed language of a particular library or database, that the instances of a Customer class or members of a Customer relation are representations of customers is part of the semantics of that language, even if it isn't part of the semantics of the host language.
- catnaroek 10y ago
  > The DBMS doesn't interpret relations at all. It performs relational operations on them; humans interpret them (often using other software as a tool to present an interpretation.) A database schema is a multisorted axiomatic system (each base relation is its own sort), of which the database's state is a model (in the logician's sense: a concrete interpretation of a theory). Unlike the interpretation in your head, whose only justification is your personal wishes, the DBMS' interpretation is backed by a concrete formal system: the language in which your database schema is expressed. > In the constructed language of a particular library or database, that the instances of a Customer class or members of a Customer relation are representations of customers is part of the semantics of that language, even if it isn't part of the semantics of the host language. This is only true if you can actually prove that your database or program's “Customers” actually behave like customers in your problem domain.
ErwinSmout 10y ago
The DBMS doesn't read your mind before interpreting relations. Which is why the real interpretation happens outside the DBMS. And which is also why the DBMS needs "help" from its users when deciding whether TUPLE{} represents "The shop is closed" and should go in THE_SHOP_IS_CLOSED rather than "The alarm is set" and should go in THE_ALARM_IS_SET. It interprets relations according to its own data integrity enforcement rules. If this is your way of saying that the only thing a DBMS does (and can ever be expected to do) is algebraic computation (e.g. to verify constraint satisfaction of a given update to a given existing db state), completely devoid of any form of "interpretation" in the sense of "human interpretation", I agree. Hell, it's why those things were called "computers". They compute. Nothing more.
- catnaroek 10y ago
  > Which is why the real interpretation happens outside the DBMS. Unfortunately, computer programs mean what they actually do, not what you wish they did. The field of formal semantics of programming languages exists to study the real meaning of programming languages, not the “intended” one, whatever the latter might be. > If this is your way of saying that the only thing a DBMS does (and can ever be expected to do) is algebraic computation (e.g. to verify constraint satisfaction of a given update to a given existing db state) The programmer is expected to make the DBMS enforce business rules. A database schema is a model (in the informal, everyday sense of the word) of the real world to the extent the real world's rules are enforced constraints in the schema. Otherwise, it's just wishful thinking.
  - ErwinSmout 10y ago
    I thought it was the database designer. But OK, maybe that's just semantics and I'm not very good at those.
    - catnaroek 10y ago
      The database designer is a programmer, and the DBMS's data definition language is a programming language.

sgeneris 10y ago

Unless it is possible for a RDBMS to make that decision instead of relying on the users as we know them to be. Which it is, but just because people are working in the db field without an ounce of introduction to logic is not good enough reason to defend reliance on user discipline.