技術メモ：postgreSQLによるテーブル結合 遺物台帳テーブルと土錘テーブル

 Technical memo: Table join with PostgreSQL: Relic ledger table and soil weight table

I analyzed the correspondence between the relic ledger and soil weight list of the shell layer on the north slope of the Ariyoshi Kita Shell Mound using a table join with PostgreSQL. This was my first data analysis with PostgreSQL. I realized that the relic ledger names are nothing more than collection bag labels.

有吉北貝塚北斜面貝層の遺物台帳と土錘リストを対象に、postgreSQLによるテーブル結合でその対応関係を分析しました。自分にとって、postgreSQLによるはじめてのデータ分析です。遺物台帳名称が採集袋ラベルに過ぎないことがよくわかりました。

1　postgreSQLによる遺物台帳テーブルと土錘テーブルの結合

1-1　遺物台帳テーブル

現在（2024.07.30）の遺物台帳テーブルの項目（カラム）は次の通りです。データ数は64097です。

（わかりやすくするために日本語で表記しています。データベースでは英字略記で表記しています。）

・グリッド（文字表記）

・遺物番号（グリッド内の通し番号）

・遺物コード（グリッド-遺物番号の文字連続表記）

・グリッドコード2（数値表記）

・遺物コード2（数値表記）

・名称（文字表記）

・標高（小数点表記）

・貝層（文字表記）

・注記（文字表記）

・はみ出し移動前（文字表記）

・はみ出し移動後（文字表記）

・移動コード（数値表記）

・遺物分類コード（数値表記）

1-2　土錘テーブル

土錘テーブルの項目は次の通りです。データ数は960です。

・遺物コード2（数値表記）

・土錘数（数値表記）

発掘調査報告書掲載土錘リストは個別土錘リスト（1090）です。このリストから遺物コード2で土錘数を集計した資料がこの土錘テーブルです。

1-3　postgreSQLによる遺物台帳テーブルと土錘テーブルの内部結合

postgreSQLのクエリで遺物台帳テーブルと土錘テーブルの内部結合主キー「遺物コード2」で行い、「遺物台帳対応土錘テーブル」を派生させました。

●「遺物台帳対応土錘テーブル」

・遺物コード2（数値表記）

・名称（文字表記）

・土錘数（数値表記）

pgAdmin4画面（テーブル結合の様子）

pgAdmin4はpostgreSQLのGUIです。

2　派生テーブル「遺物台帳対応土錘テーブル」の検討

2-1　データ数の減少

土錘テーブルのデータ数は960でしたが、テーブル結合した後の「遺物台帳対応土錘テーブル」のデータ数は940に減少しました。

このデータ減少を詳しく検討したところ、次の要因によるものであることがわかりました。

1　土錘テーブル（発掘調査報告書土錘リスト由来データ）の遺物コード2には、出土グリッドは判明しているが、遺物番号が無いものがあり、それに遺物コード2仮番を付けていたものがあるため。（8件）

2　発掘調査報告書土錘リストから生成される遺物コードに実在しないものが含まれているため（おそらく錯誤による作業ミス）。（12件）

結果として、土錘テーブル（全960件）のうち940件（97.92％）が遺物台帳との対応で使えることがわかりました。

2-2　土錘と遺物台帳名称との対応

土錘と遺物台帳名称との対応の概要は次のようになりました。

土錘（現物）がリンクしている遺物台帳名称

現場で土錘として取り上げられた件数（遺物番号の数）は437件で46.5％、土器として取り上げられたものが471件で50.1％、その他の名称で取り上げられたもの32件で3.4％ということになります。

土器として取り上げられたものとは、ほとんどの場合土器片多数を一括で取り上げ、1つの遺物番号をつけた採集袋の中にいれられた状況があり、後日その採集袋の土器片を分析するなかで土錘も見つかったと考えることができます。

石器、骨、貝、鱗、貝サンプルも同じく、それらの名称に該当する品が納められた採集袋の中から、後日土錘が見つかったという状況が考えられます。

2-3　標高データのあるものは64.4％

遺物台帳では「〇〇一括」と書かれたものは標高データがありません。その件数を「遺物台帳対応土錘テーブル」で集計すると335件となります。従って940-335＝605件が標高のあるデータで、全体の64.4％に該当します。標高データのあるものは、今後遺物分布図から平面座標を取得できますから、精細な3Dモデル座標も取得できます。

3　メモ

postgreSQLによる遺物台帳テーブルと土錘テーブルの内部結合により派生した「遺物台帳対応土錘テーブル」の分析から、遺物台帳の性格がよくわかりました。遺物台帳名称はあくまでも採集袋のラベルであり、採集袋の中にはラベルとは異なる遺物も一緒に納められいる場合がかなりあるということです。この状況を理解できたことで、今後の分析活動に柔軟性が求められることが判明しました。

4　感想

postgreSQLによる北斜面貝層遺物データベース作成活用がいよいよ本格化しました。現状ではヨチヨチ歩きですがどんな活動でも幼少期通過は必要であり、我慢して実務作業を継続することにします。さいわいなことに、postgreSQLによるデータ分析の不足分はPythonによる分析で穴埋めできています。

今後、postgreSQLのクエリ記述でChatGPT支援を受けて、データ分析の高度化を図りたいとおもいます。

なお、Pythonスクリプト作成、BlenderPythonスクリプト作成ではChatGPT支援を日常的に受けています。postgreSQL、Python、Blenderなどの連携活動がChatGPT支援で自由にできると感じるので、楽しい状況になっています。