2024年6月24日月曜日

C言語:pleiades all in one eclipce Ultimateでのgcc設定

 pleiades all in one eclipceのC言語をインストールすれば、gccのpathを通す必要はないのですが、Ultimateをインストールした場合、pathの設定が必要になります。

[gcc Pathを通す前]

コマンドプロンプトでgccを実行すると、gccがないとエラーが出ます。


[gcc Pathを通す]

pleiades all in one eclipce Ultimateをインストールすると、デフォルトで「C:\pleiades\2024-06\eclipse\mingw\bin」にgccがあります。


ここへのPathを通します。環境変数より、追加してください。



Pathが通ると、コマンドプロンプトで下記のような表示に変更になります。



2024年6月23日日曜日

C言語: Eclipseでファイル分割して関数を呼び出す

 C言語を学ぶとき、EclipseのようなIDEを使うときは多いと思いますが、テキストを順に進めていくときに、毎回プロジェクトを作成して、ソースフォルダsrcを作り、その中にmain関数があるソースファイルを作り、プロジェクトごとビルドして、実行するといった手順をふみ、次の練習コードでは、またプロジェクトを作りと、プロジェクトがたくさんになってしまいます。今回は、main関数入りのソースファイルは一つで、他は関数のみ記述したファイルを、ヘッダーファイルを経由して取り込んで、実行していく方法をやっていきます。今回利用する環境は「Pleiades All in One Eclipse 2024 C/C++」です。

(1)プロジェクトを作成して、mian関数入りのソースファイルで実行する

まずプロジェクト「HelloC」を作成し、その中にソースフォルダ「src」、その中にソースファイル「HelloC.c」を作成します。


HelloC.cには、以下のコードを作成しておきます。
#include<stdio.h>
int main(void){
printf("HelloC_main\n");
}
view raw gistfile1.txt hosted with ❤ by GitHub
プロジェクトのビルドをして、実行してみます。
(2) ファイル「subFunction01.c」を作成し、そこに関数subFunction01を作成した後、ヘッダファイルを作成する
次に、ソースフォルダの中にsubFunction01.cを作成します。
#include<stdio.h>
int main(void){
printf("HelloC_main\n");
subFunction01();
}
view raw gistfile1.txt hosted with ❤ by GitHub
この状態で、main関数から「subFunction01();」として、関数を呼び出しても、subFunction01が見つからずエラーになります。このように別々のファイルに書いた場合、ファイル間で呼び出しを行うにはヘッダーファイルが必要となります。
プロジェクトの下にヘッダーを入れるフォルダ「include」を作成します。さらにこの中に「subFunction.h」ヘッダーファイルを作成します。このヘッダーファイルに、subFunction01関数のプロトタイプ宣言を書き入れておきます。
#ifndef INCLUDE_SUBFUNCTION_H_
#define INCLUDE_SUBFUNCTION_H_
void subFunction01();
#endif /* INCLUDE_SUBFUNCTION_H_ */
view raw gistfile1.txt hosted with ❤ by GitHub
次にこのヘッダーファイルの場所をプロジェクトにパスを通しておきます。
正規表現で書いてありますが、workspace中からプロジェクトを選択し、その中のincludeを指定しただけです。
これでヘッダーファイルがあるフォルダにパスが通ったので、「HelloC.c」と「subFunction01.c」にこのヘッダーファイルを書いて、関数subFunction01を使えるようにします。
#include "subFunction.h"
[HelloC.c]
#include<stdio.h>
#include "subFunction.h"
int main(void){
printf("HelloC_main\n");
subFunction01();
}
view raw gistfile1.txt hosted with ❤ by GitHub
[subFunction01.c]
#include<stdio.h>
#include "subFunction.h"
void subFunction01(){
printf("HelloC_subFunction01\n");
}
view raw gistfile1.txt hosted with ❤ by GitHub
改めてプロジェクトをビルドして、実行してみます。
プロジェクト全体

このように、main関数でない関数として、別ファイルとして加え、ヘッダファイルにプロトタイプ宣言を書き込み、ヘッダフォルダへのパスを通して、そのヘッダファイルをincludeすることで、別ファイルにある関数を呼び出すことができました。gccが使える環境ならば、もう少し簡略化できますが、Eclipse環境ではこのように実施するのが一つの方法です。

