Sakiのプログラミング学習ブログ

フィヨルドブートキャンプ生。2021年中の卒業&就職を目指して学習中。

週報 1/18(月)~24(日)

1/18(月)~1/24(日)の一週間の学習の振り返りをざっくり。

今週の目標&結果

今週の目標 結果
TwitterのDB設計の合格 ○ 18(月)にレビューをいただいて再提出し、19(火)に合格🎉
外部キー記事
自己参照/自己結合の理解・記事
正規化の手順
DB設計の手順
自分がDB設計で理解につまずいた所&どうやって理解したか
TwitterURI設計の課題の提出(not必須) ○ 21(木)に提出

今週の学習時間

ラクティス外の学習や勉強会への参加は含めない。

日付 目標 実際
1/18(月) 2:00 2:15
1/19(火) 2:00 1:30
1/20(水) 2:00 3:30
1/21(木) 6:00 6:00
1/22(金) 2:00 3:15
1/23(土) 6:00 3:00
1/24(日) 6:00 4:30
合計 26:00 24:00

今週やったこと/考えたこと

1/18(月)

やったこと

  • 外部キーについて学んだことの記事を書くために、参考記事を読んだ
  • TwitterのDB設計の課題のレビューをいただけたので、再提出した
  • DB設計を学んだ時にわかりやすかった記事のリンク集を作った。また学習する時に一から探すのは時間がもったいないため。
  • 先週の週報ブログを書いた:週報 1/11(月)~1/17(日)
  • DB設計の提出物の合格の目処がたったので、今週の学習計画を立てた

考えたこと

  • 集中できない時・元気ない時用のタスクを用意してみたが、元気がない時はそれすらできないので、あんまり意味が無いと気づいた。。寝るのが一番だと思った。

1/19(火)

やったこと

考えたこと

  • TwitterのDB設計を合格した🎉ボロボロだったらどうしようと不安な気持ちでレビューを待っていたので、「全体的にいい感じです」と言っていただけて、とても嬉しかった!
  • 昨日よく眠れなかったため、今日は全体的に眠く、記事を読む時あんまり集中できず内容が頭に入ってこなかった。睡眠の質は学習に集中する上で本当に大事だなと感じている。
  • マネジメントとスペシャリストについての発表で、

マネジメントとスペシャリストは対立する概念として捉えられがち。しかし、スペシャリストといっても、ソフトウェア開発において個人だけで成果を出すことは少なく、チーム開発が多い。マネージャーも知識が求められる。 なので対立した概念ではない。

スペシャリストとは、その技術と心中することではない。 ❌何かを捨てて何かを得る
⭕興味がある技術がきたら、それも柱にすればいい

というお話がとても勉強になった。

1/20(水)

やったこと

  • TwitterのURL設計課題をスタート。
  • URL設計の課題のため、参考記事&「Webを支える技術」を自分でまとめたscrapbox/輪読会ノートを読んだ。参考記事をたくさん読んで、URL設計が何をするものなのか、どういう手順で行うのかがつかめてきた。
  • PATCHメソッドを学んだ
  • HTTPの一次情報はRFCと知った

考えたこと

  • Webを支える技術で、HTTPやURIの章は一通り理解できたと思っていたが、課題作成にあたり、今、「何がわかれば設計のやり方が分かるのか」が、分からない状態。色々記事を読んで掴もうと思う。

  • 目を全然労れていないことに気づいた。仕事中もデスクワークでPCをずっと見る、プログラミング学習中もずっと見る、休憩中もYouTubeTwitterを見てることが多いので、起きてる間ほぼずっと画面を見ていることになる。。スマホとPCの画面を常にブルーライトカットにしているが、それでも目のダメージは大きいと思う。目は一生ものなので、スマホを見る時間を減らしたり、温めたりして大事にしたい。

  • メンターさんに、「いろいろしっかり調べて、調べたことを咀嚼していますね」と仰っていただけて嬉しかった。

1/21(木)

やったこと

  • 6:00~7:00 Teamgeekの輪読会
  • 卒業生の方のHTTPに関するLT発表動画を見る
  • Webを支える技術の4,6,7章を読む
  • TwitterのURL設計を提出した🎉(今週掲げていた目標を達成)
  • Sinatraのプラクティスをスタート
    • Sinatraをインストール
    • reloaderをインストール
    • GETメソッドを使ってlocalhostに接続してwebページを取得してみる
  • 5時に起きて#hayaoki_girlsに参加。

考えたこと

  • メソッドよりも、URLの構成を考えることが難しい。ホスト名の直下に作るのか、リソースの下にリソース(子リソース)をおくのか。。
  • パスは、「どのリソースに対して」、メソッドが働きかけるのかを指すことに注意する。
  • 時間を見える化して管理したいと思い、Togglを使ってみることにした。なんと、GoogleカレンダーとTodoistと連携ができ、とても便利だったので驚いた。具体的には、Googleカレンダーの予定がTogglの方で見ることができたり、Todoistのタスクから、Togglの機能である作業開始~終了の記録をすることができる。 自分が知らないだけで、世の中はどんどん便利になっているんだな、と思った。そして使いこなしたい!と思った。

  • TeamGeekを読んで、「チームリーダーのアンチパターンの一つは、メンバーを子供扱いすること(≒がちがちに管理する)」「メンバーがリーダーに求めているのは、問題解決ではなく、問題解決の手助けをしてくれること」という話がとても身にしみた。アンチパターンに今から気づけて本当によかったと思う。

1/22(金)

やったこと

考えたこと

  • 昨日Sinatraを触ったときに理解できなかった挙動の意味がこれを読んでわかってスッキリした
  • ブロックの最後の結果を使ってhtmlを作り、ブラウザへレスポンスとして返す →なるほど、たしかにechoとは書いてないのにブラウザに" "内に入力した文字が表示される。これはsinatraがHTMLを作ってくれたからだったのか、と分かってスッキリした。
  • Sinatraは最初、GETを使うとなんだか接続できる、ということしかわかっていなかったが、たくさん文献を読んでいるうちに何をしてくれているgemなのか分かってきた。メモアプリ作るのがとても楽しみ。

