正規化について考える kintone
kintoneの学びが多いアールスリーインスティテュートさんのyouTube動画。
前回
に引き続き、R3さんの動画を参考にしながら私が言いたいことを乗っけていこうと思います。😅
なぜ正規化を学ぶのか
正規化とは、リレーショナルデータベースという、kintoneとは違う形のデータベースでの話です。ので、kintoneに正規化の知識が必須かというとそうではありません。ではなぜ正規化を学ぶのか。またなぜkintone界隈をうろうろしてると「正規化」なるものがときどき話題になるのか、それはこういうことだそうです。
リレーショナルデータベースの方法論というのは歴史が長く実績も豊富にある。そのため設計手法が確立されておりかなり洗練されている。さらに正規化に関する書籍や情報が充実しているので学習しやすい。
なるほど。つまり正規化は、kintoneでデータベース設計をする場合の考え方のベースに使うのに便利だからですね！
でも正規化に関する本が多いと言ってもどれも難しそうだし。。。
で、わたしのオススメの本を紹介します。じゃん
マンガでわかるデータベース
マンガです😆。しかし侮るなかれ。著者は高橋麻奈先生です。
たくさんのIT関連書籍を執筆されてますので、IT関連の書籍コーナーで一度は目にしたことがあるのではないでしょうか。「やさしいJava」とか「やさしいC」とか「やさしい○○」シリーズのIT本は、高橋先生の著書の可能性が高いです。作画のあづま笙子先生の絵がらもやさしい感じでいいですね。
出版社のオーム社さんは電気電子分野では草分け的存在で教科書なども出版されている（個人的なイメージとしてはマンガとは対極のお堅いかんじ😅）の出版社さんです。技術的な書籍として安心できますね。ネットワーク業界の定番「マスタリングTCP/IP」もオーム社さんです。
「正規化の本っていってもどれがいいかわからないよ！！」という方おられましたら参考にしてください。
正規化
さて、テーマは正規化。R3さんの動画では
「同じ意味のデータは１か所だけに記録されるようにする。同じものを複数の場所、複数のテーブルに書かない。ダブリのないようにすること。
と延べられています。
ほかにも正規化については「一事実一箇所」(1 fact in 1 place)という言い方をされたりもします。それで、もっと「正規化」についてググってみるとでてくるのが以下キーワードです。
・非正規形
・第一正規形
・第二正規形
・第三正規形
ココ、正規化についてはこの辺がハマリポイントだと思うので、私なりに理解していることを乗っかってまとめようと思います。一応合ってると思って書いてますが、ちがってたら誰か教えてください。(予防線😅)
サンプルkintoneアプリもつくってみました。こんな感じ。このアプリに入ってそうなデータで説明します。「正規化勉強用なんちゃって注文アプリ」です。
・非正規形
非正規形とは、繰り返しの項目がのこっている状態のことです。ようするにこんな感じ。
いわゆるExcelの伝票形式や、セル結合(特に列のセル結合)されたアレです。イヤー。セル結合イヤイヤイヤイヤ、ダメ。ゼッタイ。(ｼﾞﾀﾊﾞﾀｼﾞﾀﾊﾞﾀ…)
この形式だと、そもそもリレーショナルデータベースに取り込むことができません。
・第一正規形
じゃ、第一正規形とは？？
つまり最低限リレーショナルデータベースに取り込める形といえますね。具体的にはこんなかんじ。
一旦一行ずつにした形式。Excelではデータベース形式って言ったりもしますね。シンプルな１行１レコードにしたExcelデータと思ってもらえればまあそう。これが「繰り返しの項目を持たない」という第一正規形といわれるものです。
・第二正規形
ではでは、第二正規形とは？
誤解を恐れずざっくりいうと、ちゃんとマスター化することなのですが。😅マスター化といえばなんちゃらコードなどを付ける事。なんちゃらコードはキーともいいます。
リレーショナルデータベースでは、とあるデータを一言で識別できる特別な項目を主キーといいます。ということで、主キーが決まると他の列の値が決まるように表を分けてみようと思います。
ご紹介した「マンガでわかるデータベース」を参考に、わたしも注文と注文明細にわけてみました。
注文番号に紐づくデータと、注文番号と商品コードに紐づくデータでわけています（今回は同じ注文番号で同じ商品コードのダブリはない前提）。
注文は注文番号で日付やお客様コードなど注文のヘッダー部分（明細ではない部分）が決まります。注文明細は注文番号＋商品コードで、商品名と金額など注文明細の内容が決まります。これがいわゆる主キーです。
ただ、この状態だと例えば、まだ注文がない商品「キウイ」は登録することができません。また「りんご」を「林檎」と変更したいなと思ったらすべての注文明細について変更しないといけないですよね。ちょっとたいへん。
そこで、注文明細をさらに商品マスターに分割してみました。
こうすることによってまだ注文がない商品「キウイ」とかも商品マスターに登録ができるようになりました。また「りんご」を「林檎」と商品名を変えたいときにすべての注文明細を変更しなくても商品マスターの１か所だけ変更したら大丈夫になります！
これらの作業を難しい言葉でいうと「関数従属するように表を分割する」といいます。
もっというと、これマンガでは具体的な単語としてはでてこないのですが、「部分関数従属性をなくす」といいます。いわゆるこれが第二正規形のゴールとなります。
部分関数従属性について以下リンクを紹介します。ITmediaさんありがとうございます。
・第三正規形
じゃあ、第三正規形って？
注文にある、お客様コードとお客様氏名の関係はちょっと変わってて、注文の注文番号に紐づいてお客様コードが決まり、お客様コードが決まったらお客様氏名が決まるという関係があります。私は、決まって決まる関係と覚えています。
では、注文からお客様マスターを別にしてみましょう。
これが第三正規化。こうすることで、まだ注文ゼロのお客様も登録することができます。
これも難しい言葉でいうと「推移従属を除くように表を分割する」といいます。推移的関数従属性についても詳しい内容としてはコチラが参考になります。第二正規化と言い方をあわせると第三正規化は「推移的関数従属性をなくす」となります。
第二正規形のポイントである部分関数従属が主キーに含まれる項目の関数従属であるのに対して、第三正規形の推移的関数従属は、主キーに含まれない項目の関数従属であるところがポイントです。
以上が、わたしが思ってる正規化の考え方です。ちがってたら誰か教えてください。(再び予防線😅)
まあ厳密にはどっかちょっと違うかもですが、私の体験としては大体なんとなくこれくらいの理解で今まで実用上は困らなかったですし、これだけわかってれば「正規化？ワカラン？？」とはならないので、kintoneの話をするときにそういう話題が出てきても焦らず、なんなら必要に応じてドヤ顔で説明してください。
正規化をくずす
で、改めてR3さんの動画に戻りまして、kintoneではどうするのか？ということです。kintoneではそれらをわかったうえでこうするそうです。正規化をくずす！
正規化された形を常に側に置き、それを崩すことでkintoneに適した形に変形していることを意識して設計する。
冒頭でも述べましたが、そもそもkintoneはデータベースなのだけど正規化ルールに基づいたリレーショナルデータベースとはちがいます。
例えば、ルックアップフィールドは仕様上複数アプリに同じフィールドデータがあちこちに生まれますし、kintoneのテーブルフィールドを使うことで非正規形のような感じになってしまいます。そして、そもそもkintoneアプリはリレーショナルデータベースでいうところのテーブルではありません。
ですので正規化を崩していく必要があるのですね。kintoneでは正規化の概念をわかったうえで、あまり正規化にこだわりすぎない事が大事です。まさにこの辺はR3さんの動画に詳しい解説がありますのでぜひみてください！
そして私は自分の言いたいことだけ書いて唐突におわります。🤣🙏
この記事が気に入ったらサポートをしてみませんか？