宮水の日記

宮水の日記

主に書評や資格取得について記事を書いています。

「3000万語の格差」を読みました

「3000万語の格差」を読みました。

なぜ読んだのか

「3歳までの赤ちゃんへの語りかけが、その後の学力に大きく影響する」というツイートをTwitterで見かけて、気になったので。

本の概要

1章は、なぜ人工内耳外科医だった筆者が家庭の言語格差の問題に気付いたのか。2-4章は、どのような研究を行ったか。5章は「3000万語イニシアティブ」の具体的な内容について。6章は、「3000万語イニシアティブ」が社会に与える影響について書かれています。

具体的に何をすればいいのかが一番気になるところだと思うので、この本で最も重要なキーワードである、3つのTだけ紹介します。

1. チューンイン
「子供に何かしてあげようとする親よりも、子供がしていることに関心を持つ親が最も子供の脳を育てる」

例)子供が犬を指差しているときに「大きな犬がいるね」とにっこり笑ってあげる。

大人でも、関心を持ったものでないと覚えられない・集中できないのと一緒です。子供が関心を持ったものに対して反応してあげることで、子供はぐんぐん言葉を吸収します。

2. トークモア
「単語の数だけでなく、どんな単語を使うのか、どのように話すのか、言葉の質が重要である」

例)赤ちゃんの世話をするときに、大人が「さあおむつを替えようね」「気持ちがいいねえ」と赤ちゃんにあたたかく話す。

他にも、大人がしていることを言葉にし、子供がしていることの実況中継をする。
「これ」「あれ」などを使わずに、具体的な名詞を話す。子供の言葉をふくらませると良いそうです。

3. テイクターンズ
「子供の言葉を繰り返したり、もっと話したくなるように質問したり、子供の反応をじっくり観察する」

例)子供が両手で持った積み木を打ち鳴らしているときに「カンカンカンカン」と行為や言葉をつけるのはチューンイン。大人は「積み木を積んでごらん」「おうち作ってごらん」などと言いがち。それをやめて、子供の反応をよく観察するのがテイクターンズ。

4. おまけ:ターンオフ
テレビやYouTubeの時間を減らし、外に連れて行ってあげたり、子育て支援センターで手を使って遊ぶ時間を増やす。

感想

本書には、色々とツッコミどころがあるようです。「研究対象である世帯が少なすぎる(確か42世帯くらい)」「米国で、さらに米国の中でも特に貧困である層についてのエピソードが多い」などです。それに、「3歳までに子供が聞く言葉が、子供の将来に多大な影響を与える」なんて言われたら誰でも難色を示すでしょう。ただでさえ一生懸命子育てをしている私たちには、プレッシャーになってしまうような内容も多くありました。(しかも、無駄なエピソードの途中に突然重要な内容がブッ込まれたりしてて非常に文章が読みにくかったです。)

この本では、3つのTだけ拝借すればいいと思います。5章では、3つのTに関して具体的にどんな声かけをしたら良いのか詳しく載っているので、そこを読むだけでもとても勉強になりました。子育てのバイブルとして、子供が独り立ちするまでは家に置いておこうと思いました。

超個人的な感想

私は、この本を読んで0歳の息子を保育園に預けるのが怖くなりました。訳者の日本の保育園に関する記述は興味深かったです。"子供は「今日は誰とも話さなかったよ」「つまんなかったよ」と保護者に言えない" ”11時間や12時間も預けられている子供は日本だけ”などを読んでハッとさせられました。この本を読むまで私は、保育者のプロがいる保育園に行く方が、社会性も身につけられたり、歌を歌ってもらえたりして私たちが育てるよりも良いと思っていたからです。一人の先生が3人をみるわけだから、今までよりも1対1の会話が少なくなるのは当然です。

とはいえ、ありがたいことに保育園に通わせることができるようになったので、今できることをしていこうと思います。
例えば、朝早起きして子供と触れ合う時間を作ったり、残業をしないようにスキルを磨いたり。子供と一緒にいられるときは、全力で向き合おうと心に決めました。

ここまでお読みいただきありがとうございました!

「コンピュータはなぜ動くのか」を読みました

コンピュータはなぜ動くのかを読みました。

なぜ読んだのか

初心にかえってコンピュータの基礎を学びたかったため。

この本で学べること

  • コンピュータ技術の知識の範囲、絶対的な基礎
  • コンピュータの本質

本の概要

第1章 コンピュータの3大原則とは
  • コードとは、コンピュータで取り扱うために数値化された情報のこと。
  • コンピュータの3大原則

⒈ コンピュータは入力、演算、出力を行う装置である
 どんなに複雑な機能であっても、入力、演算、出力を一つの単位としてそれらを数多く組み合わせて実現されている。
