4 ms·

Dude, noblethrasher, what you just said does not make sense. I have no idea what it means or how to parse it.

silentbicycle 17y ago
I think what he's saying is that a relation can be seen as a function that returns whether or not something is present, rather than a set of the results. I think.
noblethrasher 17y ago
My bad. Suppose I want to define a function that squares integers. Well, I can either define it as a formula: Square i => i * i or I can list all of the integers in a table 1 1 2 4 3 9 4 16 etc... Both of those are perfectly valid definitions for the Square function. The signature of the function is Int -> Int. If a row is listed more than once (e.g. the row 3 9) it still doesn't affect the definition of my function. 3 still maps to 9. Now suppose I want to define a relation (remember, a relation is a function) of employees that work in my company. In a typical RDMS I might create an Employee "table" with the following schema: emp_id, first_name, last_name. The signature of this function is Int -> String -> String -> Bool It just so happens that people (tuples) explicitly listed in the table map to true and anyone else maps to false. Conceptually it's the same as if I had a function called Employees where I could do something like this: Employees(12, 'bob', 'morton') which would return true or false depending on whether or not Mr. Morton is an employee in the company. The difference is that in SQL, what is returned is not the result of the function but the definition of the function itself which just happens to look like... a table.
- davidmathers 17y ago
  remember, a relation is a function That's backwards. In a Venn diagram relations are the big circle and functions are the smaller circle inside it. A function is a deterministic relation. If you mean to say a table is a function, then yes. All relations, including functions, can be represented using a table. If a row is listed more than once (e.g. the row 3 9) it still doesn't affect the definition of my function. 3 still maps to 9. This is the issue really. I think what you're saying is: {1,2,3,3} == {1,2,3} That's true mathematically, but that's not what's happening in SQL. Try creating the table to represent the square function. Now try inserting (3,9) into it twice. SQL won't let you because it forces tables to represent relations. Not queries though. In my example {1,2,3} is the direct representation of the value of the set and {1,2,3,3} is a different representation. The tables and queries in SQL are direct representations. If a SQL query looks like |1|2|3|3| then what you actually have, mathematically, is {{1,2,3},{3}}, aka multi-set or bag. {{1,2,3},{3}} != {1,2,3} That's what's happening when a row is listed more than once. It does affect the definition of your function.
  - noblethrasher 17y ago
    > That's backwards. In a Venn diagram relations are the big circle and functions are the smaller circle inside it. A function is a deterministic relation. That's partially right. In a Venn diagram, whenever you see a little circle S contained in a big circle T what you have is a relation that says S is a subset of T. Specifically this is a relation that maps a set of sets to {TRUE, FALSE}. Fundamentally we have sets and mappings[1] between sets. A relation is a mapping between some set and a set of logical values. So relations are mappings but not all mappings are relations. In the case of SQL a relation is a well-defined mapping so we call it a 'function'. > If a SQL query looks like |1|2|3|3| then what you actually have, mathematically, is {{1,2,3},{3}}, aka multi-set or bag. No sir. What you have, formally, is a programmatically generated relation/function (under a closed-world assumption) in which one of the entries in the mapping has been overly specified. Your relation maps the set {1,2,3, 4 ...} to the set {TRUE, FALSE}. If you pass it the value 1 or 2 or 3 you get TRUE. If you pass it the value 4 you get FALSE. The domain of this function is {1,2,3, 4, ...} and the codomain (or range) is {TRUE, FALSE}. Having an entry listed twice in the definition is similar to the following: f(x) = 0 when x = 0 and x * x if x is real. That function has been overly specified. Now if we had a table with entries like this: 1 Fred Jones 2 James Smith 3 Jane Doe 4 Alice Baker 3 George Washington then we have a problem since the 'function' is now ambiguous (and hence not a function). Now, back to my employee table example. If I have a table called Employees defined as: EMP_ID (int), FIRST_NAME (string), LAST_NAME (string) where EMP_ID is the primary key then what I have is a composition of functions (a relation in SQL is always a function) One function, we'll call it G maps full names to Integers and has this 'signature': S x S -> Z where S is the set of strings and Z is the set of integers. The other function, we'll call it H maps Integers to {TRUE, FALSE} so my table is actually equivalent to the function H of G. Now I realize that this is all abstract and a bit pedantic but it is nonetheless what SQL and relational algebra are all about even if we don't ordinarily think of it like this. [1] Formally, mappings, functions, transformations and operations are all the same things just used in specific contexts.