1/23(土)

やったこと

  • ドットインストール Sinatra入門:全17レッスン中1~8までをやった
    • 変数
    • ERB
    • テンプレート
    • CSSを当てる
    • HTMLのformタグ・inputタグ
  • 6:00~7:40:TeamGeek輪読会
  • 15:00~16:15 初めてのLT会 Vol.6に聞き手側で参加
  • 20:15~22:00 LT会の感想ブログを書いた → 「初めてのLT会 Vol.6」 に参加させていただいた感想
  • 22:00~23:00 達人に学ぶDB設計 輪読会第4回

考えたこと

  • RailsSinatraを初めてみたとき、なぜこんなにたくさんのファイルがあるんだろう...と理解できるか不安だったが、ドットインストールを手を動かしながら見たらそれぞれのファイルの役割を理解できた!
  • 7時間連続で眠りたいと思っているが、最近5時間程度で起きて目が冷めてしまう。。今日は10時頃眠くなってしまい、2時間寝た。連続で7時間寝てすっきり起きられるようになりたい。寝る前のブルーライトが原因なきがしている。
  • 私は文章を読むよりも、動画のほうが頭に入りやすいので、今回もドットインストールを見ることにした。

1/24(日)

やったこと

  • Q&Aを読んで(Railsの)URL設計の指針を学ぶ
  • Notionを使って、メモアプリ課題のタスク洗い出しをする
    • Notionの使い方を知るのに時間がかかった
  • 22(金)と23(土)の日報提出
  • 8:15~9:15 LT会感想ブログを完成
  • 13:30~16:00 「新しいLinuxの教科書」を読む会 オンライン #9に参加
  • 21:30~ 今週の振り返り&来週の学習計画
  • URL設計課題のレビューをいただいた

考えたこと

  • 自由度が高くて使いこなすのが難しそうで、使っていなかったNotionを、メモアプリ作成のタスク洗い出しで使ってみることにした。なんとかtodoリストは見やすく作れるようになった。
  • 「新しいLinuxの教科書」を読む会で大角さんが発表で、「伝わりやすいメールの書き方」について具体的なアドバイスをくださって、とても勉強になった。
  • メモアプリのタスク洗い出しをしたが、Sinatraを使うのは初めてのため、今の段階ですべて細かく手順を洗い出しすることができない。そのため、公式リファレンスや記事でやり方を調べてタスクに洗い出してから、実装に取り掛かろうと思った。Sinatraを動かしてメモアプリを作りながら手順を考えるのは、あまり良くなさそうだと思ったため。

今週の振り返り

✅ できたこと/できるようになったこと

  • TwitterのDB設計を合格した
  • TwitterのURL設計を提出した
  • URL設計にもっと時間がかかると思っていたが、予想よりかからず、木曜からSinatraに進むことができた。
  • LT会の感想ブログを書くことができた
  • Sinatraの使い方が分かってきた。タスクの洗い出しも実装方法が分からなくて手順を書き出せない所以外は完成できた。

✅ "こうしたらもっと良かった"と思うこと

  • ラクティスに関する学習時間が、目標に対して平日は長く、休日は短い。 休日は6時間はプラクティスに割くと決めたのに、ブログ作成やイベント参加に時間を割きすぎてしまった。あらかじめ、この時間は絶対プラクティスのこの部分を進める、と予定を決めたほうがいいと思った。
  • 学習時間が平日は長く、休日は短い理由は、平日は学習時間が一日の中でとても限られており、「今やらないと今日何も進まないことになる」と、タイムリミットを意識するため、集中して取り組めているのだと思う。
    平日は時間を惜しんで学習するのに、休日は一日自由時間なので、のんびりしてしまう...。来週の雑談タイムかミートアップで相談してみようかと思う。
  • 今週は日報をその日のうちに出せないことがほとんどだった。その日の気持ちはその日しか覚えておらず、書けないので、あとから出すことはなるべく避けたいと思っている。その日のうちに出せない原因は、slackで書いている分報に時系列順で学んだことや感じたことを全部書いていて、それを日報に項目ごとにコピペすることに、時間がかかっている。それが億劫で提出までたどり着けていない。 slackに全部書くのはやめて、日報にこまめに書きながら書くか、あるいはキリのいいところで日報にコピペするか、方法を変えようと思う。

  • DB設計の復習をしなかった。URL設計の課題を提出した後、次のプラクティスに進みたいという誘惑に負けてしまった...。これでは計画を立てた意味がない。どれくらいの理解で先に進むか、ペースは人それぞれなので、スピードと質のバランスが難しい。

  • DB設計を合格する前に、URL設計の課題に着手しても問題なさそうだったので、先週始めればよかった。

来週の目標

学習時間

日付 目標
1/25(月) 2:00
1/26(火)有休 6:00
1/27(水) 2:00
1/28(木) 6:00
1/29(金) 2:00
1/30(土) 6:00
1/31(日) 6:00
合計 30:00

達成したいこと

  • TwitterのURL設計課題の再提出→合格
  • Sinatraのメモアプリの課題を提出
    • できれば。目安時間は26時間だが、みなさんの日報を見てると、もっと時間がかかりそう。
    • 今週、具体的にいつ何をするかは、これから計画する。
  • Sinatraの課題に集中して取り組みたいので、DB設計の復習はSinatraの課題を提出してレビューを待っている間に行う(2月1週目予定)

「初めてのLT会 Vol.6」 に参加させていただいた感想

はじめに

1/23(土)にフィヨルドブートキャンプ内で開催されたLT会に、聞き手側として参加しましたので、その感想を書かせていただきました。
今回のテーマは、フィヨルドブートキャンプで超えた壁」でした。


@Tazさん:「フィヨルドブートキャンプで超えたい壁」

speakerdeck.com

わかんないを超えたい」という言葉にとても共感しました。