⒉ プログラムは、命令とデータの集合体である
⒊ コンピュータの都合は人間の感覚と異なる場合がある
 コンピュータは色や文字など、なんでも数値で表す。だから半角文字もリンゴは4文字になる。

第2章 コンピュータを作ってみよう
  • 紙の上でマイクロコンピュータの製作を疑似体験してみる、という内容。
  • 設計図の配線をなぞることで、CPUとメモリーとI/Oの関係がちょっとわかった。
  • 実際に手を動かした方が楽しそうだったので、フリマアプリでArduino(アルドゥイーノ)を買ってみた。
第3章 1度は体験して欲しいハンド・アセンブル
第4章 川の流れのようにプログラムは流れる
  • プログラムの流れは順次進行・条件分岐・繰り返しの3つ。
  • この章では、フローチャートの書き方について学ぶ。
  • プログラムの流れには、「割り込み処理」と「イベント・ドリブン」という特殊な流れもある。
  • イベント・ドリブンは状態遷移図などで表したりする。
第5章 アルゴリズムと仲良くなる7つのポイント
第6章 データ構造と仲良くなる7つのポイント
  • 一般的なパソコンでは、メモリーの内部が8ビット=1バイトごとのデータ格納領域に区切られていて、それぞれの領域を区別するための番号が付けられている。この番号のことをアドレスという。
  • 変数を宣言すると、メモリー領域を確保してくれる。
  • データ構造の基本は配列。定番のデータ構造には、スタック、キュー、リスト、2分木などがある。
  • 構造体とは、複数のデータを一つにまとめて名前を付けたもの。
第7章 オブジェクト指向プログラミングを語れるようになろう
第8章 作ればわかるデータベース
  • 酒屋さんのデータベースを設計する
  • 主キーと外部キーについて
  • 検索速度を向上させるインデックスについて
第9章 簡単な実験7つでTCP/IPネットワークを理解する
第10章 データを暗号化してみよう
第11章 そもそもXMLって何だっけ
第12章 SEはコンピュータ・システム構築の現場監督
  • SEとは、コンピュータ・システム全体に関わるエンジニアであり、プログラミングだけに関わるプログラマとは違う。システムとは、「複数の要素が関係しあい、まとまって機能する系統」のこと。
  • 顧客は、コンピュータの技術を望んでいるのではありません。コンピュータによるITソリューションを期待している。顧客の要求通りに役に立ち、安定して稼働するコンピュータ・システムであることが大切!

感想

ハードウェアからソフトウェアまで包括的にコンピュータの基礎知識が解説されていました。小さなコンピュータの世界から、大きなシステムの世界へ章を追うごとに進んでいくので、とても分かり易かったです。基本情報技術者試験を受ける人にとっては、これを読む前と読んだ後では問題の理解度が全然違うと思います。

2章と3章は私にはちょっと難しい内容になっていましたが、少しだけプログラムが動く仕組みがわかった気がします。アセンブラを書いてみたり、ちゃんと理解すれば、プログラミング言語のより踏み込んだ技術書が読めるようになりそうです。より詳しい内容は、「プログラムはなぜ動くのか」を読んでみたいと思います!

ここまでお読みいただきありがとうございました!

今年のエンジニアとしての振り返り2021٩( ᐛ )و

みなさんこんにちは。宮水です。
毎年恒例、今回もエンジニアとしての振り返りをしていきたいと思います。

去年の記事はこちら
今年のエンジニアとしての振り返り2020٩( ᐛ )و - 宮水の日記

英語

今年は長年逃げ続けてきたReadingパートに力を注ぎ、毎日1日10分だけスタディサプリEnglishをやりました。Part7の問題は、公式ドキュメントやGitHubのISSUEを読むときにとても役立っています。

読書

本業では、マイクロサービスやGraphQLといった(私にとって)新しい技術を使ったプロジェクトに参画させていただきました。

kubernetesの設定ファイルを変えたり、SLOを設定するタスクをやるにあたって、インフラ関連の勉強をしました。

産休の勉強時間の使い方をつよつよエンジニアさんに相談したところ、「エンジニアとしての基礎的な部分を改めて勉強してみたらどうか」とアドバイスをいただき、そうすることにしました。勉強したい基礎的な話をリストアップして、まずはOSづくりやDBMSの本から読み始めました。

Webサイトを製作する機会があったので、デザインやWordPressも少しキャッチアップしました。WorPressの本はブログ記事にはしませんでしたが、1週間くらいでデザインをカスタマイズしたWordPressのサイトを作る方法が学べたので、とてもオススメです。

自己啓発本も読んでいました。つわりがきつかったときに、技術書を読む体力がなかったので、なんとか読書の習慣をやめないためのつなぎになりました。

ゴルフメドレー

