FTPサーバーを立ち上げデータの移動は完了したので、今度は移動したデータをMariaDBにテーブルにインポートしてみた。
データをラズパイ側に移動したおかげで、インポート自体は実行することができたが、何だかワーニングが発生し、しかも全数が対象だった。
インポートした結果、データ形式とテーブル形式が微妙に違っていたので、ワーニングが発生したようだ。
やっぱりやる事が素人なんで、所々でトラブルが発生するよね。
そんなデータをインポートしたのだけれど、期待した内容でデータが格納されていなかった事について今回は紹介しよう。
CSVデータをインポートする
さて、前回はWindows側にあったCSVデータをインポートしようとしてエラーとなったため、FTPサーバーを立ち上げてラズパイ側にデータを移すことに成功した。
次はいよいよラズパイ側に有るデータをMariaDBのデーブルにインポートするんだ。
それでは実際にやっていこう。
前回も記述したかもしれないが、CSVデータをテーブルにインポートするSQL文はload dataになる。
従って、SQL文としては以下の通り。
load data local infile "/home/jkawasaki/numbers3jnb.csv" into table result fields terminated by ',' OPTIONALLY enclosed by '"';
今回は自分のホームディレクトリにデータを格納したので、/home/jkawasakiがファイルのパスになる。
それでは実際にSQL文を実行してみよう。
MariaDB [numbers3]> load data local infile “/home/jkawasaki/numbers3jnb.csv” into table result fields terminated by ‘,’ OPTIONALLY enclosed by ‘”‘;
Query OK, 519 rows affected, 2077 warnings (0.058 sec)
Records: 519 Deleted: 0 Skipped: 0 Warnings: 2077
前回と違い、SQL文自体の間違いは無く無事実行されたためQuery OKと言う表示がでました。
しかし、その後の結果表示が非常に気になりました。
Records: 519 Deleted: 0 Skipped: 0 Warnings: 2077
結果としては、519のレコードがあり、削除は0、スキップも0、しかしWarningsが2077も発生しているのです。
どういう事?って思いますよね。
考えられるのは、データのインポートは519レコードできたけど、インポートした内容に誤りが2077発生していると言うことだろう。
インポートしたCSVデータを確認してみた
とりあえずテーブルが、どんな内容になっているのかを確認をする必要があるよね。
と言う事で、データがインポートされたテーブルの内容を確認してみることにした。
テーブルのデータを確認するにはSELECT文を使用する。
今回は、インポートしたデータ全部を確認したいので、SQL文は以下の通りになる。
select * from result
全項目対象なので*となりresultはテーブル名だ。
MariaDB [numbers3]> select * from result;
実行した結果は以下の通り。
+——+——-+————+——-+——-+——-+
| id | kaisi | hizuke | 3digi | 2digi | 1digi |
+——+——-+————+——-+——-+——-+
| 1 | 2023 | 0000-00-00 | 4 | 4 | 0 |
| 5664 | 2021 | 0000-00-00 | 1 | 5 | 0 |
| 5665 | 2021 | 0000-00-00 | 5 | 3 | 0 |
| 5666 | 2021 | 0000-00-00 | 4 | 2 | 0 |
| 5667 | 2021 | 0000-00-00 | 1 | 1 | 0 |
| 5668 | 2021 | 0000-00-00 | 8 | 4 | 0 |
| 5669 | 2021 | 0000-00-00 | 7 | 8 | 0 |
~ ~
| 6165 | 2023 | 0000-00-00 | 7 | 4 | 0 |
| 6166 | 2023 | 0000-00-00 | 4 | 4 | 0 |
| 6167 | 2023 | 0000-00-00 | 3 | 4 | 0 |
| 6168 | 2023 | 0000-00-00 | 3 | 2 | 0 |
| 6169 | 2023 | 0000-00-00 | 6 | 1 | 0 |
| 6170 | 2023 | 0000-00-00 | 7 | 5 | 0 |
| 6171 | 2023 | 0000-00-00 | 3 | 7 | 0 |
| 6172 | 2023 | 0000-00-00 | 2 | 8 | 0 |
| 6173 | 2023 | 0000-00-00 | 2 | 5 | 0 |
| 6174 | 2023 | 0000-00-00 | 8 | 4 | 0 |
| 6175 | 2023 | 0000-00-00 | 2 | 1 | 0 |
| 6176 | 2023 | 0000-00-00 | 3 | 7 | 0 |
| 6177 | 2023 | 0000-00-00 | 2 | 0 | 0 |
| 6178 | 2023 | 0000-00-00 | 3 | 9 | 0 |
| 6179 | 2023 | 0000-00-00 | 9 | 4 | 0 |
| 6180 | 2023 | 0000-00-00 | 0 | 9 | 0 |
| 6181 | 2023 | 0000-00-00 | 1 | 1 | 0 |
+——+——-+————+——-+——-+——-+
519 rows in set (0.004 sec)
これではワーニング表示がでるよね。
CSVデータの最初の列は開催回数となっているが、テーブルではIDとなっている。しかもIDは1から始まり自動で加算していく指定になっている。
ここでまずはアンマッチとなってしまっている。
従って、開催日のと列には2023だけ入り、それ以降に残りのデータがずれて入っている。
従って、1桁目(1digi)の列は全て0になってしまっているんだ。
と言う事で、素人がCSVデータをインポートしたらお粗末な結果になってしまった。
これを解消するには、一度テーブルを削除してもう一度テーブルを作り直してから再度CSVデータをインポートすることになる。
はぁ~、やっちまったよ。
初心者がテーブルにCSVデータをインポートした まとめ
素人がCSVデータをテーブルにインポートしてみたのだが、テーブル書式とCSVデータ書式が合っていなかったので、テーブルのデータは欠落し使い物にならなかった。
こうなった理由としては、テーブルは参考書を見ながら勝手にテーブル構造を作った。
この時、CSVデータの構造を確認しなかったことが一番の原因で、この時にCSVデータの構造をチェックして、それに合わせれば良かった。
まあこれも良い経験として、テーブルを作る手順としては
- CSVデータ構造を実際に紙に書いて見える化をする
- 見える化したデータを元に、テーブル構造を検討する
- テーブル構造をSQL文に置き換えテーブルを作成する
やはり何事も見える化することが重要であることを、ここでも再認識しました。
次回はこの手順に沿って、もう一度テーブルを作り直しから始めます。