私は、HTMLとCSSを少し学習した程度でフィヨルドブートキャンプに入会したので、ほぼ全てのプラクティスが初めて学習する内容です。
入会したはじめは理解につまづいた時にとても落ち込んでいましたが、今は新しいプラクティスに入った時に何も分からない状態になっても、学習する中で、点と点がつながって線になり、頭の中に地図ができあがっていく感覚を楽しめるようになってきました。

これからも、「分からなくて辛い」、「何が分からないか分からない」状態は何度もあると思いますが、その時は理解できた時の喜びを思い出してがんばろうと思います。


@フッシーさん:「UNIX/Linuxのキモである標準入出力・リダイレクション・パイプを説明してみよう!」

speakerdeck.com

私は「新しいLinuxの教科書」を読んだときに初めてリダイレクションやパイプを知ったのですが、最初は本の説明を読んでも、「具体的に裏側で何が起こってるんだろう?」とぴんと来なかったのを覚えています。
今でもLinuxを使っていて、「>|って何をしているんだっけ...」と調べることがあるので、今回の発表がとても勉強になりました。
コマンドを入力したときに裏側でシェルが何をしているのかの説明の図が、分かりやすかったです。

また、私は今月始めに行ったLTのスライド作成に、画像や図を使っていないのに3時間近くかかったのですが、フッシーさんは今回のスライド作成に3-4時間ほどかかったと仰っていたので、分かりやすい図を含めたこちらのスライドを短時間で作成なさったことにも驚きました。


@siroemkさん:「ssh接続で苦労した話」

speakerdeck.com

私もssh接続を学習した時に、DebianmacOSターミナルのどちらで、どの処理を行えばいいか混乱した記憶があります。
公開鍵・秘密鍵の仕組みを図で説明してくださったのが分かりやすかったです。

また、「クライアント=サーバーと勘違いしており、本当はローカルの接続したい方がクライアントだった」というお話がありました。私も学習に詰まった時に、よくよく用語の意味を調べたら自分が思っていた用語の意味と、実際の意味が異なっていたということがあるので、詰まった時は自分のそもそもの認識が間違っていないか確認するようにしよう、と思いました。


@eatplaynapさん:「Do The Next Right Thing 今できることをしよう」

speakerdeck.com

「質問するのが怖い」「英語がつらい」「輪読会する友達がいない」の3つ全てに共感でした。
私も今やっと質問をすることに恐れがなくなってきて、日報や雑談タイムで質問をしていますが、Q&Aやslackでは多くの方々の目に触れるのもあり、まだ精神的なハードルを感じています。 質問はオープンな場でした方が、同じ所でつまづいて困っている方の助けになって、メンターさんも同じことを複数回教えるという手間が減るので、「なるべくオープンな場でしなくては...!」と思っているのですが、私も@eatplaynapさんが仰ったように、心理的安全性が高い方法から始めて、徐々に慣れていこうと思いました。

他にも、苦手な英語克服のために一日一件学習内容を英語でツイートされたり、一人で擬似的に輪読会をされたり、様々な工夫をしていらっしゃいました。
@eatplaynapさんの、「今の自分にできることは何か?」を考え、学習に向き合っていらっしゃる姿に感動しました。

私も、いきなりQ&Aなどオープンな場でたくさん質問をする、外部で大勢の前で技術LTをする、などはハードルが高くて今はできないですが、日報から質問をし始めて、質問することがだんだん苦でなくなってきたり、今年のお正月に10人程度の少人数の前で初めてLTをしたりする中で、今の自分にできることをコツコツと頑張れば、最後には大きい壁を乗り越えられると思えるようになりました。


@ふーがさん:「タスクの洗い出し」

speakerdeck.com

洗い出しの手順の紹介に入る前に、タスクの洗い出しをしている方としていない方、それぞれに向けて「こういう風にきいてほしい」と伝えてくださったため、「今からこういうお話をしてくださるんだな」というのが分かって、話に入りやすかったです。

私はlsコマンドで初めて、課題に着手する前のタスクの洗い出しをしたのですが、進捗が把握できたり、要件漏れが防げたり、脱線しにくくなるなど、良いことばかりでした。それまでは、なんとなく調べて時間を溶かしてしまうことも多かったです。

ただ、私は仕様・要件を一覧でまとめていただけで、@ふーがさんのように、Notionに必要な情報や手順の細分化の洗い出しや、参考になりそうな記事やメソッドの書き出し、フローチャートの作成まではしていませんでした。 今Sinatraを使ったメモアプリの課題を行っているところなので、私もやってみよう!と思いました。


@becolomochiさん:「Virtual Hostの落とし穴にハマった件」

speakerdeck.com

私もつまづいた時に、Twitterやslackのwakaranチャンネルでつぶやいたら、フィヨルドブートキャンプの方々に助けていただいたことがあるので、分からないことを言語化して外に発信することは大切だな、と改めて思いました。


@Yusukeさん :「初めてのメモアプリ」

speakerdeck.com

私もちょうどSinatraの課題に取り組み始めたところで、メモアプリを作成するにあたって、"何から始めたらいいか分からない状態"だったので、「一つ一つの機能を言語化すると、やるべきことが見えてくる」というお話がとても勉強になりました。
頭の中だけでぐるぐると考えていると、混乱してしまうので、言語化と図を書いてみることは大事だと感じました。


@yana-giさん:「分からない」と向き合えるようになった話

speakerdeck.com

一度調べたことをもう一度調べるのは悔しいので、また調べることになりそうだと思ったことは、scrapboxに書いている。」という言葉に共感しました。
私も数ヶ月前まで、学習したことを日報に書いていたのですが、日報だとせっかくまとめても、後でどこに書いたか探すのが大変ですし、一度解決できたのにまた同じことを調べるのは時間がもったいなくて悔しいと思っていたので、去年の10月からscrapboxを使い始めました。

分かったこと単位でscrapboxに書くと、どんどん増えていくのが嬉しい」というお話が印象的でした。たしかに、自分のがんばりが見える化されるのは嬉しいですし、学習に詰まった時に励みになると思いました。


オーガナイザー:@Yusukeさん