I think what he's saying is that a relation can be seen as a function that returns whether or not something is present, rather than a set of the results. I think.

noblethrasher 17y ago

My bad. Suppose I want to define a function that squares integers. Well, I can either define it as a formula: Square i => i * i or I can list all of the integers in a table 1 1 2 4 3 9 4 16 etc... Both of those are perfectly valid definitions for the Square function. The signature of the function is Int -> Int. If a row is listed more than once (e.g. the row 3 9) it still doesn't affect the definition of my function. 3 still maps to 9. Now suppose I want to define a relation (remember, a relation is a function) of employees that work in my company. In a typical RDMS I might create an Employee "table" with the following schema: emp_id, first_name, last_name. The signature of this function is Int -> String -> String -> Bool It just so happens that people (tuples) explicitly listed in the table map to true and anyone else maps to false. Conceptually it's the same as if I had a function called Employees where I could do something like this: Employees(12, 'bob', 'morton') which would return true or false depending on whether or not Mr. Morton is an employee in the company. The difference is that in SQL, what is returned is not the result of the function but the definition of the function itself which just happens to look like... a table.

davidmathers 17y ago
remember, a relation is a function That's backwards. In a Venn diagram relations are the big circle and functions are the smaller circle inside it. A function is a deterministic relation. If you mean to say a table is a function, then yes. All relations, including functions, can be represented using a table. If a row is listed more than once (e.g. the row 3 9) it still doesn't affect the definition of my function. 3 still maps to 9. This is the issue really. I think what you're saying is: {1,2,3,3} == {1,2,3} That's true mathematically, but that's not what's happening in SQL. Try creating the table to represent the square function. Now try inserting (3,9) into it twice. SQL won't let you because it forces tables to represent relations. Not queries though. In my example {1,2,3} is the direct representation of the value of the set and {1,2,3,3} is a different representation. The tables and queries in SQL are direct representations. If a SQL query looks like |1|2|3|3| then what you actually have, mathematically, is {{1,2,3},{3}}, aka multi-set or bag. {{1,2,3},{3}} != {1,2,3} That's what's happening when a row is listed more than once. It does affect the definition of your function.
- noblethrasher 17y ago
  > That's backwards. In a Venn diagram relations are the big circle and functions are the smaller circle inside it. A function is a deterministic relation. That's partially right. In a Venn diagram, whenever you see a little circle S contained in a big circle T what you have is a relation that says S is a subset of T. Specifically this is a relation that maps a set of sets to {TRUE, FALSE}. Fundamentally we have sets and mappings[1] between sets. A relation is a mapping between some set and a set of logical values. So relations are mappings but not all mappings are relations. In the case of SQL a relation is a well-defined mapping so we call it a 'function'. > If a SQL query looks like |1|2|3|3| then what you actually have, mathematically, is {{1,2,3},{3}}, aka multi-set or bag. No sir. What you have, formally, is a programmatically generated relation/function (under a closed-world assumption) in which one of the entries in the mapping has been overly specified. Your relation maps the set {1,2,3, 4 ...} to the set {TRUE, FALSE}. If you pass it the value 1 or 2 or 3 you get TRUE. If you pass it the value 4 you get FALSE. The domain of this function is {1,2,3, 4, ...} and the codomain (or range) is {TRUE, FALSE}. Having an entry listed twice in the definition is similar to the following: f(x) = 0 when x = 0 and x * x if x is real. That function has been overly specified. Now if we had a table with entries like this: 1 Fred Jones 2 James Smith 3 Jane Doe 4 Alice Baker 3 George Washington then we have a problem since the 'function' is now ambiguous (and hence not a function). Now, back to my employee table example. If I have a table called Employees defined as: EMP_ID (int), FIRST_NAME (string), LAST_NAME (string) where EMP_ID is the primary key then what I have is a composition of functions (a relation in SQL is always a function) One function, we'll call it G maps full names to Integers and has this 'signature': S x S -> Z where S is the set of strings and Z is the set of integers. The other function, we'll call it H maps Integers to {TRUE, FALSE} so my table is actually equivalent to the function H of G. Now I realize that this is all abstract and a bit pedantic but it is nonetheless what SQL and relational algebra are all about even if we don't ordinarily think of it like this. [1] Formally, mappings, functions, transformations and operations are all the same things just used in specific contexts.