ゴルフメドレーは、今までの個人開発と違ってエンジニアである夫と優秀なプロダクトオーナー兼営業のメンバーさんとつくっているので、どんどん軌道にのってきており、とても嬉しいです。私は子育てが忙しく、出産してからはあまり開発に携われていませんが、どんどん新しい機能をリリースしています。

ysk-pro.hatenablog.com

個人では、以下のような開発をしました。

GraphQL化

本業の勉強がてら、ゴルフメドレーにGraphQLを導入しました。正直必要なAPIはそんなに多くないので、このプロダクトに導入してよかったのかわかりません。でも、フロントでずっと放置していたTypeScriptの型が簡単につけられたり、フロント側の修正だけで済む場面が出てきたときは、導入してよかったなと思いました。

詳細ページの改修

無機質なテーブルタグだけで作っていた施設の詳細ページのデザインを改修しました。
note.com

ユーザーのログを収集

「どの機能が一番使われているのか?」をわかりやすくするために、Google Analyticsを使ったイベントログを仕込みました。
今までどのページがPV数が多いかまではわかっていたのですが、細かい「もっとみる」ボタンや、「近くの練習場を見る」などの機能はどのくらい使われているのかわかりませんでした。導入したことで、意外な機能がたくさんクリックされていたりすることがわかったりしてよかったです。
note.com

NewRelicの導入

リリースした地図検索機能が重かったので、NewRelicを導入して計測し、原因を調査して改善しました。典型的なN+1を発生させちゃってて恥ずかしかったです。
note.com
note.com

パフォーマンス改善

note.com

ほかつーる

産休中は比較的時間があったので、ほかつーるという保育園検索サイトを作りました。(ゴルフメドレーの地図検索を応用して作りました。)
note.com

このほかつーるは、夫婦で作りました。夫が保育園のデータ取り込みの部分を担当し、私が環境構築やフロントを担当しました。初めて自分でDockerを使った環境構築をやってみたり、ちょっとだけ新しいことに挑戦できました。ママさん界隈ではたくさんリツイートしていただけて、本当に作ってよかったです。

hokatool.com

今年のまとめ

今年はエンジニア5年目の年でした。本業がとても恵まれている環境で、今までやったことがないタスクも先輩方にサポートしていただきながら挑戦することができました。

妊娠・出産の影響で、身体的にかなりきつい時期もありましたが、開発や勉強の習慣をやめなかったことに関しては自分を褒めてあげたいです。子供が生まれてからは、勉強時間どころか睡眠も満足に取れていない毎日ですが、1日1分でもいいからコツコツ勉強することの大切さがわかりました。

来年の抱負

英語

精読を頑張りたいです。
あと、コロナが落ち着いて抽選じゃなくなったらTOEICを受験したいです。

読書

新しいことを勉強するのもいいですが、来年は引き続きエンジニアの基礎となるような本を読んでいきたいです。DBMSの本でも、かつてはわからなかった部分が読めるようになっていてとても面白かったので。「コードの書き方」とか「達人プログラマー」とかそんな類のもの。

ゴルフメドレー

個人開発では後回しにされがちな開発環境の整備など、裏方の仕事がとても楽しいと感じたので、来年もそのポジションで頑張りたいです。

ほかつーる

赤字を解消したい!\(^o^)/


来年はきっと、子育てと仕事、勉強時間の配分で悩むことでしょう。寝不足で子育てが辛いと感じたり、仕事で周りの人に迷惑をかけてしまって、悲しい思いをするかもしれません。そんな中でも、周りの人への感謝の気持ちを忘れずに、たまには息抜きもちゃんとして、全部楽しむことを目標にしたいと思います🤘

「プロダクトマネジメントのすべて」を読みました

プロダクトマネジメントのすべて」を読みました。

なぜ読んだのか

  • プロダクトマネージャー(以下PM)さんが何をしているのかちゃんと理解したいから。
  • 個人開発でどんな機能を追加した方がいいのか考えるきっかけにしたいから。

対象読者

  • PMを目指す人
  • 新米PM
  • PMとして働いている人
  • プロダクトマネジメントに関わるエンジニア、デザイナー、マーケター、事業推進者

この本で学べること

本の概要

Chapter1 プロダクトの成功とは
  • プロダクトの成功を定義するのは、ビジョン、ユーザー価値、事業収益の3つ。
  • PMFとは、強力な価値仮説を見つけること。価値仮説とは、なぜユーザーや顧客があなたのプロダクトを使うのか説明しうる重要な仮説のこと。
Chapter2 プロダクトマネージャーの役割
  • プロダクトを育てること、ステークホルダーをまとめプロダクトチームを率いることの2種類の役割がある。
  • PMはプロダクトを成功させることに責任を持つ。プロダクトに関係する意思決定を実施し、プロダクトチームを率いる。(よく対比されるプロジェクトマネージャーはプロジェクトの品質、費用、納期に責任を持つ。そもそも概念が違うので、比較するものではない。)
