> 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

> 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.