今回のLT会は@Yusukeさんがオーガナイザーをしてくださいました。素敵な会をありがとうございました!

  • あらかじめ全発表者のスライドをslackに載せてくださる
  • たくさん発表者がいて、後で書く時に忘れてしまうかもしれないため、アンケートのURLを先に送ってくださる
  • タイムキーパーをしながら、司会としてコメントしてくださったり、slackの質問を拾ってくださる

など、発表者や聞き手の方々への気遣いをたくさん感じました。
オーガナイザーは事前の準備もきっととても大変だと思うのですが、イベント中に色んなことを同時並行でこなしていらっしゃる姿を見て、私はマルチタスクが苦手なので、臨機応変に動いていらっしゃってすごい...と思いました。 あと、イベントの段取りのスライドがかわいかったです。


おわりに

オーガナイザーと登壇者の方々、素敵な会をありがとうございました。 私もLTで自分が学んだことをアウトプットしたくなりました!本当にお疲れさまでした。

週報 1/11(月)~1/17(日)

1/11(月)~1/17(日)の一週間の学習の振り返りをざっくり。

今週の目標&結果

今週の目標 結果
TwitterのDB設計を合格する 提出物の画像のURIを間違えたため、まだレビューをしていただいていない
記事:draw.ioの使い方備忘
記事:正規化の手順 主キー/外部キーを先に書いた方がいいと思ったため、途中
記事:主キーとは
記事:外部キー
記事:DB設計の手順 提出物合格してから書こうと思ったため✗
記事:中間テーブル
記事:自己参照/自己結合 理解できていないため✗
記事:自分がDB設計で理解につまずいた所&どうやって理解したか 途中/合格してから書く

今週の学習時間

ラクティス外の学習・勉強会への参加は含めない。

日付 目標 実際
1/11(月) 6:00 5:15
1/12(火) 2:00 1:30
1/13(水) 2:00 4:00
1/14(木) 6:00 5:45
1/15(金) 2:00 2:45
1/16(土) 6:00 2:45
1/17(日) 6:00 4:45
合計 30:00 25:00

今週やったこと

1/11(月)

  • TwitterのDB設計のER図を提出した
  • draw.ioの使い方をブログに書いた
  • 自己参照/自己結合の理解ができなかった

ラクティス外

  • 週報をブログに書いた

1/12(火)

  • ブログ書くために日報と達人を読み返した

ラクティス外

  • 6:00-7:00 TeamGeek 輪読会
  • 19:30-21:00 健康LT第2弾:仕事の疲れ&睡眠について語ろうLT雑談会 #techplaygirlsに参加
  • 22:00-22:30 日報のまとめ
  • プログラミングスクール生へ、採用の現場よりを読んで気になった所。

    「今日やったこと!」的なlogをTwitterで見せるくらいなら、ブログなんかに書いたほうがいい。 なぜかというと、どんなことを学んで、どんなところで失敗し、次にどう活かすかをまとめる技術って、仕事で活きてくるのよね。 それを140字でやれるならすごいけど、いわゆる学んだ過程はしっかりひとつの記事にまとめたほうが結果として自分の身になると思う(し、書類審査側も面接官のエンジニアへのトスアップが判断がしやすい)

→週報ブログもこれに当たると思うので、続けていこうと思った。 - 睡眠の質向上には、朝の15分の散歩が一番効果的だったと教えていただいた

1/13(水)

  • データベースに関してブログ記事作成
    • データベースに関する用語まとめ:そもそもデータベースとは何なのか?今課題でやっているデータベース設計はシステム開発の中でどういう位置づけなのか、テーブルなどの用語について自分なりの言葉にしてまとめた。
    • SQLコマンドまとめ:毎回調べるのは大変なので、一つの記事にまとめた。データベースの操作、テーブルの操作、カラムの操作、SQL構文、句のまとめ。 今日は仕事後の集中力がなかったので、急遽正規化の記事ではなくSQLコマンド集の記事を書いた。

ラクティス外

  • 21:00~23:00 Fukuoka.rb #192に参加させていただいた

1/14(木)

  • 正規化」の記事を書いた(途中)
  • 「主キー」を説明する記事を書いた:【DB設計】 主キーとは
  • DB設計はOne Fact in One Place(1つの事実は1つの場所に)。これを徹底すると正規化される。

ラクティス外

学んだこと

  • 正規化しないとどうなるか?:一つの事実が複数の箇所にあると複数の箇所を同時に常に更新していかないといけない。
    →複数あるとどこか一つに登録し忘れた時に不具合が起こってしまって大変だと思った。
  • 現在の仕事のやり方ではDB設計してからコード書くことはしない。きっちり設計したところでどうせ変わるので、ボトムアップでちょっとずつテーブル増やしたりカラム追加したりしながら作ることが多い。
  • Railsは主キーは必ず自動採番の数値データ。キー自体に意味をもたせることが基本的にない。この辺はデータベースの本に書いてあるようなこととは随分印象が違うかも。
    Railsのプラクティスに入ったらまたDBに対する理解が深まりそうと思った
  • DB設計を先にきっちり設計しているのはウォーターフォール形式の開発だけという傾向はあるかも。後は分野にもよる。
    • お金を扱うシステムや医療系など人命に関わるもの、重要な個人情報を取り扱うようなシステムだと、後で取り返しがつかないことが起きないように最初にかなりきっちり設計する
    • 新しいウェブサービス(Twitterなど)などそもそも世の中にないものを生み出すときは、完成形がわからないので走りながら変えるしか無い。 →新しいウェブサービスだと、ユーザーに使ってもらってフィードバックをもらって、やっぱりこの機能はなくそう→設計を変えるということがありそう。
  • TeamGeekで、「積極的にチームとコミュニケーションをとって、自分の仕事を知ってもらうようにしよう」とあった。 たしかに、
    • スクラム開発のプラクティスでも良い意味で騒ぐ人=自分の状況を細かく報告する人がうまくいく
    • 自分が3~4名の方の上司的な役割をした時に、分からないときに一人で抱え込んでしまう方よりも、適切に今のしごとの進捗状況や困っていることをまめに報告してくれる方のほうが仕事しやすかった
    • フィヨルドで質問について議論がされたときに、メンターさんが、質問された方が「この人は何が分からないんだろう?」とか、どこに指摘するべきだろう?と考えるよりラクとコメントされていた。

