[2021年10月号] Software Design(技術評論社) サマリー+個人メモ

Software Design の2021年10月号について、

ざっくり内容紹介
個人的に気になった記事やポイント

をまとめている記事です。

サマリー記事の一覧はこちら。

特集①：データモデリングチェックリスト 48
特集②：挫折しない OAuth/OpenID Connect 入門
Column
Development
OS/Network
そのほか
Software Design 2021年10月号

特集①：データモデリングチェックリスト 48

データモデリングとは
- モノやコトの共通する性質に着目し、ある一定のルールにもとづいてそれらを整理すること
  - このお決まりの文だけ読んだらオブジェクト指向の解説とおんなじだよね、まあ当然と言えば当然だけども
- データは持っているだけでは価値にならない、正確かつ最新化されたデータを必要なときにすぐ取り出せる状態になっていてこそ意味がある
  - わかるが、難しい問題。使われていないけど潤沢なデータを持っている企業に着目されてビジネスとして投資されることもあるし（＝そこにDX価値がある）、データ単体に価値がないというのは言いすぎな所感。流れ上の表現で特に意図はないと思うけど。
- モデリングの段階
  - 概念データモデリング
    - ビジネス観点、企画レベル
  - 論理データモデリング
    - いわゆるいつもの正規化とかの段階のところ
  - 物理データモデリング
    - DBに実装してみたらイマイチだったというよくある展開以降の段階、チューニング的なものと理解した
      - ここには非機能要件が多分に含まれそうなことに留意する
- ERモデル
  - Entity Relationshipの考え方
    - エンティティ
      - データ本体のこと。顧客、商品などのモノはもちろん納品などコトも含む
    - アトリビュート
      - 属性。エンティティに対する性質や特徴、つまりレコードのキー対象に対する説明になるものと考えるとよさそう（この段階でレコードとかキーとか言うのはよくないのかもだけど）
        
        PK、FK　非キー
    - リレーションシップ
      - エンティティ間の決まりごと。「制約」と覚えたい。
    - カーディナリティ
      - 多重度。
    - オプショナリティ
      - エンティティ間で対応するデータが常に存在するのか、ないときもあるのか、のこと。早い話NotNull制約のことかしらん？
論理データモデリング
- 正規化
  - 第n正規化～のいつもの話、カット
- 最適化
  - 複数の正規化モデルには同じようなエンティティが存在する可能性がある。これに対し、小さな単位で作成した複数の正規化モデルを「同じエンティティは結合」「リレーションシップの再度見直し」をすることでいい感じにする
    - 正直なんのことかよく分からんかったので図など読んではみたものの、一般化して自分ごとに落とし込めないのであまり腑に落ちなかった感。こういうのって実務でここまで綺麗になっているものを触れる機会がレアすぎて全然普遍的に考えられるようにならないよね…
ビジネスルール検証
- リレーションシップがビジネスルールと矛盾していないか
  - 多少意味が違うかもしれないが正直これはよくある気がする。アプリケーションとデータベース的に問題なく作ったとしても「そんなん俺たちできるようにしてって言ってないんだけど」みたいなやつよね。~~ダルい~~
  - 1つのエンティティに異なる意味合いの管理対象が含まれていないか
    - これを調べるための簡易的な策は「分類」「区分」「タイプ」などのアトリビュートがあるか見てみる、とのこと。なるほど。
  - プライマリーキーの安定性
    - 下記のようなPKは注意が必要
      - JANコードや行政などが発行するコードなど、コード体系の変更ができないもの
      - 有意コード（データ値に意味があるもの）
      - 複数のアトリビュートから構成されるもの
物理データモデリング
- まずCRUD図でエンティティとプロセスの関係を図式化する
  - 何度か仕事でも書いたことあるが、クソの役にも立たずどこかへ消えていった記憶。今思うとプロセス側の設計がダメだったからCRUD図として価値が出なかったのかなー。
- 更新（U）と削除（D）が多いエンティティは注意する
- テーブル設計
  - テーブルネームやカラム名に関して、論理データモデリングからの変換辞書を用意するのがいいとのこと
  - 論理データ属性
    - 文字列
    - 数値
    - 日付
      - 日付型
      - 文字列型
      - 数値型
  - カラム名は母音を省略するのが一般的（PRDCT_NM, CSMTR_NM）