Chapter3 プロダクトマネージャーの仕事とスキルの全体像
  • Core, Why, What, Howの4階層から、プロダクト全体に一気通貫した強い軸をつくる。
  • PMに必要なスキルは、発想力、計画力、実行力、仮説検証力、リスク管理力、チーム構築力の6つ。
Chapter4 プロダクトの4階層
  • プロダクトのCore: ミッションとビジョン、事業戦略
  • プロダクトのWhy: 「誰」を「どんな状態にしたいか」、なぜ自社がするのか
  • プロダクトのWhat: ユーザー体験、ビジネスモデル、ロードマップ
  • プロダクトのHow: ユーザーインターフェース、設計と実装、Go to Merketなど
  • プロダクトの方針のフレームワークには、「リーンキャンバス」スケジュールとゴールを作成する「マイルストーン」がある。
  • プロダクトをつくるには、仮説検証が重要。実用最小限の単位でプロダクトを作り価値検証を促したり、チームでアイデアを出し合ったりするのが良い。
Chapter5 プロダクトのCore
  • プロダクトの世界観(ミッション、ビジョン)と企業への貢献(事業戦略)の2つのことを考える。
  • プロダクトの世界観とは、「プロダクトを提供することでどのような未来を作りたいのか」
  • 事業戦略は、「プロダクトが戦うドメインとそのドメインでの勝ち筋を描くこと」
Chapter6 プロダクトのWhy
  • 「誰」を「どんな状態にしたいか」と「なぜ自社がするのか」を考える。
  • 以下のようなフレームワークを使う。

- バリュー・プロポジションキャンバス ... プロダクトとサービスを説明する「バリューマップ」とユーザーについて説明する「カスタマープロフィール」を書く
- PEST分析 ... 「Plotics: 政治」「Economy: 経済」「Society: 社会」「Technology: 技術」の4つの視点で外部環境を分析するフレームワーク
- SWOT分析 ... 自社の強みと弱みを可視化するためのフレームワーク
- STP分析 ... 自社のポジショニングを確立し、ターゲットを絞り込みたいときに使う。
- ユーザーインタビュー

Chapter7 プロダクトのWhat
  • 何をつくり、どのような優先度で取り組むのかを検討する。
  • ユーザー体験 ... UIに当たるのは、カップやBGMなどのユーザーが触れるもの。ユーザー体験(UX)とは、「土曜日の午後におしゃれなカフェで素敵な音楽を聴きながらゆっくりカフェラテを飲む体験」のこと。ユーザーを理解するために、ペルソナやメンタルモデルダイアグラムを作る。
  • ビジネスモデル ... プロダクトがビジネスとして成立するかどうかは、ビジネスモデルキャンバスを用いて考える。また、ユーザーインタビューも有効である。
  • ロードマップ ... プロダクトを開始してから向かうべき経過地点をあらかじめいくつか設定しておき、明確なゴールの場所が定まらなくても着実にゴールに近づいていくための行程表。KPIなどの指標を定め、達成できているか定期的に確認する。
  • Whatが定まったら、一つ上の階層であるWhyの部分とずれていないか確認する。プロダクトのWhat検討後に気をつけるべきポイントも考慮する。
Chapter8 プロダクトのHow
  • プロダクトのCoreからWhatで見てきた内容について「どのように実現するのか」を検討する。
  • プロダクトバックログ(プロダクトに求められている機能や仕組みのリスト)を作る
  • 利用規約や適切な価格を設定する
  • 障害に備える
  • リリースが終わったら、振り返りをする
Chapter9 プロダクトマネージャーを取り巻くチーム
  • PMは一般的に、プロダクトチームと機能型組織(プロダクトマネジメント部)の2つのチームに所属する。
  • PMの仕事で重要なのは、ステークホルダーとの関係性
  • RACI ... チームメンバーの責任分担を明確にする手法
Chapter 10 チームとステークホルダーを率いる
  • コミュニケーションを深める方法について。

- プロダクトの全体像 / スケジュール / 優先度 / 進捗を可視化する
- 心理的安全性大事
- インセプションデッキを使用する
- ふりかえり大事

Chapter 11 チームでプロダクトを作るためのテクニック
  • チームでプロダクトをつくる際に有効な5つのテクニック

- ドキュメンテーション
- 共有や公開、レビューがしやすい適切なツールを選定する。
- コーチン
- チームメンバーの目標到達のための支援をすること
- ファシリテーション
- 集団活動の進行。参加者の役割を決めたり、事前準備、議論の活発化などを促す。
- プレゼンテーション
- 情報量は必要最小限に、伝えたいことが伝えられるように訓練する。
- ネゴシエーション
- 多様なステークホルダーをマネジメントするために必要になるのが交渉力。交渉相手の関係性の度合いと継続性を加味して交渉する。

Chapter 12 プロダクトステージによるふるまい方の違い

