何故データベース設計は軽視されるのか？
何故データベース設計は軽視されるのか？
ここでいうデータベース設計とは、
特定の業務システムにおける
テーブルレイアウトを設計し、決める作業であるとします。
業務システムにおいては、
このデータベース設計（テーブル設計）は仕様そのものを定義する作業にも
近いと思いますし、この設計は開発工程やその後の運用における品質を
絶対的に左右するものだと思っています。
逆にこの設計があまりにも実現すべき仕様と比較し不整合なため、
その後の開発工程がデスマーチに陥ることも少なくないのではないでしょうか？
にも関わらず、正規化程度も理解できないような担当者が
この設計を行っていたり、業務システムの受託開発において、
「テーブルレイアウトを決める」という作業が、あまりにも軽視されているような
気がしています。
みなさんの現場ではどうでしょうか？
ご意見などお聞かせください。
> 748 名前：名無しピーポ君 ：2015/11/24(火) 12:28:48.30
> 噂の日教組保育士がまた報復やったってさ
>
> 749 名前：名無しピーポ君 ：2015/11/24(火) 12:41:16.38
> あーーーー在日居住地にある能満幼稚園の >>504
システム間インターフェイスだとしても、ユーザーインターフェイスだとしても間違っているか？ データをどう持つのかを初めから考えていないとUIもデータモデルも失敗する。 >>216
Googleの検索システムがKVSの御時世に何言ってっだこいつ？ >>511
8年前の書き込みに何言ってっだこいつ？ >>511
>>512
自演なのかも知れんがクッソワロタ スレタイが気になっから来てみたが
データベース設計を「テーブルレイアウトを決める」という作業と捉えてる時点でDB設計を軽視してるんだよね
テーブル設計はDB設計の中でも末端作業だから、そういう認識から変えたほうがいい気がする
経験上、DB設計出来ますってやつのうち概念設計や論理設計がまともにできるやつは20人に1人いればいいほう 論理設計とかについて偉そうに語れるほど
論理設計が出来るとは思ってないが
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことを
末端作業と言って軽視すのは
どうかと思うよ 軽視してるってわけでもないんだがテーブルレイアウトを決めるのはDB設計全体の一部でしかなく
それも最後のほうにやる作業だって意味
ある業務に関わるデータをどういうデータ構造で管理するのが適切かを考えようとしてる時に
「Excelのフォーマットを決める」ような作業が、RDBなら「テーブルレイアウトを決める」という作業
「どういうExcelフォーマットにしようか」ってのと同じ観点から始めて
テーブル定義書と申し訳程度のER図を書くことがDB設計だと思ってる人がすごく多い
DB設計はテーブルレイアウトを決める作業じゃなくて、DB設計の結果としてテーブルレイアウトが決まる システム設計を「クラスの定義を決める」作業として捉えてるのと同じって言ったほうがわかりやすいか
クラス図とクラス定義書を書くのが設計だと思ってる人はほとんどいないけど
DB設計においてはそのレベルの人がたくさんいるよね テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ
それだけの話
それらを必要に応じて
敢えて崩すのはアリだけど
正規化をやらないとかはありえない >>518
それって結局、DB設計をテーブルレイアウトを決める作業と捉えてて
テーブルレイアウトを決めるのにはそれらが最も大切だって言ってるんじゃねーの？
例えば正規化ってOOにおけるSRPやOCPみたいな設計原則に相当するものだよ
SRPに従ってクラスを分けることがシステムやプログラム全体の設計の中で最も大切だったりする？
クラス定義においてならまだ理解できるけどさ
それと同じで正規化の知識は必須だし、業務アプリなら当然その設計原則に従ったモデルを作るんだけど
DB設計において正規化することが最も大切なわけではないよ >>519
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ
それより大切なことって何かな？ >>1
>何故データベース設計は軽視されるのか？
理由を考えてみたが、教育不足と経験不足が大きな原因だと思う
まず一般的なプログラムの設計に比べてDB設計はその機会自体が圧倒的に少ない
それはプログラムに比べてDBは数も少なくライフライクルも長いし、プログラム設計に比べればDB設計は一人で担当できる規模が大きいから
機会自体が少ないから、業務アプリに関わるエンジニアの中で繰り返し何度もDB設計の経験が積めるような人も当然少ないし
その中でも優れたDB設計者となるともっと少ない
だから一部のDB設計に特化した会社や部門を除くと、かなり大手でもDB設計に関してまともに後進の教育や育成ができるような人はすごく稀
そうでない人たちに教育・育成されたエンジニアが大多数を占めるからDB設計が軽視されることが自然と多くなる
DB設計能力の低いと、どうしてもプログラムの処理に重きを置きがちで
プログラムからデータをどう使いたいかという観点でDBを設計しちゃう人が多い(=DB設計の軽視)
そういうやり方を見てきた人たちはそれが当たり前だと考えるからDB設計軽視が再生産される
個人レベルでは優れた教育を受けたり、数多くの経験を積むことで負の連鎖からは抜け出せそう
会社レベルではDB設計の機会の少なさと重要性を認識して、優れた育成者を多く育てる努力が必須かな >>520
DB設計において最も重要なことは
ビジネスドメインと要求を深く理解して適切なデータモデルを作ること >>522
ビジネスドメインと要求を深く理解するというのは
そもそもデータベース設計レベルの話かい？ >>523
そうだよ
ちゃんとしたデータベース設計には必須だよ
対象のドメインと要求を深く理解しないと適切なデータモデルは作れないから
だからプログラムの実装に近い人がDB設計するよりも
要求分析をする人で技術力もある人がDB設計をしたほうがまともな設計ができることが多いよ
後者の場合は組織や責任者がDB設計にとって何が重要か理解しててDB設計を軽視してないっていう理由も大きいけどね。 >>524
ふむ
要求分析をする人で技術力もある人が
ビジネスドメインと要求を深く理解して適切なデータモデルを作れば
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するのは
やらなくて良いと仰りたいなかな？ >>523
大局的には「計算機で効率的に処理可能な形式で対象を表現したモデル」――「対象領域の計算機向けモデル」（数理モデルとか、あっちの意味でのモデル）の構築こそが根本であるので、
それを重要視する、ということ？
でも個人的には正規化などのtuple（型）の設計しながらフィードバックしていって上記の概念を理解・把握・構築している感じがある
具象から始まり抽象化する、というか、つまり何なのか、を追求していくとそこに至るというか
なので個人的には>>522 兼 >>520 ww
データベースに長けた人からみるとまた違うのかな？ >>526
ビジネスドメインと要求を深く理解して適切なデータモデルを作る
という作業の中に
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義する
という作業が内包されてるなら
そもそも比較することが間違い 正規化も、データ型の決定も、それより上位の工程がちゃんとできてれば
ほぼ機械的に決定して薦めれるからなぁ DB設計と、要件定義やモデリングとかとを同一視しすぎてるような気もするな。
本質的に不可分なのだという主張なら、それはそれというか、方向性としてはわかる。
もっとも、そうなるとその線引きは難しいだろうけど。 >>528
機械的にやれるからと言って軽視するのが
そもそも間違い >>529
DB設計の一部である概念設計は要件定義の一部
という考え方なので不可分といえば不可分
フェーズの呼び方は会社によって違うだろうけど
要件定義時に概念設計,
基本設計時に論理設計,
詳細設計時に物理設計が基本
DB設計の質を一番大きく左右するのが概念設計
エンティティの漏れやリレーションの間違いがあると
制約の定義漏れやデータ型の選択ミスとは比べられないレベルの悪影響が出る
(正規化の多くは概念設計で行われる)
もっと狭義のDB設計フェーズという考え方があるのかもしれないけど
そういう考え方自体がデータベース設計軽視につながっている可能性があるのかも >>531
その考え方を徹底すると、DB設計はなくなりそう。ｗ >>530
機械的にやれるということと、軽視するということには関連性がない
君はいったい何と戦ってるんだ？ >>531
概念設計、論理設計、物理設計のどの段階で正規化するの？ >>534
普通は初めから正規化したようなまとまりで考える。 概念モデルに正規化もなにも無いと思うけど
概念を正しく論理モデルにする作業が正規化だろ >>534
>>535の言うとおり、どこかで正規化の工程があるというよりは
最初からほぼ正規化されたモデルで考えて
モデルを改善するたびに正規化違反をチェックしながら都度対応する
なので概念設計が終わったらその段階まででの正規化も終わってる
論理設計時にはサロゲートキーや削除フラグみたいなのが追加されて
正規化が崩れる場合があるからその場合も都度判断して対応する
物理設計では正規化に関わるようなところは基本的にいじらない
DB概念設計のインプットになるようなドメインモデリングをする時は
概念間の関係とわかりやすさを重視するので正規化されてるかどうかは気にしない 誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
DX2Z9GYZ7S そういえば、昔、DB仕様が悪くて、日次夜間バッチ処理が2日かかるシステムがあったな。 今の現場にも「正規化！正規化！」キチがおる、確かに少し歪んだところもあるが、締めのバッチなどでやむを得ず放置されている
で、「じゃ、キッチリ正規化してみてよ」ってお願いしたら「影響範囲がー」とか
お前はアホか？お前はそれを改善するために「正規化！」言うてたんやろ
もう。口出しすんなってＰＭに怒られてたわ わかってないやつほど正規化と言ってしまう。用語で知ったかぶりをする典型例。 「良い設計」を専門用語で言うと「正規化」だと思ってるような奴がこの板にも多いよね いまどきまったく正規化されていない表を思いつく方が難しい。 それが難しいようじゃあデータベース設計に向いてないんじゃないかねぇ。 >>545
データベース設計よりも、日本語が向いてなさそう。ｗ すべてを2次元の表であらわしているデータなんて、Excelでも見たことない。 テーブルのことを表、インデックスを索引と呼ぶのはいまだに違和感がある 軽視していないけど、人間の脳には難しいからだよ。
人件費がいくらあっても足りない。
ディープラーニングに任せたほうがいい分野だよ。 設計のどの部分をディープラーニングに任せるって話なんだろうか >>550
製品マニュアルを呼んだことがありますか？ >>550
製品マニュアルを読んだことがありますか？ 軽視したくないけどさ、設計が良いかどうかってどうやって見分けるの？
正規化をバカにする人が多いけど、あれ以外に人に教えられる観点ってあるのか？ RDBに関して言えば正規化ほど体系化されててわかりやすい観点は他にはないね
良い設計かどうかは求められた状況に対してどれだけ高い品質特性を備えているかで
観点としては機能性以外に使いやすさ、わかりやすさ、堅牢性、運用性、耐障害性、
保守性(柔軟性/拡張性/変更容易性)、効率性(時間/資源)、移植性なんかがある
正規化はデータ整合性、使いやすさ、保守性あたりを高めようとするもの 正規化は非正規形で起きる問題(更新異常等)を防ぐものであってそれ以上ではない。
実際、更新異常を考慮する必要のないDWHなどでは不要。 >>559
DWHでも更新異常は考慮する必要あるよ
更新異常ってCRUDのUだけのことじゃないから
DWHは正規化が不要なんじゃなく
ソースデータの正規形をベースに特定の分析用途に特化させて非正規化してるだけ
スタースキーマもスノーフレークもDWHに特化した非正規化パターン
非正規形のデメリットはDWHだろうがOLTPだろうが同じ >ソースデータの正規形をベースに特定の分析用途に特化させて非正規化してるだけ
正規形非正規形というのはあくまでもリレーションの表現であって抽象的なデータモデルには
そんな区別はないんだが。
だからDWHにおいて
>ソースデータの正規形
通常これは実在しない。 >>561
ごめん、何言ってるかわからない
抽象的なデータモデルって何のこと？ どっから出てきたの？ 更新異常が発生しにくいだけで
考慮する必要がないわけないわな
>>561はエアプが即バレして煙に巻きたいのだろう >ソースデータの正規形
これが抽象的なデータモデルを指しているのかと思ったんだが、そうでないなら話は簡単。
DWHは「ソースデータの正規形」が存在することを要求しないんで>>560は正しくない。
データソースが正規化された他のDBであることはあるが、それはそのシステム自身の
要求によって正規化されているだけ。 >>557
正規化がバカにされてるんじゃなく
正規化を理解してなかったり正規化されてるかどうか以外にDB設計を見る目がないのに
ドヤ顔でDB設計を語ろうとしてる人間がバカにされてるんだと思うぞ RDBと関係ないRやPython使った統計処理の分野でも
分析をやりやすくするために下準備としてDBで言うところの正規化をしてる
更新異常を考慮する必要は全くないけど そういうのごっちゃにすると話が発散するからやめて。
そもそもその「正規化」って、リレーションの正規化と違ってなにをどうするかきちんと定義されたものじゃないでしょ。 それに統計解析向けの加工って、クレンジングは最初に必要かもしれないけどあとは解析しやすいようにJOINしまくるのがふつう。
DWHのスタースキーマから任意に抽出した1つの表の形のデータセット、あれがまさに統計解析向けのもの。 エアプDWHの次はエアプ統計解析かよw
なんでろくにやったこともない事を語りたがるのかね データベース設計は軽視されるの原因と
エアプ野郎が語りたがる原因の一つに
素人に毛が生えたような人間には難しさが分からず
自分でもできそうに思えてしまうところにある >>571
誰のどのレスに対して言っているのか曖昧でよくわからんが、とりあえずどのレスの
どこがどう違っているのかはっきり書いたら？
反論は受けたくないけどマウントだけ取った気分になりたい中学生じゃなけりゃ。 エアプ素人さんはスタースキーマのファクトとディメンションがそれぞれ第何正規形か考えると良いと思うよ
>>565の言葉を借りれば正規化すら理解してないのにドヤ顔で語ろうとしてるのが丸わかりだから ど底辺の土方グラマーだけどDB設計させられて「なんでちゃんとしたDB屋に頼まないんだよ、DBって根幹部分で大切だろ！」って疑問だったけどここ見て納得。
日本の企業が作る(使う）システムがクソな理由も・・・ ある意味当たってる。
そうやってしばらくして、曲がりなりにもER図書いたり正規化ができるようになって
いっぱしのDB屋を気取れるようになったら彼等の仲間入り。 >>575
根幹部分だからこそDB中心のシステムを作る開発者なら誰もが身につけておくべきスキルだぞ
要件定義や基本設計を含めて依頼するならともかく
DB設計だけを外部に依頼するのは今の時代にはそぐわないので設計専業のDB屋は絶滅危惧種 ホンマにうわさ以上に凄いのが金さんの億様株レシピて投資ブログ。
ここまじで神すぎる！
めちゃ当てまくる。
おすすめなのは危険な銘柄と宝石の銘柄て記事に出てくる銘柄。 プログラム組まないやつが設計すると保守性重視になるよな…
人間がパッと見て理解しやすい設計にしがち
ナチュラルキー多用したり >>579
ナチュラルキーを多用してるにもかかわらず保守性が高いならいいんじゃね >>580
>>579は「保守性」と言っちゃってるが、実はたぶん保守性の話やないな。
初見のわかりやすさしか見えてないような、困ったちゃんの話なんやろな。 そうすると保守性を理解してない>>579が困ったちゃんってことになる すまん、保守性って言葉が悪かったな
プログラムの保守性ではなくて
ユーザーからの問い合わせ時にデータ見てパッとわかるテーブル構造を好む 人間にとっての見やすさというかわかりやすさも重要な品質要素だからね
それを犠牲にして得られるメリットとのバランス次第
何と何をトレードオフしようとしてるのか理解してないうちはまともな設計は期待できない パッと見理解しやすくて保守性も高いならいいことずくめに読めるが。
たぶん言いたいことは逆になにか問題があるということなんだろうけど
結論書いてないから何を言いたいのかわからない。 >>585
理解力なさすぎ。
人工キー+JOIN前提みたいな、不慣れだとややこしげに見えるテーブルを組みたがらない素人の話なだけやろ。 だから、そこで自然キーの欠点や人工キーの利点を説明しなきゃ何を言いたいのかわからんだろ。
人工キーが自然キーより優れているのは自明だと思ってるとかそんなとこかね。 >>587
SQL書くときに条件や結合は少ないほうがバグが発生しにくい
プログラマにとってはサロゲートキーの方がわかりやすい
しかしサロゲートキーだと生データを見たときにわかりにくいことがある
ナチュラルキーとサロゲートキーの代表的なメリットデメリットだと思うけど…
その辺天秤にかけてこのテーブルはサロゲートキー、このテーブルはナチュラルキーと決定できるのは
設計もプログラムも保守もやる人。
どれか一つしかやらない人はこのへんのさじ加減わからないのでは。 こうやってブレイクダウンするとどこに誤解があるか見えてくる。
複合キーは扱いづらいのでかわりにサロゲートキーを使うことはあるが
自然キーだと一律にサロゲートキーより扱いづらいなんて理由はないだろう。 >>589
おっしゃる通り複合キーの場合だな
大変失礼しました
設計と保守しかしない年配のSEさんはサロゲートキーを知らずに複合キーを使いまくる傾向にある
プログラマは若かったり雇われだったりなので口出しできずにクソシステムの出来上がり >>589
めんどくさ。
そんな話じゃなかったやろ。。。
おまえは、自分が理解できない話を、自分が理解できるようにしたいだけ。ｗ
何が「ブレイクダウン」や。ｗ >そんな話じゃなかったやろ。。。
どういう話なのか、お前はまず言いたいことを結論からハッキリ書くようにしろ。 呼び名はともかく人工キーは80~90年代でも普通に使われてただろうから年配だろうが知らないわけない
複合キーは見てわかりやすいわけじゃないが
人工キーに比べると整合性を維持する設計が簡単なんだよ
SQL書く時は面倒くさいから嫌がられるけど不整合が発生するのに比べればマシだから >>593
不整合はユニーク制約つければいいんでないの 同じ型の単純キー同士なら、それが自然キーか人工キーかで扱いやすさが変わることはないやね。 >>593
ちょっと、「整合性を維持する設計」について詳しく説明してくれ >>557
仕様変更に強いかどうか。それと人間にとってわかりやすいかどうか。正規化の話はもっともらしいが、ちゃんとしたテストと運用・保守をやっていれば、ただの非現実的な理屈だとわかる。 >>593
論理的な整合性をアプリケーションで担保する。そうでないとアプリケーションのテストも難しい。 >>598
彼はアプリ屋と壁を作るタイプだから、かかわらない方がいいよ。 >>599
このちゃんとした
ってのがどれだけ難しいか 