→たしかに仕事でも学習でも、その人が何がわからなくて困っているかはその人にしかわからないので、積極的に発信した方が良いな、と思った。

1/15(金)

  • 大名エンジニアカレッジの特別編:データベースを視聴

1/16(土)

ラクティス外

  • 6:00~7:00 TeamGeek輪読会
  • 睡眠の質向上のため、朝30分お散歩に行ってきた

1/17(日)

  • TwitterのDB設計で誤りに気づいたので、追加修正した

今週の振り返り

✅ できたこと/できるようになったこと

  • 初めて地域rbに参加した。
  • 質問することにためらいが無くなってきた
  • 今週は体調不良にしては記事作成などがんばれたと思う
  • DB設計に関する記事を4つ書けた。記事を書くなかで、なんとなく理解していてきちんと説明できない所が浮き彫りになった。
  • 土曜から休日の朝散歩を始めた
  • 睡眠の質向上のためのTipsについてたくさん知れた

✅ "こうしたらもっと良かった"と思うこと

  • Fukuoka.rb #192に参加させていただいたが、カメラオフ&緊張していたのもあってうまくコミュニケーションがとれずもくもくしていた。次回からはカメラオンにしたり、チャットを使ったり、コミュニケーション取るようにがんばる
  • 最近やっと質問できるようになってきたが、日報で質問するのが一番ハードルが低く、ついつい日報で個別に質問してしまっていて、オープンな場でできていない....。私が個別に解決できただけだとフリーライダーになってしまって申し訳ないので、これからDB設計を学ぶブートキャンプ生に向けて「今DB設計でつまづいたこと&どうやって理解したか」の記事もちょこちょこ書き進めている。が、これに加えて、Q&Aに投稿して自己回答したらもっといいかもしれないと思った。
  • 振り返ると、休みの日よりも、仕事がある日の方が、時間が限られているという意識が働くせいか、学習に専念できている。休日の学習時間を増やしたい。一日全部自由時間にするよりも、勉強会やイベントがある方が時間にメリハリがつくので、気になったものに申し込んだ。
  • 日報をその日のうちに出せてないことが多かった→次の日の朝に書くのは集中力がもったいないのでその日の夜に書くようにする。
  • 記事作成にかかる時間の見通しが甘く、2倍以上かかった。説明するための例えのテーブルを作ったりすると時間がかかる。
  • 自己参照/自己結合の理解ができなかった
  • 画像のURL化がきちんとできているか確認すべきだった
  • 朝6時台に起きても、寝るほど眠くはないけど眠い状態が続いているので改善したい。休日の昼寝が夜の睡眠に悪影響を及ぼしているのかも。

考えたこと

  • 「自分の話した言葉が相手にちゃんと伝わっているか不安。自分の言語化能力がどの程度のレベルか知りたい」と一緒に輪読会をしてる方に話したら、「質問した時に自分が言語化できているかどうかは、自分が決めることでは?聞きたいことを知ることができて、分かりにくいと指摘されたわけでなければ、きちんと言語化できていると思う」と言われた。それを聞いて、たしかに自分が聞きたいことは自分にしか分からないことだな、と思った。
    また、話を聞いてもらったことで、言語化能力の問題ではなくて自分が変なことを言ってないか・変に思われていないか不安という自信のなさから来ている問題ということに気づけた。
    →ひとまず、質問した時は、聞きたいことを聞けて、疑問を解決できれば他のことは気にしないようにしようと思った。
  • たまに日報が丁寧で分かりやすいと褒めていただくので、ブログというオープンな場でも文章を書いて役に立ちたいと思った。
  • 雑談タイムで日報に気持ちを書いてくれるとメンターさんも嬉しいということがわかった。"本を読んだ"など、やったことだけを書かれると、簡単にできたのか?難しかったか?などが分からないのでありがたい&お気持ちを書くといろんな方がコメントくださって情報が集まることもあるとのこと。→引き続き書いていこうと思った。

来週の目標

  • TwitterのDB設計の合格
  • DB設計で学んだことをブログに書く
    • 外部キー
    • 自己参照/自己結合
  • 以下は合格したら書く
    • 正規化の手順
    • DB設計の手順
    • 自分がDB設計で理解につまずいた所&どうやって理解したか
  • TwitterURI設計の課題の提出:DB設計の出来具合によって、取り掛かれる日が変わるので必須にはしない。

【DB設計】 中間テーブルとは

Twitterのデータベース設計の課題を作成するにあたり、中間テーブルについて学んだので、自分なりにまとめた。

中間テーブルを理解する前に

中間テーブルを理解するためには、テーブルのリレーションシップや、ER図について理解しておく必要がある。 以下の記事の説明が分かりやすい。

 やさしい図解で学ぶ ER図 表記法一覧

また、この記事に出てくる、テーブル,エンティティ,レコードなどの用語については以下の記事に書いている。

 データベースに関する用語まとめ

リレーションシップは4種類だけ

テーブルのリレーションシップは4種類のみである。

  • 1対1
  • 1対多
  • 多対1
  • 多対多

一番最後の多対多の関係になっているテーブルは、そのままでは結合することができない。 これを解決する方法の一つとして、2つのテーブルの間に「中間テーブル」というテーブルを配置する、というやり方がある。

そもそも多対多とは、どういう関係か?

中間テーブルについて説明する前に、そもそも多対多がどういう関係なのかを先に説明する。

学生とサークルの関係を例に考える。

✅ 学生から見た、サークルとの関係

学生一人が所属できるサークルの数は、複数である。そのため、学生から見たサークルとの関係は、学生:サークル=1:多である。
(学生はサークルには絶対に所属しなくてもいいため、厳密には1対0~多の関係)

✅ サークルから見た、学生との関係