プロダクトの置かれた状況別にPMgaどのように振る舞うのかについて

  • プロダクトライフサイクルについて
  • カスタマーアダプションについて
  • 0→1、1→10、10→100のライフサイクルについて
  • プロダクトに見切りをつけたときに気をつけること
Chapter 13 ビジネス形態によるふるまい方の違い
  • BtoCのPMに求められるのは、「機敏さ」。ユーザーの反応を素早く集め、ユーザーのプロダクト体験を常にアップデートし、いかにして継続して使ってもらうかが勝負。
  • BtoBのPMに求められるのは、業界特有の商習慣に対する深い関心、ユーザーとユーザーを取り巻くステークホルダーに対する想像力、優先度のつけ方のバランス。
Chapter14 未知のビジネスドメインに挑む
  • ビジネスドメイン知識を学ぶ。ドメイン知識を獲得するために現場に入り込む必要がある。
  • 未知のビジネスドメインを学ぶには、「プロダクトランドスケープ」「モチベーション分析」「対立スコープ」「トレードオフの発見」などがある。ビジネスドメインを学んだら、その知識をプロダクトチームで理解すると良い。
Chapter15 技術要素の違いによるふるまい方の違い
  • ハードウェア、AI、ソフトウェアなどの技術要素の違いによって、PMが求められるふるまい方が異なる。
Chapter 16 プロダクトマネージャーと組織の成長
  • プロダクトマネジメントが根付いていない組織に所属する場合、まずは共通の課題認識を持つところから始める。
  • ジョブディスクリプションを作成し、各従業員の責務を明確にする。
Chapter 17 プロダクトマネージャーのスキルの伸ばし方
  • PMになるために、ビジネス、UX、テクノロジーのどれかについて自分が自信がもてる領域を作る。
  • W型モデルで自分のスキルをマッピングし、自分の持ち合わせていないスキルや十分に足りていないスキルを可視化して、今後どのように成長していくか検討する。
Chapter 18 プロダクトマネージャーのキャリア
  • PMは担当範囲や担当プロダクトの重要性や複雑さによって高いスキルが要求される。
  • PMを務めた後も、キャリアに色々な選択肢がある。
Chapter 19 ビジネスの基礎知識
  • 様々な収益モデルについて
  • パートナーシップについて
  • 知的財産の扱いについて
Chapter 20 UXの基礎知識
  • デザインを学ぶためのマインドセットや、デザイン6原則について。
  • デザイナーに意図を的確に伝えるために、ペルソナの設定をしっかり揃えたり、ワイヤーフレームや画面遷移を表現すると良い。
  • プライバシーポリシーと利用規約について。
Chapter 21 テクノロジーの基礎知識
  • プロダクトの品質を保つ上で、QAの知識、狩野モデルの利用、ソフトウェアテストなどの知識を持っておくと良い。
  • 開発手法の基礎知識としては、DevOps、ウォーターフォール開発とアジャイル開発などの知識を持っておくと良い。
  • ソフトウェアの基礎知識としては、ソフトウェアがプログラミング言語で動いていること、アーキテクチャ、ネットワークの仕組み、データベースの基本、セキュリティなどの知識を持っておくと良い。

感想

とても読み応えのある本でした。私の中でプロダクトマネージャーとプロジェクトマネージャーがごっちゃになっていることがわかりました。
プロダクトマネージャーさんが、どういった役割を持っているのか、普段どういったことを勉強されているのか知ることができてよかったです。
また、本書の知識は個人開発のプロダクトにも色々と応用できそうでした。こうやって別の職種の方の本を読むのもいいですね!

ここまでお読みいただきありがとうございました!

「WEB+DB PRESS Vol. 122『特集3 作って学ぶ RDBMS のしくみ』」を読みました。

WEB +DB PRESS 〜作って学ぶRDBMSのしくみ〜を読みました。

なぜ読んだのか

  • SQLRDBMSの本を読んでいたら、内部の構造が知りたくなったから。

この本で学べること

  • ミニRDBMSを実際に作りながらその内部を知り、RDBMSをもっと活用できるようになる。

本の概要

第1章 RDBMSを作ろう

RDBMSは以下の層で構成されている。本書では、ディスクマネージャー〜クエリプランナまでを作成する。
- 構文解析器 ... クエリの構文解析
- クエリプランナ ... 実行計画の最適化・決定
- クエリエクスキュータ ... 実行計画どおりにアクセスメソッドを呼び出す
- アクセスメソッド ... ディスク上のデータ構造をたどる
- バッファプールマネージャ ... データの塊をメモリにキャッシュする
- ディスクマネージャ ... データの塊をディスクに書く・読む

本書で作るDBは、テーブル作成、行の挿入、行のクエリ、セカンダリインデックスなどの機能を持つ。トランザクションや複数のテーブル、JOINなどは対応しない。

