〜DBガチ勢ちゃうやつは全員集合〜
こんにちは！
情シスに関する仕事をしてるものです⭐️
- DB専任ちゃう
- スプレッドシートや台帳は山ほど触る
- デバイス管理、表製作とかやってるやつ
そんな情シス、多いんちゃうかなと思ってます。
この記事は
「情シス同士で、これ分かっといたら楽になるよな」
っていう気持ちで書いてます。
1. データ不整合って何なん？
一言で言うと、
同じはずの情報が、見る場所によって違う状態
これが データ不整合 や。
情シスあるあるで言うと
- 端末台帳では「Mac」
- 別シートでは「MacBook」
- GWSの端末名は「MB-001」
「いや、どれが正解やねん」ってなるやつ。
これ、大体原因は同じ。
原因は「同じ情報を何回も書いてる」こと
データ管理で一番大事な考え方はこれ。
1つの事実は、1か所だけに書く
これを 「1か所1事実」 って呼ぶ。
でも現場では、
- ユーザー台帳
- デバイス台帳
- アカウント管理表
全部に 部署名・社員名 書いてたりする。
ほんで、
- 部署名変更
→ 1枚だけ修正
→ 他は放置
はい、データ不整合完成⤵️
2. データ不整合は「いつ」起きるん？
これは 更新時異常（Update Anomaly） って言うねんけど、
情シス的にはこの3つ覚えたらOK。
① 更新したとき（修正）
同じ情報が複数ある状態で、
一部だけ直して他を忘れる。
→ 一番多い事故。
② 追加したとき（登録）
主キーの設計が微妙で、
- まだ決まってない情報が必須
→ 登録できへん
→ 仮データ入れる
→ 後で地獄。
③ 削除したとき
ある情報を消したら、
- 付随して
- 消したらあかん情報まで
一緒に消えるやつ。
「いや人は残してええやろ」案件。
3. どこ見たら「ヤバそう」って分かるん？
情シス目線で見るなら、ここだけ見たらええ。
① 同じ文字が縦にズラっと並んでる
- 営業部
- マーケ部
- 情シス
何回も出てきてたら、
そこは将来ズレる。
② 「それ、この表に要る？」って列がある
例：端末を管理する場合
| 端末ID | 利用者 | 部署名 | 部署TEL |
|---|
部署名とTEL、
端末の情報ちゃうよな？
（いらない情報は別テーブルで管理じゃない？)
③ 主キーの一部だけで決まる情報がある
- 主キー：社員ID＋端末ID
- でも社員名は社員IDだけで決まる
→ 同じ名前が何回も出る
→ 修正漏れ不可避。
4. どう直すん？（正規化の考え方）
「正規化」って聞くと難しそうやけど、情シスなりに簡単にまとめたものが前回の記事であるから見てみて！
https://qiita.com/taisuke_kuramoto/items/33166b150d516f81d233
ステップ①：1セル1情報にする
❌ Mac, iPhone
⭕ Mac / iPhone
ステップ②：それ専用の表を作る
端末管理表に
- 端末名
- スペック
入ってたら、
👉 端末マスタ 作る。
ステップ③：名前・名称系は別管理
社員表に
- 部署ID
- 部署名
両方あったら、
👉 部署マスタ に切り出す。
5. 正規化しすぎてもええわけとちゃうって知ってた？
例えばなんやけど、技術的観点から見ると下記のことがあり得る！
- JOIN増える
- シート見づらい
- 現場が嫌がる
だから情シス的には、
壊れやすいとこだけ正規化
でええと思ってる。
- 部署名
- 社員情報
- 権限系
ここだけ「1か所管理」するだけで、
事故はだいぶ減る。
まとめ（情シスとして一番言いたいこと）
- データ不整合は「人のミス」じゃなくて 構造の問題ってこと
- 同じ情報を何回も書いてたら、いつか必ずズレるってこと
- 正規化はDB専任の技術やなく、情シスが会社守るための考え方でも必要ってこと
おわりに
情シスって、
- GWS
- デバイス管理
- アカウント
- 台帳
- スプレッドシート
「半DB」みたいなもんを毎日触ってる。
やからこそ、
データの持ち方 だけ分かっとくと、
仕事めっちゃ楽になるで。
情シス同士、ぼちぼち頑張ろ！