ラベル postgreSQL の投稿を表示しています。 すべての投稿を表示
ラベル postgreSQL の投稿を表示しています。 すべての投稿を表示

2024年7月30日火曜日

技術メモ: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支援で自由にできると感じるので、楽しい状況になっています。


2024年7月3日水曜日

postgreSQLの導入

 Introduction of postgreSQL


I introduced postgreSQL (free software) as the basic software for creating relational databases after two days of intensive training. Not only is SQL (database language) easy to use, but it also has ChatGPT support, so my psychological hurdle has disappeared. I will use postgreSQL for the artifact database of the shell layer on the north slope of the Ariyoshi Kita Shell Mound, etc.


リレーショナルデータベース作成の基本ソフトしてpostgreSQL(フリーソフト)を2日間の特訓で導入しました。SQL(データベース言語)は平易であるだけでなく、ChatGPT支援も受けられますから、私の心理的ハードルはなくなりました。postgreSQLを有吉北貝塚北斜面貝層の遺物データベースなどで活用します。

1 postgreSQLの導入


postgreSQLのGUIであるpgAdmin4画面

2日間のpostgreSQL導入活動項目

1-1 導入すべきリレーショナルデータベースソフトの選定

これまでリレーショナルデータベースソフトとしてFileMakerを利用してきました。しかし、FileMakerの最大特徴が多人数業務利用を前提とする有料クラウドタイプにすっかり移動してしまいました。デスクトップパソコン単体による個人利用はいわば対象外になってしまいました。いつまでもFileMakerにこだわっていられる状況では無くなってしまいました。

そのような中で有吉北貝塚北斜面貝層の3Dデータベース作成作業が進み、新たなリレーショナルデータベースソフトを探すことになりました。

主にweb検索でいろいろ調べ、無償ソフトであるpostgreSQLを導入することに決めました。

web検索の中で、次のYouTubeサイトを見つけ、postgreSQL利用イメージが大いに湧きました。

伊藤研究室 / ITO Lab @UTokyo

1-2 postgreSQLのインストール

postgreSQLダウンロードサイトからダウンロードしたファイルのインストールは、幾つかのインストール解説サイトを見ながら行い、問題なくできました。

1-3 postgreSQLの試用

postgreSQLに付属する管理ツール(GUI)pgAdmin4を使ってデータベース作成、テーブル作成、テーブル結合などのテスト作業を行いました。作業のメインはSQL(データベース言語)でクエリ(指示)を書く作業になります。SQLはPythonなどのプログラミング言語と比べるとかなり平易でだれでも扱えそうな言語です。

2 SQL記述におけるChatGPTの支援

SQL記述で迷ったときに、ChatGPTの支援を受けたところ、丁寧に教えてもらることができました。SQLはもともと平易なうえ、ChatGPTの支援をPythonと同じように受けることができます。

3 感想

・postgreSQL導入は難渋するかもしれないと心配しましたが、以外と短時間にできました。特に、ChatGPT支援を受けられることに気が付き、一気に心理的ハードルが下がりました。

・postgreSQLとBlenderを関連付けて一連の作業を行い、訴求力のある3Dモデル資料作成を目指します。

・postgreSQLはファイルを全部読み込んでから作業するという通常ソフトと異なり、データベースに直接アクセスして作業しています。従って、とても高速で、扱っていて痛快です。

・過去に作成・利用したデータベース(千葉県遺跡データベース約2万件、千葉県小字データベース約8万件、千葉県墨書土器データベース約3万件(出典:明治大学)、日本貝塚データベース(奈文研から貸与))などもpostgreSQL仕立てのデータベースに変更して、再び命を吹き込みたいとおもいます。