何故データベース設計は軽視されるのか？ (659ﾚｽ)
上下前次1-新
515: 2017/08/23(水)00:07 ID:xUh+Pb4A(1) AAS
論理設計とかについて偉そうに語れるほど
論理設計が出来るとは思ってないが
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことを
末端作業と言って軽視すのは
どうかと思うよ
516: 2017/08/23(水)01:15 ID:??? AAS
軽視してるってわけでもないんだがテーブルレイアウトを決めるのはDB設計全体の一部でしかなく
それも最後のほうにやる作業だって意味
ある業務に関わるデータをどういうデータ構造で管理するのが適切かを考えようとしてる時に
「Excelのフォーマットを決める」ような作業が、RDBなら「テーブルレイアウトを決める」という作業
「どういうExcelフォーマットにしようか」ってのと同じ観点から始めて
テーブル定義書と申し訳程度のER図を書くことがDB設計だと思ってる人がすごく多い
DB設計はテーブルレイアウトを決める作業じゃなくて、DB設計の結果としてテーブルレイアウトが決まる
517: 2017/08/23(水)02:10 ID:??? AAS
システム設計を「クラスの定義を決める」作業として捉えてるのと同じって言ったほうがわかりやすいか
クラス図とクラス定義書を書くのが設計だと思ってる人はほとんどいないけど
DB設計においてはそのレベルの人がたくさんいるよね
518(1): 2017/08/23(水)08:18 ID:ZPvWL1rI(1) AAS
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ
それだけの話
それらを必要に応じて
敢えて崩すのはアリだけど
正規化をやらないとかはありえない
519(1): 2017/08/23(水)22:05 ID:??? AAS
>>518
それって結局、DB設計をテーブルレイアウトを決める作業と捉えてて
テーブルレイアウトを決めるのにはそれらが最も大切だって言ってるんじゃねーの？
例えば正規化ってOOにおけるSRPやOCPみたいな設計原則に相当するものだよ
SRPに従ってクラスを分けることがシステムやプログラム全体の設計の中で最も大切だったりする？
クラス定義においてならまだ理解できるけどさ
それと同じで正規化の知識は必須だし、業務アプリなら当然その設計原則に従ったモデルを作るんだけど
DB設計において正規化することが最も大切なわけではないよ
520(2): 2017/08/23(水)22:20 ID:HAUVK0b0(1/2) AAS
>>519
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ
それより大切なことって何かな？
521: 2017/08/23(水)22:52 ID:??? AAS
>>1
>何故データベース設計は軽視されるのか？
理由を考えてみたが、教育不足と経験不足が大きな原因だと思う
まず一般的なプログラムの設計に比べてDB設計はその機会自体が圧倒的に少ない
それはプログラムに比べてDBは数も少なくライフライクルも長いし、プログラム設計に比べればDB設計は一人で担当できる規模が大きいから
機会自体が少ないから、業務アプリに関わるエンジニアの中で繰り返し何度もDB設計の経験が積めるような人も当然少ないし
その中でも優れたDB設計者となるともっと少ない
だから一部のDB設計に特化した会社や部門を除くと、かなり大手でもDB設計に関してまともに後進の教育や育成ができるような人はすごく稀
そうでない人たちに教育・育成されたエンジニアが大多数を占めるからDB設計が軽視されることが自然と多くなる
省5
522(2): 2017/08/23(水)22:56 ID:??? AAS
>>520
DB設計において最も重要なことは
ビジネスドメインと要求を深く理解して適切なデータモデルを作ること
523(2): 2017/08/23(水)23:33 ID:HAUVK0b0(2/2) AAS
>>522
ビジネスドメインと要求を深く理解するというのは
そもそもデータベース設計レベルの話かい？
524(1): 2017/08/24(木)00:54 ID:??? AAS
>>523
そうだよ
ちゃんとしたデータベース設計には必須だよ
対象のドメインと要求を深く理解しないと適切なデータモデルは作れないから
だからプログラムの実装に近い人がDB設計するよりも
要求分析をする人で技術力もある人がDB設計をしたほうがまともな設計ができることが多いよ
後者の場合は組織や責任者がDB設計にとって何が重要か理解しててDB設計を軽視してないっていう理由も大きいけどね。
525: 2017/08/24(木)01:09 ID:3UP+EtyQ(1/2) AAS
>>524
ふむ
要求分析をする人で技術力もある人が
ビジネスドメインと要求を深く理解して適切なデータモデルを作れば
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するのは
やらなくて良いと仰りたいなかな？
526(1): 2017/08/24(木)01:22 ID:??? AAS
>>523
大局的には「計算機で効率的に処理可能な形式で対象を表現したモデル」――「対象領域の計算機向けモデル」（数理モデルとか、あっちの意味でのモデル）の構築こそが根本であるので、
それを重要視する、ということ？
でも個人的には正規化などのtuple（型）の設計しながらフィードバックしていって上記の概念を理解・把握・構築している感じがある
具象から始まり抽象化する、というか、つまり何なのか、を追求していくとそこに至るというか
なので個人的には>>522 兼 >>520 ww
データベースに長けた人からみるとまた違うのかな？
527: 2017/08/24(木)01:41 ID:3UP+EtyQ(2/2) AAS
>>526
ビジネスドメインと要求を深く理解して適切なデータモデルを作る
という作業の中に
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義する
という作業が内包されてるなら
そもそも比較することが間違い
528(1): 2017/08/27(日)03:26 ID:??? AAS
正規化も、データ型の決定も、それより上位の工程がちゃんとできてれば
ほぼ機械的に決定して薦めれるからなぁ
529(1): 2017/08/27(日)11:26 ID:??? AAS
DB設計と、要件定義やモデリングとかとを同一視しすぎてるような気もするな。
本質的に不可分なのだという主張なら、それはそれというか、方向性としてはわかる。
もっとも、そうなるとその線引きは難しいだろうけど。
530(1): [age] 2017/08/27(日)13:03 ID:??? AAS
>>528
機械的にやれるからと言って軽視するのが
そもそも間違い
531(2): 2017/08/27(日)16:06 ID:??? AAS
>>529
DB設計の一部である概念設計は要件定義の一部
という考え方なので不可分といえば不可分
フェーズの呼び方は会社によって違うだろうけど
要件定義時に概念設計,
基本設計時に論理設計,
詳細設計時に物理設計が基本
DB設計の質を一番大きく左右するのが概念設計
エンティティの漏れやリレーションの間違いがあると
制約の定義漏れやデータ型の選択ミスとは比べられないレベルの悪影響が出る
省3
532: 2017/08/27(日)19:45 ID:??? AAS
>>531
その考え方を徹底すると、DB設計はなくなりそう。ｗ
533: 2017/08/28(月)10:28 ID:??? AAS
>>530
機械的にやれるということと、軽視するということには関連性がない
君はいったい何と戦ってるんだ？
534(2): 2017/08/28(月)19:01 ID:??? AAS
>>531
概念設計、論理設計、物理設計のどの段階で正規化するの？
上下前次1-新書関写板覧索設栞歴
あと 125 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.008s