A tuple is a fixed fixed-length list containing elements that need not have the same type. It can be, and often is, used as a key-value pair.

Technically, the name tuple is overloaded and denotes several distinct but very closely related concepts. So depending on the context one of the following definitions apply.
----
(1)

The most common used in general mathematics, database theory, etc.

'''Intuitive''' : a n-tuple is a composite with n elements. t = (x1, x2, ..., xn)

Formally a n-tuple is a function t: {1 .. n} -> U where U is a set (universe) of elements
----
(2)
In axiomatic set theory the above definition is typically not used because students are introduced to function as a special kind of relation and relation is a set of tuples. So the following technical trick is used:

 An '''ordered pair''' (2-tuple) denoted (a,b) is defined as the following set {{a},{a,b}}
 The following theorem is easy to verify: (a,b)=(a',b') <=> (a=a') /\ (b=b')
 An n-tuple (n>2) is the ordered pair t_n= (t_(n-1), x_n) where t_(n-1) is a (n-1_ -tuple

''Those of us who have been out of school for too long may not recognize what notations like "<=>" and "/\" mean. May I suggest a page called WikiAsciiMathSymbols.''

----
(3)

Database theory operates with two kinds of tuple (FoundationsOfDatabases calls the two approaches the named versus unnamed perspective. The unnamed perspective uses the first definition as it provides a slightly more convenient notation to prove some theorems.

In addition, DrCodd decorated (just like in DecoratorPattern) the unnamed tuple with column names. So instead of referring to tuple components by their index, we refer them by names. Formally we can consider a tuple a function 
  t: Column_Names -> U 
where Column_Names is a set of names (strings) and U is the universe of simple (scalar) values. This can further be decorated with domains by associating a column_name with a domain of values, so that each column value belongs to a particular domain defined for that column.
 t(column) '''in''' domain_of(column)

This later definition is particularly useful in programming, as information items are better access by their names as
in employee.employee_id rather than an arbitrary index (employee[1]).

''It should be pointed out that in relational theory, more than just decoration is going on. By the act of decoration, the order of elements within a tuple no longer matters -- tuples in the RelationalModel are held to be unordered.''

Actually, functions are like that by definition. So even under the first definition tuples are unordered, it's only in the notation or possibly within an implementation inside a computer that tuples are thought to be ordered. In any case the same can be said about the named perspective: you can introduce an order of components defined by the lexicographical order of column names. 

However this point is worth mentioning since SQL being what it is (not very faithful to RelationalModel) made the order of columns important, so if two tables do not have the same exact order of columns they are "type incompatible" in SQL so:
 (select id,name from x)
  union
 (select name,id from y)
is illegal in SQL. 

Which is particularly strange (they mix the named and unnamed perspective in the same ball of wax) and sometimes annoying in complex database schemas, where different views may have slightly different column orders and then when thy need to be put back together it breaks unless you explicitly re-order the columns.

''It is a trade-off. Order-based is easier for some situations and name-based is easier for others. Perhaps if SQL had better intermediate (virtual) table abilities, then it may tilt the other way. -- top''
----

Discussion:

Some old discussion is TupleDefinitionDiscussion. In particular, TopMind is adamant that tuples can be equated with dictionary data structures (as in Perl for example) suggesting they are just different views of the same thing.