一つのサークルに対して、複数人の学生が所属することができる。そのため、サークルから見た学生との関係は、サークル:学生=1:多である。
(学生が一人も所属していない、0人のサークルが存在する可能性があるため、厳密には1対0~多の関係と考える)

✅ 学生とサークルの関係は、多対多

以上のことから、学生:サークル=多対多の関係であることが分かる。

多対多の関係のテーブル同士を結合したい

✅ テーブルを作ってレコードを入れてみる

2つのテーブルを作り、レコード(実際のデータそのもの)を入れてみると、以下のようになる。

【学生テーブル】

学生ID(主キー) 学生の名前
1 山田花子
2 佐藤太郎
3 田中桜子


【サークルテーブル】

サークルID(主キー) サークル名
1 放送研究会
2 スポーツ新聞部
3 英語部
4 映画研究会
5 野球部


ここで、

  • 学生が何のサークルに所属しているか
  • どのサークルにどの学生が所属しているか

をデータとして管理するデータベース設計をしたい場合、学生とサークルの2つのエンティティにリレーションシップを設定する必要がある。

しかし、

リレーショナルデータベースの「お約束」として、この多対多の関連は作ってはならない

(『達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ』(ミック 著,翔泳社,2012年出版)の128ページより)

とあるため、多対多の関係のテーブルはそのまま結合することができない。

f:id:Saki-Htr:20210116150311p:plain
このままではリレーションシップを設定できない

そこで、中間テーブルが必要になる。

✅ 2つのテーブルの間に中間テーブルを配置する

2つのテーブルの間に、中間テーブルを配置すると、以下のようになる。

f:id:Saki-Htr:20210116150240p:plain
中間テーブルを配置したER図

中間テーブルを作る時は、接続先のテーブルそれぞれの主キーを、外部キーとして持たせる
今回の例でいうと、学生_サークルテーブルには、学生テーブルの主キー「学生ID」と、サークルテーブルの主キー「サークルID」を、外部キーとして持たせている。

これによって、学生エンティティとサークルエンティティに、リレーションシップを設定することができる。

✅ レコードを登録してみる

実際にレコードを3つのテーブルに登録してみると、分かりやすい。


【学生テーブル】

学生ID(主キー) 学生の名前
1 山田花子
2 佐藤太郎
3 田中桜子


【サークルテーブル】

サークルID(主キー) サークル名
1 放送研究会
2 スポーツ新聞部
3 英語部
4 映画研究会
5 野球部


【学生_サークルテーブル】

学生_サークルID(主キー) 学生ID(外部キー) サークルID(外部キー)
1 1 3
2 1 5
3 2 2
4 3 2
5 3 1
6 3 4


中間テーブルを配置すると、

  • 学生が何のサークルに所属しているか
  • どのサークルにどの学生が所属しているか

というデータを抜き出せるようになる。


この例でいうと、

  • 学生のデータを抜き出したい場合
    • 山田花子は英語部と野球部に所属している
    • 佐藤太郎はスポーツ新聞部に所属している


  • サークルのデータを抜き出したい場合
    • 放送研究会に所属している学生は、田中桜子
    • スポーツ新聞部に所属している学生は、佐藤太郎と田中桜子

ということが分かる。

中間テーブルの特徴まとめ

  • 多対多の関係のテーブルを結合したい時の解決法の一つ
    (状況によっては、中間テーブルを作った方がいいケースばかりではない)
  • 2つのテーブルの間に配置する
  • 2つのテーブルそれぞれの主キーを、外部キーとして持つ

参考記事

【DB設計】 主キーとは

主キーを理解していないと、データベース設計で行う正規化を理解することができないので、自分なりに学習して理解したことをまとめた。

アイデンティファイアとは

  • アイデンティファイア(ID)とは、「このレコードは他のレコードとは違う」と、識別するためのもの。
  • 例えば、社員に関するデータが登録されているテーブルがあり、そこにたくさんの社員のレコードが登録されていたとする。 この時、社員を個人一人に特定できるようなカラム(列)がアイデンティファイアになる。この例なら、社員番号などがアイデンティファイアとなる。
  • キーはこのアイデンティファイアの中から選ばれる。

主キーとは

そのテーブルのレコードを一つに特定できる組み合わせのこと。 詳しくは以下。

主キーを満たす条件

  1. レコード(タプル)を一つに特定できること
  2. そのカラムのレコードがNULLにならないこと
  3. 最低限の数の組み合わせであること
    カラム一つではレコードを一つに特定できないが、カラムが2つだと特定できる、3つでも特定できるとなった場合、最低数である2つの組み合わせのカラムが主キーである。
    (極端に言えば、すべてのカラムを組み合わせれば、絶対に一つのレコードを特定できてしまう...)

私の失敗:主キーは一つのテーブルにつき、常に一つだけだと勘違いしていた

  • 主キーを満たす条件の3つめに、「最低限の数の組み合わせであること」という条件がある。
  • 私が最初に主キーを学んだのは、『達人に学ぶDB設計』(以下、『達人』と記載)という本なのだが、この本を読んだ時に主キーは一つのテーブルに常に一つしかないと勘違いしていた。ここを勘違いしていると、後に説明する、正規化の手順を理解できなくなってしまうので注意が必要。

  • 勘違いした理由は、 『達人』のp.73では、

    その値を指定すれば、必ず1行のレコードを特定できるような列の組み合わせ

と説明をしてくれている。

が、主キーを説明するための例えのテーブルが、主キーが一つのテーブルだったため主キーは一つのテーブルに一つだけと勘違いしてしまった。

以下がそのテーブル。「社員ID」というカラムが主キーのテーブル。

社員ID 社員名 年齢 部署
000A 加藤 40 開発
000B 藤本 32 人事
001F 三島 50 営業
001D 斉藤 47 営業
009F 田島 25 開発
010A 渋谷 33 総務

( 『達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ』(ミック 著,翔泳社,2012年出版,全360ページ)のp.73より引用)

  • 主キーは一行のレコードを特定できる“組み合わせ“という説明で、複数以上を連想させておいて、例えのテーブルが主キーが一つしかなかったのが、個人的に分かりづらかった。

「社員名」が主キーではいけない理由