2024年6月20日木曜日

データベースへcsvでデータをインポートする

 今回はcsvで正規化されたデータをデータベースにインポートしていきます。これは、

データベースの正規化(エクセルでの処理) (https://smizunolab.blogspot.com/2024/06/blog-post_18.html)

の続きです。利用するcsvファイルは、csv にも掲載してあります。この5個のファイルを利用してやっていきます。

(1) テーブルの作成

今回のテーブル構成は、メインテーブル(corporation)1個と外部テーブル(classification, agreement, content, conclusion)の4つです。以下のようにルールを決めます

・全てのテーブルは「id」を持ち、int not null, auto_increment, primary key とする 

・メインテーブルでの外部キー:「外部テーブル名_id」

・外部テーブルの構成:「id」、「name」は必須、このidはメインテーブルへの参照とする

このルールでテーブルを作成すると、以下のSQL文になります。

CREATE DATABASE IF NOT EXISTS disaster;
USE disaster;
-- Classification table
CREATE TABLE classification (
id INT NOT NULL AUTO_INCREMENT,
name VARCHAR(255) NOT NULL,
PRIMARY KEY (id)
);
-- Agreement table
CREATE TABLE agreement (
id INT NOT NULL AUTO_INCREMENT,
name VARCHAR(255) NOT NULL,
PRIMARY KEY (id)
);
-- Content table
CREATE TABLE content (
id INT NOT NULL AUTO_INCREMENT,
name VARCHAR(255) NOT NULL,
PRIMARY KEY (id)
);
-- Conclusion table
CREATE TABLE conclusion (
id INT NOT NULL AUTO_INCREMENT,
name VARCHAR(255) NOT NULL,
PRIMARY KEY (id)
);
-- Corporation (Main table)
CREATE TABLE corporation (
id INT NOT NULL AUTO_INCREMENT,
classification_id INT NOT NULL,
date_of_agreement DATE NOT NULL,
partner VARCHAR(255) NOT NULL,
agreement_id INT NOT NULL,
content_id INT NOT NULL,
conclusion_id INT NOT NULL,
PRIMARY KEY (id),
FOREIGN KEY (classification_id) REFERENCES classification(id),
FOREIGN KEY (agreement_id) REFERENCES agreement(id),
FOREIGN KEY (content_id) REFERENCES content(id),
FOREIGN KEY (conclusion_id) REFERENCES conclusion(id)
);
view raw gistfile1.txt hosted with ❤ by GitHub

これを用いて、データベースを作成します。今回のデータベースは「disaster」とします。

(2) データベースの用意

データベースはAWS RDSを利用します。下記を参考に、データベースに接続してください。

AWS RDSでデータベースを作成しCloudShellから接続してSQL文からデータを格納する(https://smizunolab.blogspot.com/2024/06/aws-rdscloudshellsql.html)

Cloud Shellに接続して、csvファイルを5個アップロードしておきます。


Cloud Shell からRDSで立ち上げたMySQLに接続します。まず、データベースとテーブルを(1)のSQL文で作成します。テーブルまで作成したら、csvからデータをインポートします。
LOAD DATA LOCAL INFILE 'classification.csv'
INTO TABLE classification
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 LINES
(name);
LOAD DATA LOCAL INFILE 'agreement.csv'
INTO TABLE agreement
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 LINES
(name);
LOAD DATA LOCAL INFILE 'content.csv'
INTO TABLE content
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 LINES
(name);
LOAD DATA LOCAL INFILE 'conclusion.csv'
INTO TABLE conclusion
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 LINES
(name);
LOAD DATA LOCAL INFILE 'corporation.csv'
INTO TABLE corporation
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 LINES
(@dummy, classification_id, date_of_agreement, partner, agreement_id, content_id, conclusion_id)
SET id = NULL;
view raw gistfile1.txt hosted with ❤ by GitHub
テーブルの中身を全て削除するときは、truncateでやりますが、今回外部キー制約を入れてあるので、制約を一度解除してからtruncateすればテーブルの中身は消すことができます。
SET FOREIGN_KEY_CHECKS = 0;
TRUNCATE TABLE classification;
SET FOREIGN_KEY_CHECKS = 1;
view raw gistfile1.txt hosted with ❤ by GitHub
各テーブルに対して、select文で確認してみましょう。
他のテーブルも内容が入っているか確認してください。

(3) テーブルのリレーションを利用
corporationテーブルを表示すると、各テーブルのidで出力されます。この参照しているidを外部テーブルから値を取得するにはjoinを使います。
SELECT
corporation.id,
classification.name AS classification_name,
corporation.date_of_agreement,
corporation.partner,
agreement.name AS agreement_name,
content.name AS content_name,
conclusion.name AS conclusion_name
FROM
corporation
JOIN
classification ON corporation.classification_id = classification.id
JOIN
agreement ON corporation.agreement_id = agreement.id
JOIN
content ON corporation.content_id = content.id
JOIN
conclusion ON corporation.conclusion_id = conclusion.id;
view raw gistfile1.txt hosted with ❤ by GitHub
このように実行すると、値を連携することができます。

(4) データベースのバックアップ
最後に、今回作成した「disaster」データベースをテーブル、データごとバックアップします。
mysqldump -u admin -p --host=各自のエンドポイント disaster > disaster_backup.sql
これでCloud Shell上にバックアップが作成できました。

以上で、エクセルで正規化したデータをデータベースに格納することができました。またバックアップも取得できました。

2024年6月18日火曜日

データベースの正規化(エクセルでの処理)

 今回はデータベースの処理をエクセルで実施します。使用するデータはオープンデータの下記を使います。下記のデータをダウンロードして使用します。

浦安市災害協定締結先一覧(オープンデータ)https://www.city.urayasu.lg.jp/shisei/keikaku/1022110/1025892/1025894/1022122.html

(1) データの前処理

データの前処理を下記の項目で実施します。変更を反映できるようにエクセルファイルにしてから編集した方がいいでしょう。

・1行目を削除

・B列:区分に指定されている項目を入れる

・C列:日付を西暦に変更(色々な形式になっているので)、例:令和元年9月12日 と変換できない文字列として入れられたものは、手で変換する必要があります。日付の形式は「yyyy-mm-dd」とします。

・G列:締結に空白があるので「記載無し」としておく

ここまでのファイル:saigaikyoutei.teiketsusaki_20231026_v01_01.xlsx

(2) データの正規化

次にエクセルにシートを追加して、データの正規化をしてやっていきます。以下のシートを追加し、エクセルのunique関数を使って、重複の無い項目を抽出します。例として、classificationシートのA2に「=UNIQUE(saigaikyoutei.teiketsusaki_2023!B2:B130)」と入力。

・B列:区分 -> classificationシートを作成(name, classification_idの2列を作成)

・E列:締結の名称 -> agreementシートを作成(name, agreement_idの2列を作成)

・F列:協定等の内容 -> contentシートを作成(name, content_idの2列を作成)

・G列:締結の内容 -> conclusionシートを作成(name, conclusion_idの2列を作成)

ここまでのエクセルファイル:saigaikyoutei.teiketsusaki_20231026_v01_02.xlsx

(3) データの正規化:vlookupで外部キーを挿入
次に(2)で作成した表でvlookupを利用して、元データを外部キーで置き換えます。vlookupは検索したキーワードに対し、それに紐づいているID等を挿入するものです。
全体の表でB列「区分」の左に、classification_id列を追加して、vlookupで区分の値を検索し、classification_idを取得します。新たに追加したB列のB2には以下のように入力します。
=VLOOKUP(C2,cllasification!A$2:B$13,2,FALSE)
他の外部テーブルを作った列に対しても同様にやっていきます。classification,agreement,content,conclusionの4テーブルに対して同様にできたら、このシートを「値」でコピーして、新たなシート「corporation」に貼り付けます。idを挿入した区分、協定の名称、協定等の内容、締結の各列は削除します。
この「corpration」がメインテーブル、「classification」「agreement」「content」「conclusion」の4つが外部テーブルとなり、正規化が完了しました。
ここまでのファイル:saigaikyoutei.teiketsusaki_20231026_v01_03.xlsx

次はこの計5個のテーブルをデータベースに格納して、リレーションを張る作業になります。ここまでの作業を確認して、構造化されているデータがあったとき、どのように正規化してデータベースに格納するかを確認して下さい。

2024年6月14日金曜日

研究のスタイル

 研究者によって研究のスタイルは様々だと思いますが、僕の日々の研究のスタイルについて書いておきます。


(1) マルチタスクが基本

研究活動に携わっていると、研究プロジェクトが同時に走る場合がほとんどです。その中で、一つのタスクに集中して進めるタイプと、複数のタスクをパラレルに進めるタイプに大きく分かれると思います。僕は、「複数のタスクを少しずつ進めるタイプ」です。と言うより、一つのタスクを集中して進めることが苦手なので、複数タスクを少しずつ進めて、芽が出たものから優先度を上げていくやり方です。時には、集中して一気に仕上げる場合もありますが、そのタイミングを掴むまでは、複数タスクをじっくりやって少しずつ進めています。研究だけでなく仕事でも言えることだと思いますが、「継続・持続力」、「興味・視野の広さ」、「瞬発力」を意識して、自分のフェーズに合わせて優先度を設定することが大事かと思います。


(2) 研究での情報収集

研究を行う場合、文献整理は必須になります。論文を執筆するときは、十分な量の論文を読んで研究背景を確認しますが、日々の活動のときは、僕自身書籍を中心にインプットしています。インターネットでの収集もしますが、書籍は体系的に整理されていて、僕自身一番知識が整理しやすいです。書籍は英語の本を読んでいきますが、その本の類似本を日本語で4~5冊用意して、英語本でわからない部分を補ったり、表現を比較したり利用すると、理解が進みます。英語の本はページ数が多く、英語と言うこともあり読み進めることが大変ですが、1冊読めれば論文も書ける内容が身に付きます。今までに何冊かとても参考になる英語本と出会えましたが、自分のバイブルとなるような本に出会うことも重要です。海外出張に行った時は、書店があれば覗いてみて、良い本がないか探しています。


(3) スタンディングディスクが欲しい

僕は座って仕事をするより、立って仕事をすることの方が好きです。腰が良くないということもありますが、立って仕事ができる環境のときは、立ってやっています。スタンディングデスクがあればかっこいいのですが、僕は背が高く、販売しているスタンディングデスクでは、少し高さが足りません。今まで高さがピッタリだったのは自宅のタンスです。研究室では書籍ロッカーを机代わりにして、立って仕事をしているときもあります。立って仕事をしているときの方が、なぜか頭が回り、体も疲れていない場合が多いです。


研究や仕事はいつも絶好調というのではなく、むしろ調子が上がらず、我慢の状態で進めていることが多いです。調子が良くないと進められないということではなく、調子が悪い時に、「一歩でも前へ」と考えて、日々進めています。


2024年6月12日水曜日

データサイエンスの失敗例

 今まで色々なデータサイエンスに関する案件に携わってきましたが、成功例もある一方色々な失敗もしてきました。いくつか例としてあげておきます。


(1) 可視化をすることで失敗

これはどの現場でもありそうなことですが、データサイエンスを実践するときに、まずは可視化を行い、自分自身がデータを理解し、またディスカッションの材料とします。しかし、打ち合わせでは様々な立場の方々がいます。出席者の立場を配慮せず、多角度から可視化をした結果、その立場の方のウイークポイントが明確になってしまい、打ち合わせ場で怒りを買ってしまったことがあります。課題を明確にするには必要なことですが、相手を怒らせてしまうと議論が停滞し、その後精度の良い分析をしても受け入れられることもなくなってしまいます。その現場の方は頑張っていることだと思いますし、言い方の問題だと思いますので、あまり機械的に話さず、時には柔らかく話すことも大事だと思いました。


(2) キーパーソン不在

データサイエンスでは、こちらが持つ分析ノウハウ、データ、現場の課題感を結びつけながら課題解決を図っていきます。そのときに分析側と現場を繋げるキーパーソンが必要です。キーパーソンはこちらの分析結果を現場に合う形に翻訳することもあります。また現場の課題を抽出し、まとめてもらうことも必要です。このキーパーソンがいない場合、良い結果が出る可能性は極端に低くなると思います。


(3) 何かやってよ

以前は「AIやってみて」という依頼もあったのですが、このデータは山のようにあるから「何かやってみてよ」は上手くいきません。それは目的がないからです。データサイエンスは社会の課題解決を図ることが目的の一つですので、目的がない限り、NDAのデータ利用制限があるような分析環境はうまくいきません。データサイエンスはやはり現場との連携と目的意識を共有することが重要です。


(4) あまりに強い仮説意識

データサイエンスを実践する場合、目的意識は大事で、経験値からくる仮説は重要です。可視化によってディスカッションを経て仮説が出てくれば、その仮説を実証するために分析を行います。その分析結果を確認し、必要なら仮説を修正するようなPDCAサイクルを繰り返します。しかし、あまりに自分の仮説に固執すると、そのための分析になってしまい、事実を曲げてしまう可能性があります。適度な強度の仮説が求められます。


(5) 相手がこわい

打ち合わせの場で、そもそも相手がこわいときがあります。その人の素の姿だと思いますが、自然体で怖そうだと打ち合わせに行きたくなくなります。研究で仲介者がいる場合は、「先方は怖い人ですか?」と聞いています。


AI・データサイエンスは魔法のように思われている節もありますが、上記にあげたように泥臭いことも多いです。これらを乗り越えてデータサイエンスでの社会貢献に向けて、日々研究を進めています。


待ち行列理論について

 待ち行列という言葉は誰でも知っている言葉だと思います。スーパのレジやテーマパークの順番待ちなどが考えられると思います。この日常的な待ち行列に、理論があるのを知っているでしょうか?この理論は待ち行列理論といい、1900年代から始まった理論で、電話交換機の評価を行うためのものでした。僕が考える待ち行列理論の面白さは、次のようなものがあります。

・人間の行動やシステムを、いくつかの仮定の下で、数式で表現できる

・数式から解析解を求めることができる

・待ち行列を評価する特性量(平均系内人数など)を求めることができる

・特性量を用いて、システムを最適化することもできる

・数学的にきれい

・確率論、確率過程をふんだんに使う

(1) 待ち行列理論の構成

待ち行列理論にはケンドール記号というものがり、「M/M/1」のような形で表現されます。最初のMですが、到着過程を表し、MはMarkovian(マルコビアン)の略です。これがMのときは、到着過程がポアソン過程での到着を示しています。ポアソン過程は、単位時間あたりの到着人数がポアソン分布に従い、到着間隔は指数分布に従う過程のことです。最初はポアソン分布とポアソン過程の違いがわからずに、同じものと考えてしまっていました。次のMはサービスを表しています。到着がMのときはポアソン過程でしたが、サービスがMのときはサービスが指数分布に従うことを表します。最後の1は窓口数を表します。さらに、「M/M/1/K」のように、窓口数の後にさらにバッファーの大きさ指定する場合があります。このKの大きさまで待ち行列を作れて、K人既に並んでいる場合、新規で到着した客は待ち行列に並ぶことができず、退去することになります。これを故損と言います。またMだけでなくGなどの他の記号も用います。Gの場合は一般分布に(名前が定まっていないような確率分布)に従うことを意味していて、表現を広げています。このように待ち行列理論は、到着過程、サービス分布、窓口数で基本的な構成がされています。

(2) 待ち行列理論を解く

待ち行列理論の面白いところは、このような人間の行動をシステムとして評価できるところです。M/M/1は解析的に解くモデルの代表例ですが、M/M/のモデルは複数窓口の場合も、バッファーが有限の場合も解析的に解くことができます。M/G/1のサービスが一般分布になったモデルも解析解が得られます。これをポラチックヒンチンの公式と言います。ところが、M/G/s (sは2以上)のような複数窓口になった場合、解析的に解くことが困難になります。窓口数が1なら解析的に解けるのですが、複数になると、途端に難しくなるところが待ち行列理論の特徴です。

待ち行列理論にはネットワーク型もあります。M/M/1がネットワーク型に繋がったものがジャクソンネットワークといい、積形式解という形で解析解が求まります。このジャクソンネットワークは外部からの到着、外部への退去もあり、開放型と言います。このジャクソンネットワークを開放型、閉鎖型両方のネットワークに対応し、さらに複数窓口、客クラス、4つのサービスタイプに拡張したBCMP待ち行列ネットワークというものも解析的に特性量を求めることができます。僕はこのBCMP待ち行列ネットワークが適用範囲が広く、この応用例をよく扱っています。


待ち行列理論の背景を簡単に述べましたが、日常的にみられる待ち行列を、数式で表現でき、さらにそれを解いて特性量からシステム的に評価できるような待ち行列理論は、いろんな奥深さがあると考えています。


2024年6月10日月曜日

AWS RDSでデータベースを作成しCloudShellから接続してSQL文からデータを格納する

 AWS RDSを利用してデータベースを作成していきます。AWS RDSはリレーショナルデータベースで、構造的な関係を持つデータの格納に便利です。今回はクラウド環境で使えるAWS RDSを使って、データベースを作成していきます。今回の目標は、「RDSでデータベースを作成し、CloudShellから接続して、SQL文からデータを格納する」ことです。本当はデータをプログラムで分析し、データベースに格納したいところですが、データベースの基本を確認するために、今回はSQL文を利用していきます。

(1) AWS RDSにデータベースを作成

AWS マネージメントコンソールからRDSにはいり、データベースを作成していきます。今回はできる限り簡易的にやっていきます。画面の「データベースの作成」ボタンを押します。

データベース作成方法を選択 -> 簡単に作成
エンジンのタイプ -> MySQL
DBインスタンスタイプ -> 無料利用枠
DBインスタンス識別子 -> database-001
マスターユーザー名 -> admin (そのまま)
認証情報管理 -> セルフマネージド
マスターパスワード -> 任意ですが授業の場合は「LinuxOS99」とします。(@は使えません)
データベースの作成をクリックします。下記の内容が出てきてもそのまま閉じるで構いません。
AWS Acdemyでやっている場合は、エラーが出る場合もありますが、そのままやっていきます。データベースの作成には少し時間がかかります(3分程度)。
ステータスが利用可能になり、これで作成ができました。

(2) パブリックアクセス可能に変更する
次に、データベースをCloudShellや外部プログラムから接続できるように、設定を変更します。
DB識別子「database-001」をクリック
画面右上の「変更」をクリック
接続 -> 追加設定をクリック -> 「パブリック接続可能」に変更
画面をスクロールして一番下にいき、続行をクリック
「すぐに適用」に変更し、DBインスタンスを変更をクリック
ステータスが変更中となり、しばらくすると、利用可能になります。これでパブリックアクセス可能に変更ができました。

(3) セキュリティグループを変更して、データベースに接続できるようにする
次に、セキュリティグループを変更して、データベースに接続できるようにします。つまりファイアーウォールでデータベースに接続できない状況となっています。
DB識別子のdatabase-001をクリック、
セキュリティ -> VPCセキュリティグループをクリック
セキュリティグループIDをクリック
インバウンドのルールを編集
ルールを追加
MySQL/Aurola、0.0.0.0/0 (どこからでもアクセス可能)にして、ルールを保存をクリック
ポートは3306のまま
これで外部からのデータベースアクセスが許可されました。
RDSに戻ります。

(4) Cloud Shellから接続する
これでデータベースにアクセスができるようになったので、今回はCloud Shellを使って、データベースにアクセスします。Cloud Shellは画面上部のボタンをクリックします。
クリックすると、画面下部にプロンプトが出てきます。
このプロンプトに次のコマンドを入力します。
mysql -h エンドポイント(各自のもの) -P 3306 -u admin -p
エンドポイントはDB識別子をクリックして、接続とセキュリティ画面にあるので、確認してください。
パスワード(授業ではLinuxOS99)を入れてログインできれば成功です。データベースで何があるかを確認するには、
show databases;
とします。最後に;(セミコロン)があるので忘れないようにしてください。
MySQLからログアウトするには
exit;
とします。

(5) SQL文を使って、データをインポートする
データベースに接続ができたので、SQL文からデータをインポートします。段取りとしては
(i) データベースの作成(create)、データベースの指定(use)
(ii) テーブルの作成(create)
(iii) データの挿入(insert)
(iv) データの確認(select)
-- データベースの作成
CREATE DATABASE IF NOT EXISTS urayasu;
USE urayasu;
-- locations テーブルの作成
CREATE TABLE IF NOT EXISTS locations (
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(255) NOT NULL,
latitude VARCHAR(255) NOT NULL,
longitude VARCHAR(255) NOT NULL
);
-- distances テーブルの作成
CREATE TABLE IF NOT EXISTS distances (
id INT AUTO_INCREMENT PRIMARY KEY,
from_location INT NOT NULL,
to_location INT NOT NULL,
distance FLOAT,
FOREIGN KEY (from_location) REFERENCES locations(id),
FOREIGN KEY (to_location) REFERENCES locations(id)
);
-- urayasu_bunkazai.csvのデータをlocationsテーブルに挿入
INSERT INTO locations (name, latitude, longitude)
VALUES
('宝城院', '35.66167', '139.8911'),
('浦安市郷土博物館', '35.65536', '139.90122'),
('旧大塚家住宅', '35.66187', '139.8927'),
('花蔵院', '35.66078', '139.89685'),
('豊受神社', '35.66067', '139.89758'),
('善福寺', '35.66989', '139.89277'),
('大蓮寺', '35.66203', '139.89049'),
('庚申塔', '35.66408', '139.8938'),
('旧宇田川家住宅', '35.66196', '139.89228'),
('清瀧神社', '35.66238', '139.89122'),
('稲荷神社', '35.67241', '139.89154'),
('浦安駅','35.66604888473298','139.89326652577006');
-- distancesテーブルにデータをインポート
INSERT INTO distances (from_location, to_location, distance)
VALUES
(1, 1, 0.0), (1, 2, 1647.0), (1, 3, 174.0), (1, 4, 997.0), (1, 5, 1092.0), (1, 6, 1010.0), (1, 7, 69.0), (1, 8, 713.0), (1, 9, 92.0), (1, 10, 133.0), (1, 11, 1462.0), (1, 12, 919.0),
(2, 1, 1819.0), (2, 2, 0.0), (2, 3, 1928.0), (2, 4, 1100.0), (2, 5, 1164.0), (2, 6, 2534.0), (2, 7, 1888.0), (2, 8, 1809.0), (2, 9, 1846.0), (2, 10, 1887.0), (2, 11, 2932.0), (2, 12, 2443.0),
(3, 1, 872.0), (3, 2, 1643.0), (3, 3, 0.0), (3, 4, 639.0), (3, 5, 710.0), (3, 6, 1683.0), (3, 7, 1118.0), (3, 8, 823.0), (3, 9, 900.0), (3, 10, 941.0), (3, 11, 2248.0), (3, 12, 1592.0),
(4, 1, 997.0), (4, 2, 1100.0), (4, 3, 1107.0), (4, 4, 0.0), (4, 5, 65.0), (4, 6, 1466.0), (4, 7, 1243.0), (4, 8, 606.0), (4, 9, 1025.0), (4, 10, 632.0), (4, 11, 1864.0), (4, 12, 1375.0),
(5, 1, 1068.0), (5, 2, 960.0), (5, 3, 1178.0), (5, 4, 65.0), (5, 5, 0.0), (5, 6, 1537.0), (5, 7, 1314.0), (5, 8, 677.0), (5, 9, 1096.0), (5, 10, 703.0), (5, 11, 1935.0), (5, 12, 1446.0),
(6, 1, 1370.0), (6, 2, 2707.0), (6, 3, 1461.0), (6, 4, 1826.0), (6, 5, 2153.0), (6, 6, 0.0), (6, 7, 1251.0), (6, 8, 1323.0), (6, 9, 1379.0), (6, 10, 1314.0), (6, 11, 462.0), (6, 12, 669.0),
(7, 1, 69.0), (7, 2, 1893.0), (7, 3, 243.0), (7, 4, 1243.0), (7, 5, 1338.0), (7, 6, 1251.0), (7, 7, 0.0), (7, 8, 1076.0), (7, 9, 162.0), (7, 10, 202.0), (7, 11, 1374.0), (7, 12, 1140.0),
(8, 1, 713.0), (8, 2, 1622.0), (8, 3, 804.0), (8, 4, 606.0), (8, 5, 677.0), (8, 6, 963.0), (8, 7, 782.0), (8, 8, 0.0), (8, 9, 722.0), (8, 10, 656.0), (8, 11, 1362.0), (8, 12, 872.0),
(9, 1, 864.0), (9, 2, 1635.0), (9, 3, 82.0), (9, 4, 630.0), (9, 5, 701.0), (9, 6, 1674.0), (9, 7, 1110.0), (9, 8, 815.0), (9, 9, 0.0), (9, 10, 933.0), (9, 11, 2240.0), (9, 12, 1583.0),
(10, 1, 133.0), (10, 2, 1716.0), (10, 3, 224.0), (10, 4, 632.0), (10, 5, 1160.0), (10, 6, 954.0), (10, 7, 379.0), (10, 8, 656.0), (10, 9, 142.0), (10, 10, 0.0), (10, 11, 1405.0), (10, 12, 863.0),
(11, 1, 1493.0), (11, 2, 2830.0), (11, 3, 1584.0), (11, 4, 1949.0), (11, 5, 2276.0), (11, 6, 462.0), (11, 7, 1374.0), (11, 8, 1446.0), (11, 9, 1502.0), (11, 10, 1437.0), (11, 11, 0.0), (11, 12, 1024.0),
(12, 1, 547.0), (12, 2, 1884.0), (12, 3, 638.0), (12, 4, 1003.0), (12, 5, 1330.0), (12, 6, 798.0), (12, 7, 616.0), (12, 8, 500.0), (12, 9, 556.0), (12, 10, 491.0), (12, 11, 1196.0), (12, 12, 0.0);
view raw gistfile1.txt hosted with ❤ by GitHub
このSQL文は、データベース:urayasu、テーブル:locations、distances となっていて、locationsではid, 名前、緯度、経度を持ち、distancesではlocationsのidを外部キーとして、from_locationとto_locationで2拠点間の距離を格納しています。このように、locationsのidがdistancesの外部キーとなっており、リレーションがはられている構造です。
これをCloud Shellから文ごと確認して、データのインポートができるか確認してください。
インポートができたら
select * from locations;
select * from distances;
で確認しましょう。





これで、AWS RDSでデータベースを作成しCloudShellから接続してSQL文からデータを格納することができました。

2024年6月8日土曜日

API (Application Programming Interface)の利用:POSTMANの利用

 API (Application Programming Interface)は文字通り、アプリケーションをプログラムで繋ぐインターフェースです。このAPIを利用することで、様々なデータ、システム、アプリケーションを連携させることができます。自分のシステムに、外部のデータや計算結果を連携することができます。今回はPOSTMANを利用して、動作を確認していきます。

(1) POSTMANの準備

POSTMANを利用するためには、アカウント作成(無料)が必要です。https://www.postman.com/ にアクセスし、アカウントを作成してください。サインイン後、WorkSpaceとして、わかりやすいものを作成します(デフォルトのWorkSpaceを利用でも構いません)。

(2) APIの利用

APIがどのように動作するか確認するために、下記のサイトのAPIを利用してみます。

https://dog.ceo/dog-api/

このサイトはランダムに犬の画像を返してくれます。

POSTMANを開き、上記のサイトに掲載されているAPIのURLをPOSTMANに入力します。

これでsendを押すと、messageとstatusが戻ってきます。
ここで出力されたURLにアクセスしてみると、犬の画像が返されています。
このような形で使っていきます。

(3) Pythonプログラムでの利用
POSTMANの画面右上(sendボタンのすぐ右上)にコードに変換するボタンがあります。
このボタンを押して、今回は「Python - Requests」に変換をします。
この変換されたコードを利用して、Pythonが実行できる環境で実行してみます(ここでは Google Colaboratoryでやっています)
実行できたのがわかります。せっかくですので、この犬の画像が表示されるようにしてみます。
import requests
from PIL import Image
from io import BytesIO
import matplotlib.pyplot as plt
url = "https://dog.ceo/api/breeds/image/random"
payload = {}
headers = {}
response = requests.request("GET", url, headers=headers, data=payload)
print(response.text)
response = requests.get(url)
data = response.json()
image_url = data["message"]
# 画像を表示
response = requests.get(image_url)
img = Image.open(BytesIO(response.content))
plt.imshow(img)
plt.axis('off') # 軸を非表示にする
plt.show()
view raw gistfile1.txt hosted with ❤ by GitHub


今回はPOSTMANを使って、APIを実行し、Pythonコードに変換して、画像を表示しました。