第2章 ディスクマネージャの実装
  • ディスクマネージャは、ファイルの読み書きを担っているコンポーネント
  • Rustでヒープファイルを新しく作ったり、ページを書き込んだり読みだしたりする機能を実装する。
第3章 バッファプールマネージャの実装
  • バッファプールマネージャは、ページの内容をメモリ上にキャッシュすることでディスクの遅さを隠蔽する役割がある。一度読んだページをメモリに保持しておく。
  • どのバッファを捨てるか決めるClock-sweepアルゴリズムは、PostgreSQLでも採用されている。
  • バッファがない場合、バッファがいっぱいになった場合、ページの貸し出しといった処理を実装する。
第4章 B+Treeの観察
  • B+Treeをアクセスメソッドのデータ構造とアルゴリズムとして利用する。
  • B+Treeは挿入、検索、削除などの計算量がいずれもO(log n)でありバランスがよく、範囲検索・列挙が得意。
第5章 テーブルの実装
  • B+Treeにテーブルを格納する
第6章 セカンダリインデックスの実装
  • セカンダリインデックスとは、検索しやすい形に変形されたデータ構造のこと。

感想

ちゃんと実装したわけじゃないのですが、RDBMSが何で構成されているのか、B+Treeのアルゴリズムについて雰囲気だけわかったので面白かったです。

ここまでお読みいただきありがとうございました!

「達人に学ぶDB設計徹底指南書」を読みました

「達人に学ぶDB設計徹底指南書」を読みました。

なぜ読んだのか

基本情報を取ったときに読んだ本で、初心に返りたかった。

対象読者

  • DBエンジニア
  • DB設計を初級者で終わりたくない人

この本で学べること

  • リレーショナルデータベースの論理設計と物理設計について

本の概要

第1章 データベースを制する者は、システムを制す
  • 「データベース」と「DBMS」は異なる。「データベース」はデータの集合を指す論理的概念であるのに対し、「データベース」を管理するためのシステムを「DBMS」という。
第2章 論理設計と物理設計
  • 概念スキーマを定義する設計を論理設計と呼ぶ。論理とは、「物理層の制約にとらわれない」という意味。ER図などを書いて設計する。
  • 物理設計は、論理設計の結果を受けてデータを格納する頼め物理的な領域や格納方法を決める工程。容量、冗長構成、ファイルの物理配置(データベースのファイルをどのディスクに保存するか)などを検討する。
  • バックアップ設計とリストア設計についても触れていた。
第3章 論理設計と正規化 〜なぜテーブルは分割する必要があるのか?〜
  • テーブルとは、共通点を持ったレコードの集合である。
  • 正規化は、データの更新の不都合/不整合を排除するために行う。
  • 第一正規形は「一つのセルの中には一つの値しか含まない」
  • 第二正規形は「部分関数従属を解消する」ことで得られる。

- 部分関数従属とは、主キーの一部の列に対して従属する関係のこと。
- 結合すると、第一正規形のテーブルに戻すことができる。

  • 第三正規形は「推移的関数従属を解消する」ことで得られる。

-推移的関数従属とは、 {社員ID}→{部署コード}→{部署名}のように、テーブル内部に存在する段階的な従属関係のこと。

  • テーブルの正規化は簡単だが、「なぜ正規化しなければならないのか」「正規化のメリット」を説明できる人は少ない。
第4章 ER図 〜複数のテーブルの関係を表現する〜
  • ER図の書き方について
第5章 論理設計とパフォーマンス 〜正規化の欠点と非正規化
  • 正規化とSQLのパフォーマンスはトレードオフの関係にある。
  • 正規化すると、データを集計するときに結合が必要になり、パフォーマンスが落ちる。対処法として、テーブルを非正規形の形に戻したり、冗長なカラム(商品数やいいねの数など)を作る方法がある。
  • どちらも正解はない。ケースバイケースで実装する。
第6章 データベースとパフォーマンス
  • DBMSSQLを受け取ったあとたくさんの経路の中から最短経路を選択し、SQL手続きに変換する。経路はDBMSがお任せで決めてくれる。
  • B-treeインデックスはバランスの良いインデックス。計算量はO(log n)となり、データが増えても検索や更新にかかる時間はほとんど増えない。
第7章 論理設計のバッドノウハウ
  • 配列型は利用しない。あとから結合されたものを分割するのは難しい。
  • テーブルにポリモルフィズムはいらない。
  • レコード単位で分割する「水平分割」をするとどんどんテーブルが増えてしまうので×
  • 列単位でテーブルを分割する「垂直分割」は、定期的にデータの同期が必要になるデメリットがある。
第8章 論理設計のグレーノウハウ
  • 主キーがないテーブルに主キーを作る方法
  • 行持ち、列持ちテーブル
  • データクレンジングについて