上記のテーブルで、「社員名」も主キーにできるように見えるが、同姓同名がもし登録されたら、レコードを一つに特定できなくなるので、不適切。 他にも例えば、お店が商品に関するデータベースを持っていたら、商品名は主キーとして不適切。

主キーが複数の場合はどんなテーブルか

以下のテーブルを使って、それが主キーになるか説明する。

伝票番号 取引先番号 取引先名 商品コード 商品名 数量
1 101 A商事 1 プリン 50 
1 101 A商事 2 シュークリーム 10 
2 102 B建設 1 プリン 5
2 102 B建設 3 クッキー 100
2 102 B建設 4 アイス  20
3 101 A商事 2 シュークリーム 15
3 101 A商事 3 クッキー 40
4 103 C銀行 2 シュークリーム 30
  1. まず、取引先名,商品名,数量はアイデンティファイア(ID)ではないため、候補から除外する。
  2. 主キーの候補となる伝票番号,取引先番号,商品コード を順番に見ていく。
    • 伝票番号:1が2つのレコードに登録されているなど、同じ番号が複数あるため不適切
    • お得意先番号:101が4つのレコードに登録されているなど、同じ番号が複数あるため不適切
    • 商品番号:1が2つのレコードに登録されているなど、同じ番号が複数あるため不適切

→このことから、一つのカラムでは主キーになることができないことが分かる。

  1. カラム2つの組み合わせで主キーにできないか見ていく。
    - 伝票番号とお得意先番号:伝票番号1でお得意先番号が101のレコードが2つあるので、主キーではない  
    - お得意先番号と商品番号:お得意先番号101と商品番号1002のレコードが2つある(2行目と6行目)ので、主キーではない 
    - 伝票番号と商品番号:伝票番号は1で商品番号が1のレコードは一つしかない
    

    伝票番号と商品番号の2つのカラムを組み合わせたら、一つのレコードを特定できる。

  2. よって、このテーブルの主キーは伝票番号と商品番号

参考書籍/参考記事

SQLコマンドまとめ

これまで学んだSQLコマンドについてまとめた。

  • SQL文をうつ時は文末にセミコロン;を忘れない。忘れると文が終わらない。

データベースの操作

データベース作成

createdb <データベース名>

データベース一覧

psql -l

データベース削除

dropdb <データベース名>

データベースに接続

psql <データベース名>

データベースの接続終了

\q

操作方法

help

helpよりもっと詳しい操作方法

\?

テーブルの操作

テーブル作成

# 同時にカラムも登録できる
CREATE TABLE テーブル名 (列名1 データ型1 制約1 , 列名2 データ型2 制約2);

# 一度に複数のカラムを登録したい
CREATE TABLE テーブル名 (
   列名 データ型 制約
   CardID nchar(6),
   CustomerID nchar(5),
   IssueDate datetime,
   ExpireDate datetime,
   EmployeeID int
 )

テーブル一覧表示

\dt

テーブルに設定されてるカラム(列)確認

 \d <テーブル名>

テーブル名変更

alter table <変えたいテーブル名> rename to <変更後の名前>;

テーブル削除

drop table <テーブル名>

カラムの操作

カラム追加

alter table <テーブル名> add <カラム名> <データ型>;

カラム削除

alter table <テーブル名> drop  <カラム名>;

カラムの名前変更

rename <変更前カラム名> to <変更後カラム名>;

カラムのデータ型を変更

ALTER TABLE テーブル名 ALTER COLUMN カラム名 TYPE データ型
例: alter table users alter myname type varchar(32);

INSERT:テーブルにデータを登録する

INSERT  INTO テーブル名 (列名1 , 列名2, …) VALUES (入れたい値1 , 値2 …);

# 例
insert into posts (title, body) values (‘title1’,‘body11111’);
#=>titleというカラムにtitle1という値、bodyというカラムにbody11111を登録する

SELECT:必要なデータを検索して取り出せる

SELECT 列名, … FROM テーブル名;

すべてのカラムを取り出す

select * from テーブル名

一部のカラムを取り出す

select <カラム名> from <テーブル名>

テーブルを複数扱うとき

テーブル名前.フィールド名 と書く

UPDATE:レコードの値を変更する

update <テーブル> set <変えたいカラム> = <値> where <レコード> = ‘<変えたいレコード>‘;
  • データ型が数値のカラムを+1で変えることもできる。

DELETE:レコードを削除する

delete from <テーブル名>

これを入力すると、 指定したテーブルに登録されているレコードすべてを消してしまうので注意! whereで条件をつけて消せる。

トランザクション

  • トランザクションとは、"複数の処理をまとめて行う処理"の仕組み。
  • commitとrollbackがある。

commit

1. begin; でトランザクション開始
2. SQL文①;
3. SQL文②;
4. commit;    # これを打つと、2~3で打ったSQL文の処理が実行される

rollback

  • commitをしないで、やっぱりやめること。
1. begin;  でトランザクション開始
2. SQL文①;
3. SQL文②;
(4. select * from <テーブル名>  で、2~3で実行した結果を確認できる)
5. 結果を見て、やっぱり2~3でやった処理を無かったことにしたい時、rollback;する。

f:id:Saki-Htr:20210113222246p:plain
トランザクションをやってみた例

旬の使い方

  • WHERE
  • LIKE
  • ORDER BY
  • LIMIT
  • OFFSET
  • GROUP BY
  • HAVING

WHERE:取り出すときの条件を指定できる

select <フィールド> from <テーブル> where <抽出したい条件>

#scoreの数値が4.0より大きいという条件で、usersテーブルの全カラムを取り出す
select * from users where score > 4.0 

# nameが'taguchi'のものだけを抽出したい
select * from users where name = ‘taguchi’

LIKE:対象のカラムに対して文字列検索

like <検索したい文字列>
  • 任意の文字0文字以上:%
  • 任意の文字1文字以上:_
  • 参考:【SQL】LIKE句

f:id:Saki-Htr:20210113223409p:plain
LIKEを使ってみた例

ORDER BY ::レコードの並び替え