- 制約設計
  - さっきのビジネス関連違反に近くて、例えば「ある製品が製造中止になったのにDB上では残ってしまっていて、生産計画立案時のリストに出てくる」などのこと
  - 手順は３つ
    - カラムのデータ仕様の確認
    - データ制約の適用検討
    - データ制約の定義
  - データ制約、大きく６つ
    - ドメイン制約
      - データ値が正しい範囲にあるか。列挙でも可。
    - 一意性制約
      - ユニーク制約、複数定義OK。NULLもいい。
        
        １つのテーブルに１つだけで、NULLもダメなのがPK制約。
    - NOT NULL制約
    - 関連制約
      - 同一テーブル内の複数のカラム間における関連を保証する。
    - 導出制約
      - getterみたいなやつ。
    - 参照制約
      - 外部キー制約。

特集②：挫折しない OAuth/OpenID Connect 入門

ちょうど少し前に体系的に知識をインプットしたばかりの領域のため記載を省略する

Column

エンジニアも知っておきたい法律知識「ソースコードの引き渡し義務」
- プログラムの著作権者だからといって著作物（ソースコード）の引き渡しを求めることができるわけではない
  - 基本的には「できない」と考えられているらしい。
  - これ「プログラムの」じゃなくて「ソースコードの」だったら話は別なのかね。

Development

Pythonモダン化計画「スナップショットテストの可能性を追求する」
- サーバー側の実装に対してフロントエンド側でも見た目（動作）が変わっていないことを保証したいときがある
  - なるほどたしかに。UX的には当然の考え方だけど気づかなかった、フロントエンドのことだと分離してまっていた。
- ツール
  - Jestというのが有名らしい
    - JSのDOM比較を考慮している
  - レスポンスヘッダやDOMの記録にはPuppeteerというヘッドレスブラウザでサーバーへリクエストする
    - ヘッドレスブラウザ：GUIのないブラウザ（たぶん）
- テストパターンの網羅
  - こんなん絶対やりたくないわ（）
  - 後ろの方で例によってモノタロウの実例があり、テストパターンのリストアップをどうやったか書いてあった
    - 今回対象にしたのは「商品検索APIの結果」だということで、これはクエリの内容がBigQueryの中に全部溜まっていたからなんとかなったそう。
    - なんか思ってたんと違う
      - 例えばログイン状態や会員のステータスごとに全てのページで配置やデザインが…みたいなやつかと。まあケースを絞ったのかな。
- 自動化
  - このテストの背景を考えれば自動化の意義は薄いかもね（そんなようなことが誌面にも書いてあった）

OS/Network

明後日のコンピューティングを知ろう「ラック収容率の乖離」
- 半導体の集積率向上などによって「1つのCPUパッケージの熱密度が400Wを超えることは少ない」と言われていた
  - ところがFPGAに代表されるような「1つへの集約」が近年再度進んできており、これからも熱対策は必要とされていくのでは？（筆者さん談）
- 実際、データセンターの消費電力はかなり上昇傾向にある（グラフあり）、1Uに対する電源ユニットはmax 2,000Wで、実効値も1,300Wほどあるとのこと
  - で、これを19インチラック（42U）に入れまくるとラックあたりの熱密度は54kWを超える
    - 国内最先端のデータセンターでもラックあたりの想定許容値は10kWほどということでオーバーしまくってる
- クラウドサービス全盛期だけど、物理的に「何か」が動いているところは世界のどこかにあるわけで、それらは当然負担がのしかかっているんだよねー。

そのほか

ITエンジニア必須の最新用語解説「Allstar」
- GitHubリポジトリを保護するもの
- GitHub管理下に置いていてもセキュリティ運用を正しく理解していないメンバーがいたり規模が巨大になることで管理が杜撰になっていってしまったりする対策
- 開発はGoogle、OSS
  - OSSのプロジェクトとしては今はOpenSSFという団体管理の模様
- リポジトリに対してインストールし、セキュリティ設定を継続的に監視してくれる