第9章 一歩進んだ論理設計 〜SQL木構造を扱う〜
  • SQL木構造を扱うのが苦手。方法としては以下のようなモデルがある。

- 隣接リストモデル
- 入れ子集合モデル
- 入れ子区間モデル
- 経路列挙モデル

感想

今までもDB設計は業務でやったことがあり、本書を読んでいて、「普通に」考えたらそうなるでしょ、「普通に」考えたらそんな設計にはならないのでは?と思う箇所がたくさんありました。しかしながら、この「普通」について、なぜ必要なのか、なぜいけないのかちゃんと考えたことはありませんでした。DB設計の基本を丁寧に説明されている本だと思いました!
三年くらい前に一度目を通した本でしたが、あたらめて読んでみると新しい発見がありました。読んで良かったです。

ここまでお読みいただきありがとうございました!

「達人に学ぶSQL徹底指南書」 を読みました

達人に学ぶSQL徹底指南書 を読みました。

対象読者

  • 実務でのSQLプログラミングの経験が半年から1年くらいある方
  • レベルによらず、「SQLとは何なのか」知りたいと思っている方々

この本で学べること

  • CASE式、ウィンドウ関数、外部結合、相関サブクエリ、HAVING句、EXISTS述語などのSQLの道具を取り上げて、それらの便利な使い方をサンプルケースを通じて学んでいく。
  • SQLの原理となっている仕組みや、この言語を作った人々が何を考えて現在の形にしたのかというバックグラウンドを学ぶ。

本の概要

1. CASE式のススメ
  • CASE式を使えば、異なる条件の集計を1つのSQLで行える。例えば、県名と人口のテーブルを、「四国」「九州」などで括って集計できる。条件の異なるUPDATEを一度にかけられる。CASE式の中で集約関数(SUM、MAX、COUNTなど)を使うことができ、複数のSQL文を一つにまとめられ、可読性もパフォーマンスも向上する。
  • CASE"文"ではなく、CASE"式"であるがゆえに、実行時には評価されて一つの値に定まる。「1+1」や「a + b」などと一緒。式だから、SELECT句にもGROUP BY句にもWHERE句にもORDER BY句にも書くことができる。(※ 式と文の違いを調べてみたら、例えば「a = 1 + 2」が文で、「1+2」が式っぽいです。)
2. 必ずわかるウィンドウ関数
  • ウィンドウとは「範囲」という意味。ざっくりいうとウィンドウ関数は手続き型でいうfor文やwhile文に似ている。

1. PARTITION BY句によって、レコードの集合のカット(カットとは、母集合のレコードから操作したいレコードを集めて部分集合を作ること)
2. ORDER BY句でレコードを順序付け
3. フレーム句で、カレントレコードを中心に処理を行っていく
f:id:kattyan53:20211010224226p:plain

3. 自己結合の使い方

自己結合を使うと、

  • 重複順列・順列・組み合わせ
  • 重複行の削除
  • 部分的に不一致なキーの検索(同じ家族レコードだけど、住所が違う)

などをしたいときに応用が効く。

4. 3値論理とNULL
  • NULLには「未知」と「適用不能」の2種類がある。NULLは値でも変数でもない。
5. EXISTS述語の使い方
  • SQLに置ける述語とは、戻り値が真理値(true, false, SQLの世界ではunknownも)になる関数のこと。
  • EXISTS / NOT EXISTSを応用すれば、テーブルに存在しないデータを検索できる。
6. HAVING句の力
  • HAVING句はCASE式や自己結合といった他の武器と組み合わせると真価を発揮する
  • 探したいデータがあるときは、線と資格ではなく円(ベン図)を書く
  • 歯抜けのデータを探せる
  • 最頻値を探せる
  • NULLを含まないデータを抽出できる
7. ウィンドウ関数で行間比較を行う
  • 行間の比較は、昔は相関サブクエリを使っていたが、今はパフォーマンスや可読性の観点からウィンドウ関数が使われている。
  • 以下のようなテーブルで、前年より売上が上がったのか、下がったのか、変わらなかったのかみたいなデータを抽出できる。

f:id:kattyan53:20211011223912p:plain

8. 外部結合の使い方
  • 本来、SQLは検索のためのクエリであって、表の再形成には向いてない。
  • この章では、外部結合やCASE式を駆使していろんなテーブルの整形を行う。
9. SQLで集合演算
  • 和(UNION), 交差(INTERSECT), 差(EXCEPT)は最近標準に入った。
  • 除算(DIVIDE BY)はまだ実装されていないので、自前で作る必要がある。
  • 和(UNION)を応用して、2つのテーブルが等しいか否か調べたりできる。
10. SQLで数列を扱う
  • SQLで数列や順序集合を扱う方法について
11. SQLを速くするぞ