order by <カラム名>
  • カラムのデータが数値の場合、小さい順になる f:id:Saki-Htr:20210113223614p:plain

  • 大きい順にしたい:descを付ける f:id:Saki-Htr:20210113223834p:plain

  • 複数の条件をつけられる f:id:Saki-Htr:20210113223816p:plain

LIMIT:取得するデータの行数の上限を設定

LIMIT <取り出す数>

f:id:Saki-Htr:20210113224003p:plain

OFFSET:取り出す開始位置を指定

開始位置は、1番目が0(Rubyのインデックスと同じ) - offset 0 = 1番目が開始位置 - offset 1 = 2番目が開始位置 

f:id:Saki-Htr:20210113224209p:plain

GROUP BYとHAVINGは集計したレコードに使う

GROUP BY:レコード集計したものを、グループごとに取り出す

例:scoreの合計値を「teamごとに」出したい

f:id:Saki-Htr:20210113224435p:plain

HAVING:レコード集計したものに、条件をつける

  • 例: チームごとのスコアの合計を集計→そこから更に、スコア合計が10以上のものを取り出したい = 上記のselect team , sum(score) from users group by teamに、having sum(score) > 10.0; を足す。

f:id:Saki-Htr:20210113224536p:plain

参考記事

データベースに関する用語まとめ

✧ データベースとは

  • 整理されたデータのまとまり
  • 大量のデータをコンピュータシステム上で扱えるように集めたもの
  • 大量とはエクセルで管理できるレベルでなく、数千万件、数十億件の数

データと情報のちがい

  • データとは:事実のみを指す。あるフォーマットに揃えられている。
  • 情報とは:データを部分的(全体の場合もある)に収集、加工したもの
  • 天気予報で例えると、
    • データは観測側で決めた数値を観測したもの
    • 情報は、そのデータを用いて晴れの確率、雨の確率を導き出したもの。普段ニュースで見ている天気予報はこっち。

✧ リレーショナルデータべース(RDB)とは

  • データを表形式で扱うデータベースのモデル
  • 他にも様々なデータベースのモデルがあるが、プログラマーを目指すなら、まずはRDBをできるようになる必要がある

リレーショナルデータベースマネジメントシステム(RDBMS)とは

  • リレーショナルデータベースを便利に使うためのソフトウェア
    例:オラクルデータベース、MySQLPostgreSQL

SQLとは

  • リレーショナルデータベース(RDB)を読み書きするときに使う言語

RDB, RDBMS, SQLの3つの関係

  • Postgresqlなどのリレーショナルデータベースマネジメントシステム(をSQLという言語を使って操作し、これによりリレーショナルデータべースデータベースを扱うことができる。

✧ リレーショナルデータべース(RDB)の設計

  • 以下より、リレーショナルデータべース(RDB)の設計=データベース設計と記載

設計は、システム開発のステップのどこに当たるのか?

  • 開発には4つのステップがある
    • 要件定義
    • 設計 ←リレーショナルデータべース(RDB)の設計はここに当たる
    • 開発
    • テスト
  • この4ステップのうちデータベース設計が当てはまるのは設計。 設計はデータベースだけを設計するのではなく、ユーザーが使用する画面の設計や機能を決めるアプリケーション設計など、他にも色々設計することがある
  • この4つをどう進めるかのやり方は主に2つに分かれる。
    ウォーターフォールモデルとプロトタイピングモデル(これを応用したのがアジャイル)

データベース設計の3つのステップ

データベース設計にも段階があり、3つのステップがある。
1. 外部スキーマ/ 2. 概念スキーマ/ 3. 内部スキーマ

1. 外部スキーマ

  • ユーザーから見たデータベース。画面のユーザーインターフェースや入力データなど。
  • 例えば、Twittterのアカウントのプロフィール画面では、ユーザー名(@から始めるID),表示名,自己紹介文,位置情報,ウェブサイトなどのURL,誕生日,いつからTwitterを使っているか,今フォローしている人数,今フォローされている人数,時系列順になったツイートの一覧,リプライも含めたツイート一覧,画像・動画がついたツイート一覧,いいね一覧,おすすめツイート,トレンドなど、ユーザーは様々なデータベースを見ることができる。

    このように、プロフィール画面に何のデータを表示するかや、データをどのように画面に表示するかなどを定義するステップが、外部スキーマである。

2. 概念スキーマ

  • データベースに格納するデータの洗い出し、そのデータ同士の関連性の定義を行う。
    = 論理設計という。
  • この「論理」とは、データベースサーバーのCPUパワーやストレージの格納場所など、物理層の制約にとらわれない設計ということを意味する。
  • データベース設計を行う時は、まずこういった物理層の制約は無視して先に論理設計を行う。
  • フィヨルドブートキャンプのTwitterのデータベース設計の課題はこれに当たる。

3. 内部スキーマ

  • 論理設計で定義されたデータを、具体的にどのようにリレーショナルデータベースマネジメントシステム(RDBMS)に格納するかを定義する。=物理設計という。

✧ 論理設計で出てくる用語まとめ

f:id:Saki-Htr:20210113070746p:plain
テーブルの見方
(データベースの用語を理解しよう 「テーブル」「レコード」「カラム」「フィールド」とは?より引用)

エンティティ/テーブル

  • エンティティとは、データの集合体。 例:顧客、会社、社員、店舗、車、注文履歴、税
  • リレーショナル・データベースでは、これを二次元表に近いテーブルという物理的な単位で格納して、データを表現する。

列(カラム,属性)

  • エンティティは、データを属性という形で保持する
  • 例えば、顧客というエンティティが持つ属性は、顧客の名前、生年月日、住所、電話番号など。

行(レコード,タプル)

  • 登録・管理されるデータそのものを指す。
  • 例えば、上記の顧客テーブルのレコードは、
    • 顧客の名前:山田花子
    • 生年月日:1990年1月1日
    • 住所:東京都大田区○○町1-1-1
    • 電話番号:03-1234-5678

この山田花子に関する実際のデータそのものを指す。

✧ 参考書籍/参考記事