Funny that no one seems to mention Date's "SQL and relational theory : How to write accurate SQL code".
Most of the answers here are on the right track. However, a row is not a tuple. Tuples* are unordered sets of known values with names. Thus, the following tuples are the same thing (I'm using an imaginary tuple syntax since a relational tuple is largely a theoretical construct):
(x=1, y=2, z=3)
(z=3, y=2, x=1)
(y=2, z=3, x=1)
...assuming of course that x, y, and z are all integers. Also note that there is no such thing as a "duplicate" tuple. Thus, not only are the above equal, they're the same thing. Lastly, tuples can only contain known values (thus, no nulls).
A row** is an ordered set of known or unknown values with names (although they may be omitted). Therefore, the following comparisons return false in SQL:
(1, 2, 3) = (3, 2, 1)
(3, 1, 2) = (2, 1, 3)
Note that there are ways to "fake it" though. For example, consider this INSERT statement:
INSERT INTO point VALUES (1, 2, 3)
Assuming that x is first, y is second, and z is third, this query may be rewritten like this:
INSERT INTO point (x, y, z) VALUES (1, 2, 3)
INSERT INTO point (y, z, x) VALUES (2, 3, 1)
...but all we're really doing is changing the ordering rather than removing it.
And also note that there may be unknown values as well. Thus, you may have rows with unknown values:
(1, 2, NULL) = (1, 2, NULL)
...but note that this comparison will always yield UNKNOWN. After all, how can you know whether two unknown values are equal?
And lastly, rows may be duplicated. In other words, (1, 2) and (1, 2) may compare to be equal, but that doesn't necessarily mean that they're the same thing.
If this is a subject that interests you, I'd highly recommend reading SQL and Relational Theory: How to Write Accurate SQL Code by CJ Date.
* Note that I'm talking about tuples as they exist in the relational model, which is a bit different from mathematics in general.
**And just in case you're wondering, just about everything in SQL is a row or table. Therefore, (1, 2) is a row, while VALUES (1, 2) is a table (with one row).
VALUES (1, 2)
UPDATE: I've expanded a little bit on this answer in a blog post here.
If you want to learn about what relational means, I recommend the book "SQL and Relational Theory" by C. J. Date.
Relational in this context doesn't refer to relationships. It refers to relations which are basically what tables are called in the mathematical theories that led to the relational model.
The reason that relational databases have become ubiquitous is that they are the most general-purpose solution for organizing data with minimum redundancy.
There are valid reasons to use non-relational solutions. They often solve specific tasks of data-management extremely well, but are weak in other areas. Whereas SQL and relational databases strike a compromise, solving a larger set of problems adequately, with fewer areas of weakness.
Other technologies currently available that are not based on the relational model are listed in "The Next-Gen Databases."