![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2023-06-19T11:26:15+09:00","default:irrp","irrp") #author("2023-07-20T13:21:38+09:00","default:irrp","irrp") →[[データベース関連]] #contents *関係モデル [#a1ac38de] -[[関係モデル>http://www.ss.em-net.ne.jp/~kouyamat/HTML/DB_KnkMdl.htm]] *エンティティとインスタンス [#ia6edc94] -エンティティ：実世界で管理すべき事物 -インスタンス：エンティティの属性に実際に値を持ったもの。実際のレコード -カーディナリティ：多重度。インスタンスの対応関係。１対１とか１対多、とか -オプショナリティ：カーディナリティに０を含むかどうか -連関エンティティ：多対多の関連を正規化するために間に追加するエンティティ -ロール：あるエンティティがあるエンティティに対してどのような役割を持つか（アクセス権限の管理に使うロールとは別物） -強実体：他のエンティティのインスタンスが存在しなくなっても自身のエンティティのインスタンスの存在には影響がないもの -弱実体：他のエンティティのインスタンスが存在しなくなると自身のエンティティのインスタンスの存在がなくなるもの *スキーマの種類 [#ec365249] -外部スキーマ：アプリから見たビューレベルの見た目 --サブスキーマ：外部スキーマの別名 -概念スキーマ：実際のテーブルの定義 -内部スキーマ：マシン上での実装。ISAMとかVSAM -開発の現場でスキーマと言ったら概念スキーマのことを指していることが多い -情報スキーマ：データディクショナリを見るためのビュー -定義スキーマ：情報スキーマの実体となるテーブル *キーの種類 [#aefc059b] -スーパーキー：行を一意に識別するすることができる属性（の組み合わせ） -候補キー:スーパーキーのうち行の識別に最低限必要な属性（の組み合わせ） -主キー：候補キーのうち、もっともよく使うもの（を設計のときに主キーと決める） -複合キー：候補キーのうち複数の属性で構成されているもの -代替キー（オルタナティブキー）：候補キーのうち主キーでないもの -外部キー：リレーションにおいて他のテーブルの主キーを参照する属性 -ナチュラルキー：候補キーのうち、業務的に意味のある内容を値として持つもの（＝サロゲートキーでないもの） -サロゲートキー（代理キー）：候補キーのうち、業務上は意味を持つ値ではないが、システム的に一意な値をとるよう連番を振るなどしたもの。候補キーが複合キーで属性数が多い場合、PKを一属性としてテーブルを取り扱いやすくしたりするためにサロゲートキーを用いる。PKとせず代替キーとすることもある（そこは設計次第）。 -開発の現場でテーブルのキーと言ったら主キーのことを指していることが多い -ある列が主キーであると同時に外部キーであるということもありうる *関数従属性 [#o408a441] -関数従属性：属性Xを決めると他の属性Yが決まる状態 -完全関数従属：候補キーのすべてに関数従属している状態 -部分関数従属：候補キーの一部に関数従属している状態（候補キーの一部になっていない属性に関数従属性があっても部分関数従属とは言わない点に注意） -推移的関数従属：関数従属が推移的に行われている状態。X→YかつY→ZでありZ→Xではない --例）社員番号→社員の住所→郵便番号 -多値従属性：Aが決まるとBという集合が決まる。 --例)：地方がわかると県が決まる -結合従属性：分解によって得られる表が結合によって元の表に戻せる性質。無損失分解できるような状況。 -関数従属する方向とE-R図のリレーションは方向が逆になる *正規形の種類 [#n6b4a2da] -非正規形：繰り返し項目が残っている状態 -第１正規形：非正規形から繰り返し項目を除いた状態 -第２正規形：第１正規形から部分従属性を除いた状態 -第３正規形：第２正規形から推移従属性を除いた状態 -第４正規形：多値従属性が存在するとき、すべての属性がその決定項に従属する関係 -第５正規形：ある表がその候補キー内で結合従属性が満足されている状態 -参考：[[「特殊な正規形」を理解する：「データベーススペシャリスト試験」戦略的学習のススメ（10）（1/2 ページ） - ＠IT>https://atmarkit.itmedia.co.jp/ait/articles/1703/01/news183.html]] 2017 -参考：[[データベースの正規化について - Qiita>https://qiita.com/TAGAKI/items/9330854863fed0c4853e]] 2022.2 **ボイス・コッド正規形 [#k50d35a3] -すべての関数従属の決定項がスーパーキー（候補キー）であるような第３正規形 --あるリレーション (関係) 上に存在する自明でない全ての関数従属性の決定項が候補キーであるとき、かつそのときに限り、そのリレーションはボイス・コッド正規形 (Boyce/Codd normal form; BCNF) であるという。すなわち、ボイス・コッド正規形では、すべての属性が候補キーに完全従属する。この定義には第3正規形への言及がないが、ボイス・コッド正規形のリレーションはすべて第3正規形でもある。 --ボイス・コッド正規形は、ほとんどの場合第3正規形と等価であり、複数の属性からなる候補キーが複数存在する場合にのみ差異が生じうる。第3正規形は非キー属性を従属項とする関数従属性だけを問題とするので、候補キーを構成する属性の間に候補キーを決定項としない関数従属性が存在することを許す。ボイス・コッド正規形では、この問題が存在することを許さない。ボイス・コッド正規形は、いわば第3正規形をより完全にしたものである。 --第3正規形のリレーションは、常に無損失なようにボイス・コッド正規形に分解することができる。 *データ・クレンジング [#ja468638] -[[日本における「名寄せ」と「照合」の黒歴史 | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/column/18/00139/071400095/]] 2023.7 -[[基本4情報での名寄せは難しい｜MORI Daisuke>https://note.com/moridaisukepub/n/nba1c6711b8e7]] 2023.6 -[[とにかく日本の住所のヤバさをもっと知るべきだと思います｜inuro>https://note.com/inuro/n/n7ec7cf15cf9c]] 2023.6 -[[日本の住所の正規化に本気で取り組んでみたら大変すぎて鼻血が出た。 - Qiita>https://qiita.com/miya0001/items/598070abcdf0799daebc]] 2020 -[[データ・クレンジング>http://www5.ocn.ne.jp/~shinya91/csm/31csm_zyunbi.html]] -[[データ・クレンジングと名寄せ技術>http://itpro.nikkeibp.co.jp/article/COLUMN/20070613/274697/]] --例えば，氏名のデータとして苗字と名前が入っているとします。苗字と名前が続けて入力されているものもあれば，半角スペースがはいっているもの，全角スペースがはいっているものもあります。この場合のデータ・クレンジングとしては，半角/全角スペースを取り除く，という行為になります。 --「03(9999)9999」「0399999999」といった電話番号のデータを「03-9999-9999」の形式に補正することもデータ・クレンジングです。また，成人コードという欄に「1：成人」「2：未成年」「3：年齢不詳」という定義がされている場合に，“4”というデータがあったとします。このような未定義のデータを，成人とも未成年とも判断がつかないため不正データとして“3”に修正することもデータ・クレンジングになります。
