pleiades all in one eclipceのC言語をインストールすれば、gccのpathを通す必要はないのですが、Ultimateをインストールした場合、pathの設定が必要になります。
[gcc Pathを通す前]
コマンドプロンプトでgccを実行すると、gccがないとエラーが出ます。
pleiades all in one eclipce Ultimateをインストールすると、デフォルトで「C:\pleiades\2024-06\eclipse\mingw\bin」にgccがあります。
C言語を学ぶとき、EclipseのようなIDEを使うときは多いと思いますが、テキストを順に進めていくときに、毎回プロジェクトを作成して、ソースフォルダsrcを作り、その中にmain関数があるソースファイルを作り、プロジェクトごとビルドして、実行するといった手順をふみ、次の練習コードでは、またプロジェクトを作りと、プロジェクトがたくさんになってしまいます。今回は、main関数入りのソースファイルは一つで、他は関数のみ記述したファイルを、ヘッダーファイルを経由して取り込んで、実行していく方法をやっていきます。今回利用する環境は「Pleiades All in One Eclipse 2024 C/C++」です。
(1)プロジェクトを作成して、mian関数入りのソースファイルで実行する
まずプロジェクト「HelloC」を作成し、その中にソースフォルダ「src」、その中にソースファイル「HelloC.c」を作成します。
今回は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文になります。
これを用いて、データベースを作成します。今回のデータベースは「disaster」とします。
(2) データベースの用意
データベースはAWS RDSを利用します。下記を参考に、データベースに接続してください。
AWS RDSでデータベースを作成しCloudShellから接続してSQL文からデータを格納する(https://smizunolab.blogspot.com/2024/06/aws-rdscloudshellsql.html)
Cloud Shellに接続して、csvファイルを5個アップロードしておきます。
今回はデータベースの処理をエクセルで実施します。使用するデータはオープンデータの下記を使います。下記のデータをダウンロードして使用します。
浦安市災害協定締結先一覧（オープンデータ）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列を作成)
研究者によって研究のスタイルは様々だと思いますが、僕の日々の研究のスタイルについて書いておきます。
(1) マルチタスクが基本
研究活動に携わっていると、研究プロジェクトが同時に走る場合がほとんどです。その中で、一つのタスクに集中して進めるタイプと、複数のタスクをパラレルに進めるタイプに大きく分かれると思います。僕は、「複数のタスクを少しずつ進めるタイプ」です。と言うより、一つのタスクを集中して進めることが苦手なので、複数タスクを少しずつ進めて、芽が出たものから優先度を上げていくやり方です。時には、集中して一気に仕上げる場合もありますが、そのタイミングを掴むまでは、複数タスクをじっくりやって少しずつ進めています。研究だけでなく仕事でも言えることだと思いますが、「継続・持続力」、「興味・視野の広さ」、「瞬発力」を意識して、自分のフェーズに合わせて優先度を設定することが大事かと思います。
(2) 研究での情報収集
研究を行う場合、文献整理は必須になります。論文を執筆するときは、十分な量の論文を読んで研究背景を確認しますが、日々の活動のときは、僕自身書籍を中心にインプットしています。インターネットでの収集もしますが、書籍は体系的に整理されていて、僕自身一番知識が整理しやすいです。書籍は英語の本を読んでいきますが、その本の類似本を日本語で4~5冊用意して、英語本でわからない部分を補ったり、表現を比較したり利用すると、理解が進みます。英語の本はページ数が多く、英語と言うこともあり読み進めることが大変ですが、1冊読めれば論文も書ける内容が身に付きます。今までに何冊かとても参考になる英語本と出会えましたが、自分のバイブルとなるような本に出会うことも重要です。海外出張に行った時は、書店があれば覗いてみて、良い本がないか探しています。
(3) スタンディングディスクが欲しい
僕は座って仕事をするより、立って仕事をすることの方が好きです。腰が良くないということもありますが、立って仕事ができる環境のときは、立ってやっています。スタンディングデスクがあればかっこいいのですが、僕は背が高く、販売しているスタンディングデスクでは、少し高さが足りません。今まで高さがピッタリだったのは自宅のタンスです。研究室では書籍ロッカーを机代わりにして、立って仕事をしているときもあります。立って仕事をしているときの方が、なぜか頭が回り、体も疲れていない場合が多いです。
研究や仕事はいつも絶好調というのではなく、むしろ調子が上がらず、我慢の状態で進めていることが多いです。調子が良くないと進められないということではなく、調子が悪い時に、「一歩でも前へ」と考えて、日々進めています。
今まで色々なデータサイエンスに関する案件に携わってきましたが、成功例もある一方色々な失敗もしてきました。いくつか例としてあげておきます。
(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待ち行列ネットワークが適用範囲が広く、この応用例をよく扱っています。
待ち行列理論の背景を簡単に述べましたが、日常的にみられる待ち行列を、数式で表現でき、さらにそれを解いて特性量からシステム的に評価できるような待ち行列理論は、いろんな奥深さがあると考えています。
AWS RDSを利用してデータベースを作成していきます。AWS RDSはリレーショナルデータベースで、構造的な関係を持つデータの格納に便利です。今回はクラウド環境で使えるAWS RDSを使って、データベースを作成していきます。今回の目標は、「RDSでデータベースを作成し、CloudShellから接続して、SQL文からデータを格納する」ことです。本当はデータをプログラムで分析し、データベースに格納したいところですが、データベースの基本を確認するために、今回はSQL文を利用していきます。
(1) AWS RDSにデータベースを作成
AWS マネージメントコンソールからRDSにはいり、データベースを作成していきます。今回はできる限り簡易的にやっていきます。画面の「データベースの作成」ボタンを押します。
API (Application Programming Interface)は文字通り、アプリケーションをプログラムで繋ぐインターフェースです。このAPIを利用することで、様々なデータ、システム、アプリケーションを連携させることができます。自分のシステムに、外部のデータや計算結果を連携することができます。今回はPOSTMANを利用して、動作を確認していきます。
(1) POSTMANの準備
POSTMANを利用するためには、アカウント作成(無料)が必要です。https://www.postman.com/ にアクセスし、アカウントを作成してください。サインイン後、WorkSpaceとして、わかりやすいものを作成します(デフォルトのWorkSpaceを利用でも構いません)。
(2) APIの利用
APIがどのように動作するか確認するために、下記のサイトのAPIを利用してみます。
このサイトはランダムに犬の画像を返してくれます。
POSTMANを開き、上記のサイトに掲載されているAPIのURLをPOSTMANに入力します。
