Awk言語によるプログラムでは、必ずというわけではないが たいてい、 入力データが「表 (table)」とよばれる論理的構造をもつことを想定している。 この「表」の概念は、「関係 (relational) データベース」の理論に出てくるのと同じである。 これは偶然ではない。 Awk言語は、Unixオペレーティングシステムといっしょに発達してきた。 そしてUnixは、関係データベースを、システム管理に必要な情報をたくわえるのに使っている。
「表」の形は長方形だ。 これは、表が、升目(cell)が縦横にならんだ形で構成されていて、 横にのびるのを「行」、縦にのびるのを「列」とすれば、 どの列も同じ数の行をもち、どの行も同じ数の列をもつようになっているということだ。
複数の行にまたがるセルや、複数の列にまたがるセルをつくることは許されていない。 これはきびしい制約といえるかもしれない。 しかし、関係データベースの教科書では、 情報を「正規化」した構造の複数の表に構成しなおすことによって、 データの首尾一貫性が失われる危険を減らすことができ、 また、記憶容量を節約できることもたびたびある、と教えている。
実際は、わたしはデータを必ずしもこの意味で正規化せず、 いくつかの冗長な情報の列を残していることがある。 [行の部分的統合をするわけではなく、同じ情報をそれぞれの行に入れる。] たとえば、「観測地点番号」があれば「観測地点名」と「国」は一意的にきまるのならば、 データベースの教科書にしたがえば、 「観測地点名」と「国」は、観測値の表には入れず、 別の「観測地点リスト」の表にだけふくめるべきだ。 しかし、わたしはそのような論理的には冗長な情報を、 個別のデータ要素を [人が] 同定しやすくするために、表に入れることが多い。 (わたしはそのような表を目でチェックして、はずれ値を見つけることがたびたびある。 そのとき、それぞれの はずれ値が生じた日時と場所を知りたくなる。 そこで、地名が、別の正規化された表に置かれているよりも、 観測値の表自体にふくまれていたほうが、たすかるのだ。)
行と列のやくわりは対称的ではない。 列の順序は意味をもつ。 表のデータを使うプログラムが、列にそれぞれ区別できる名まえをつけて使うことが想定される。 行の順序は (原則として) 意味をもたない。 行の順序がいれかわっても、(原則として) 同じデータなのだ。 行は、(原則として) [表にあらわれる順序によってではなく] きまった列の内容、 あるいは複数のきまった列の内容のくみあわせによって、一意的に同定される。 これは、関係データベースでの表についての原則であって、 Awk で処理される表が必ずこの原則にしたがっているわけではない。 しかし、原則にしたがったほうがよいことが多い。