<HOME　　<お願い事項　　 <Access2002 TOP　　　<Access2000 TOP　　　<サイト内検索
MS-Access97大魔法陳列棚＞行と列を入れ替える

【仕　様　な　ど】MS-Access97で作成。Windows95でのみ動作確認。

【ダウンロード】←Zip形式
　　　　　　　　　　　　（解凍後、mdb初期状態：およそ192kb）

【主　な　機　能】

テーブルの「列」と「行」を入れ替えるプロシージャです。

【作　り　方　等】

はっきり言って、Accessらしからぬ処理。こういうことをしなければならないこと自体、システムの作り方を見直すべきではないかと思うんです。

Accessには「列」「行」の概念はないと考えた方がよいでしょう。確かにテーブルは開くと表の形をしています。でも、フィールドは「列」とは違います。レコードも「行」ではなく、その辺はうまく見極めてテーブルを設計していく必要があるでしょう。

と、いっても、やむをえないときもあるでしょう。
テーブルの内容を見て、その都度別のテーブルを作成するプロシージャを書きました。

例えば表計算ソフトのようなものから、データをインポートしてきたとしましょう。
表計算ソフトは、縦横自由にセルを使うことができるので、手軽にデータ入力ができますね。

下の表は、横にとても長い表です。緑色のところが項目名。1989年1月から約10年間、それぞれ毎月数値を入力して、9行目に集計しています。1999年の12月までマスを取っているので、A列を除いて数値の列だけ数えると、132列、横に長い表になっています。

まあ、ExcelやLotus1-2-3は、シートを分割したりすることもできますから、横にいくら長くても入力しにくいってことはないですね。Excelなら横に256列ありますから、あと10年は大丈夫ですね。

こういうふうに横に長い表にデータ入力していらっしゃる方も多いと思います。表計算ソフトだったら、これでいいんです。むしろこの方が便利だと思います。表計算ソフトを使ってデータ入力をするなら。

え？上の表は何の表かって？えーと、ふ、ふり逃げした回数です。少年野球とか高校野球とかの時期も含めて。

さて、上記のような表を、Accessに移行したい、と、ただなんとなく思いついたとき、問題は発生します。まずそのまんまインポートしてきたときのことを想像してください。

こういうテーブルになりそうですよね。1行目をフィールド名としてインポートしてみました。

このテーブルのデザインを見ると、

こうですね。こうなります。

フィールドの数が133個。来年末だと、145個になってるのかな・・・。1年で12フィールドずつ増えることになるわけですね。

まあ、テーブルは256までフィールドを持つことができますから、どうってことないですけども・・・。

でも、ここにたまったデータに、未来はありますか？このテーブルを利用して、ここにデータを入力して、いったいなにをします？クエリーで集計？レポートに印刷？

ふつう、テーブルというものは縦に伸びますよね。レコードがどんどんたまるんです。フィールドがどんどん増えて横に伸びるテーブルなんて、ちょっとどうかと思いますけどねぇ。

でも、よそのアプリケーションからデータを移行してきたり、あるいはこのExcelのワークシートを常にテーブルリンクして使わなきゃいけないとか、最悪な状況も多々ありえると思います。
できれば、Accessの本来の性質や、リレーショナルデータベースとしての能力を発揮できるような構造に、つまり縦方向にデータが伸びていくような形に考え直すのが理想だと思うんですけれどね。

テーブル構造では、フィールド定義はほぼ固定です。あとでフィールドをチョコっと追加したりすることはあるかもしれませんが、フィールドを後から追加すると、当然既存の入力データに関してはNull値になってしまいますし、あまりいいことはありません。

項目が増えたり減ったり定まらないような表示や帳票なら、Accessでなくて表計算ソフトをうまく活用すべきだと思います。

で、バカを承知で、「行と列の入れ替え」をやってみました。ある目的で作ったんですが、そこそこの動きは取ると思いますので、表計算ソフトからのデータの移行などを考えておられる方に参考にしていただければと思います。

上記のような横に長いテーブルを基に、下のようなテーブルをその都度新規に作成します。

上記テーブルの「フィールド名」を拾って［月度］というフィールドの中の1レコードとして格納し、［名前］フィールドの中身をばらして「フィールド」に置き換えます。

いわゆる「行と列の入れ替え」っぽいですよね。

これもあんまりいいテーブル構造じゃないかもしれないですが。。。
今回はとりあえず［月度］は数値型フィールドとして拾っています。日付/時刻型にする必要があるなら、プロシージャを少し変更する必要があります。

もっとAccessっぽいテーブル構造にするとしたら、下のようなテーブルに書き出すことになるかもしれませんね。

こちらは、あらかじめ［テーブルC］という名前のテーブルを作ってあり、そこに基のテーブルからデータを書き出すようにしています。

このテーブルなら、縦方向にどんどん伸びる構造で、フィールドの数を増やしたりしなくても必要なデータを書き込むことができますよね。

［年月］と［名前］を両方主キーにしているので、こんな並び順になります。

こういうことが、設計段階で明確になっていればめんどうはないんですけどね。なかなかそうはいかないですよね。