SQLを早くするテクニックについて学びます。

  • 暗黙裡にソートが使われる関数を使わないようにする
  • GROUPBY句とORDERBY句でインデックスを使う
  • 中間テーブルをなくし、HAVING句を活用する
  • 早い段階でレコード数が絞れるなら絞る
12. SQLプログラミング作法

全ての言語に共通するような話

  • わかりやすいカラム名をつける、インデント、スペース、大文字と小文字、カンマの位置

SQL独特の作法

  • SQLの世界はコメント推奨
  • PostgreSQLOracleMySQLなど方言が強いので、いつか移行するかもしれないことを視野に入れて標準語で書くようにする。
13. RDB 近現代史
  • RDBは従来の階層型DBを置き換えた破壊的イノベーション。エンジニアが扱うものとされていたデータベースをエンドユーザーが扱えるものにしようとした。
  • RDBは、非循環グラフ(例えば、組織図)やネットワーク構造(例えば、SNS)を表すのが苦手。
  • 近年NoSQLの製品群が登場しているが、RDBの補完的関係として共存する可能性が高い。
14. なぜ"関係"モデルという名前なのか?(なぜ表モデルではないのか)

簡単にいうと、関係モデルは数学の集合論を基礎に作られたので、使われる用語も集合論の用語を流用している。関係と表は、以下のような違いがある。

  • 関係には重複する組みは存在してはならないが、表には存在しても良い。
  • 関係の組は上から下へ順序付けられていないが、表の行は上から下へ順序付けられている。
  • 関係の属性は左から右へ順序付けられていないが、表の列は左から右へ順序付けられている。
  • 関係のすべての属性値は分割不可能だが、表の列の値は分割可能である。
15. 関係に始まり関係に終わる
  • SQLが持っている面白い性質の一つ、「閉包性」について。
  • 演算時の入力と出力が共に関係になる、関係の世界が閉じていることを保証する性質のこと。
  • 関係が閉包性を満たすおかげで、これらの演算の出力を、別の演算の入力にすることが可能になる。
16. アドレス、この巨大な怪物
  • SQLでは、ポインタが隠蔽されている。そうすることで、人間が認識しやすい有意味な世界を作り上げようとした。
17. 順序をめぐる冒険
  • ウィンドウ関数の登場は、なぜこんなに遅かったのか。
  • SQLには、「行は順序を持つべきではない」という思想があったから。
18. GROUP BY とPARTITION BY
  • どちらもほぼ似たような動きをする
  • PARTITION BYは数学でいう「類」の概念に由来して付けられた
  • GROUP BYは個々の要素を集合に振り分ける機能を持つ
19. 手続き型から宣言型・集合指向へ頭を切り替える7箇条

① if文やcase文はcase式で置き換える。
② ループはGROUP BY 句とウィンドウ関数で置き換える
③ テーブルの行に順序はない
④ テーブルを集合とみなそう
⑤ EXISTS述語と「量化」の概念を理解しよう
⑥ HAVING句の真価を学ぶ
⑦ 四角では無く、円を描く

20. 神のいない論理
  • 3値論理の歴史について
21. SQL再帰集合
  • 集合の中に集合を含むような入れ子の集合を再帰集合という。
  • よくわからなかった。
22. NULL撲滅委員会
  • NULLでは無く、コードを割り当てる(0:未知, 9:適応不能など)
  • 数値の場合は0で代替する
  • 日付の場合、最大値・最小値で代替する
23. SQLにおける存在の階層
  • SQLでは、集約すると元のテーブルの列名をそのまま参照できなくなる。
  • 例えばage列はメンバー一人一人の年齢の情報を保持しているが、年齢というのが一個人にまつわる属性であって、チーム全体の属性ではないから。1人の人間について「年齢は?」とたずねることはできても、複数の人間の集まった集団に対して「年齢は?」とたずねることはできない。

感想

率直にいうと、DBエンジニア向けの本だったので結構難しかったです。説明はありますが、たくさん数学用語が出てきたり、ソフトウェアエンジニアがあまり使わないようなデータの取得のケースを取り扱っていたからです。難しい箇所に関しては、「こういうSQLを使ったら、こういうテーブルからこんなデータを抽出できたり、こんなテーブルの再成形ができるんだな」くらいの感想で読んじゃいました。

しかしながら、今まで抱いていたSQLへのイメージがかなり変わりました。特に「テーブルには順序がない」「ループがない」「ポインタが隠蔽されている」など、言われてみないと気づかないような、今まで意識したことがない事柄を学ぶことができました。

また、SQLの歴史も初めて知りました。データの持ち方にもいろんな種類があって、それぞれに利点や欠点があるので、RDBMSだけでなくそのサービスにあったものを検討してみるのもいいと思いました。

一見簡単な構文しか持っていないように見えて、実は奥が深いですね!

ここまでお読みいただきありがとうございました!