何故データベース設計は軽視されるのか?

1NAME IS NULL2008/12/01(月) 01:07:27ID:X6n/IiFX
何故データベース設計は軽視されるのか?

ここでいうデータベース設計とは、
特定の業務システムにおける
テーブルレイアウトを設計し、決める作業であるとします。

業務システムにおいては、
このデータベース設計(テーブル設計)は仕様そのものを定義する作業にも
近いと思いますし、この設計は開発工程やその後の運用における品質を
絶対的に左右するものだと思っています。
逆にこの設計があまりにも実現すべき仕様と比較し不整合なため、
その後の開発工程がデスマーチに陥ることも少なくないのではないでしょうか?

にも関わらず、正規化程度も理解できないような担当者が
この設計を行っていたり、業務システムの受託開発において、
「テーブルレイアウトを決める」という作業が、あまりにも軽視されているような
気がしています。

みなさんの現場ではどうでしょうか?
ご意見などお聞かせください。



488NAME IS NULL2012/07/28(土) 10:54:33.10ID:???
>>486
安いので許せや

489NAME IS NULL2012/07/28(土) 10:55:35.76ID:???
>>487
酷い問題のってどれですか

490NAME IS NULL2012/08/04(土) 09:12:32.99ID:???
>>487-488
>>486 は取れなかった奴の言い訳じゃね (w

491NAME IS NULL2013/10/13(日) 20:53:47.26ID:4bhXtCWz
保守age

492NPCさん2014/01/15(水) 06:23:23.94ID:8z9mQXwT
66427727358778987766457232625+40=66427727358778987766457232665
www.2ch.net
toro.2ch.net/db/
toro.2ch.net/test/read.cgi/db/1228061247/

493NAME IS NULL2014/01/29(水) 00:39:34.78ID:???
>>1
せっかく合意のとれた業務フローとテーブル設計を
180度ひっくり返しに来る奴(客・身内問わず)がいるから
それが最初からわかってるから軽視される

494NAME IS NULL2014/01/29(水) 01:16:58.43ID:???
この前某中古ショップですごく安いパソコンを発見しました。
ちょうど私はその時新しいパソコンがほしいと思っていて本当に買おうかと悩みました。
というのも2011年製でCPUがCorei5、メモリも4GBあるしHDDが1TBもあってお値段がなんと38000円でした。
まだ発売日からあまり期間も経っていないしこのスペックでこの値段ならかなりお買い得かなと思ったのですが、問題は少スペース型というか拡張性がないタイプのものだったんです。
それにグラフィックボードもついておらず後々の事を考えるとやめといたほうがいいかなという結論に達しました。
結局ネットでBTOのパソコンを後で注文しました。
いやぁしかしまさか周りにあるパソコンの中で一番スペックが高いのに一番安い値段になってるとは思いませんでした。

http://toro.2ch.net/test/read.cgi/hp/1382021349/
http://toro.2ch.net/test/read.cgi/hp/1352858999/

495NAME IS NULL2014/02/02(日) 00:06:45.66ID:LwhyxpFz
自分で競馬データベースや競馬新聞を作りたいんだが
どんなプログラミング言語を学習すればいいですか?
競馬を通してプログラミングを勉強すれば楽しいと思うし、
仕事にも役立つとなれば一石二鳥。

データーソースは外部の物を利用。

496NAME IS NULL2014/02/14(金) 21:34:14.86ID:???
↓こういう提供されたexcelデータがあるとします
     日本小学校
     1年   |2年
     1組 2組 | 1組  2組
座席番号1安藤 伊藤|五十嵐 飯田
座席番号2臼井 榎本|上田  岡田
座席番号30(全クラス30で統一)

↑をデータベースに格納しようとすると
こういう風な感じになると思いますが
日本小学校 一年 1組 座席番号1 安藤
日本小学校 一年 1組 座席番号2 山田
日本小学校 2年 1組 座席番号1 伊藤

視覚的に編集するには前者の方がやりやすいですよね
こういう前者のデータ構造は何か名称があったりしますでしょうか

また前者のテーブルの横にアメリカ小学校を追加する場合もあります
こういうデータを管理するために何かいいツールとかないでしょうか?
データベースに格納できるよう変換してくれたり

     1年   |2年
     1組 2組 | 1組  2組
日 座席番号1安藤 伊藤|五十嵐 飯田
本 座席番号2臼井 榎本|上田  岡田
小 
ア 座席番号1ボブ トム
メ 座席番号2マリー




こんな風にしたり

497NAME IS NULL2014/02/15(土) 11:02:45.63ID:???
>>496
そもそもそれはデータ構造と呼べる代物かが疑問なんだが
表現方法としては「マトリクス表」とか呼べばいいんじゃね?

ツール?excel使えばいいじゃん
excel VBAでcsvを出力するマクロを作れば終いだ

498NAME IS NULL2014/02/15(土) 20:26:44.89ID:???
やっぱ自作ですかね
どうもです!

499NAME IS NULL2014/07/22(火) 14:35:32.25ID:AM7LzXqx
★2ch勢いランキングサイトリスト★

◎ +ニュース板
・ 2NN
・ 2chTimes
◎ +ニュース板新着
・ 2NN新着
・ Headline BBY
・ unker Headline
◎ +ニュース板他
・ Desktop2ch
・ 記者別一覧
◎ 全板
・ 全板縦断勢いランキング
・ スレッドランキング総合ランキング
・ ログ速
◎ 全板実況込み
・ 2勢
・ READ2CH
・ i-ikioi

※ 要サイト名検索

500NAME IS NULL2014/07/23(水) 19:35:38.12ID:???
 埼玉県警川口署は20日、小学生の女児の下半身を触ったとして強制わいせつの疑いで、
同県蕨市南町、東大大学院博士課程の内藤慶一容疑者(26)を逮捕した。

 川口署によると、内藤容疑者は「研究が忙しく、ストレスがたまっていた。少女に興味があった」と供述している。

 逮捕容疑は1月4日午後5時半ごろ、埼玉県川口市並木2丁目の書店1階の階段近くで、
当時9歳で小学4年だった女児の下半身を触った疑い。

 書店の防犯カメラ画像を解析するなどして内藤容疑者が浮上した。
3月上旬に近くのスーパーで別の女児が下半身を触られる被害があり、関連を調べる。
http://www.47news.jp/CN/201407/CN2014072001001585.html

501NAME IS NULL2015/02/08(日) 18:11:12.29ID:???
色々あるけど結論として
役に立たないんだよ。

まじで。

502NAME IS NULL2015/08/22(土) 10:22:18.62ID:???
テーブル設計がきちんとしてるだけで
オプティマイザがいい仕事するんやで

503NAME IS NULL2015/10/22(木) 23:00:56.18ID:72sKbAfY
☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。

504NAME IS NULL2015/11/22(日) 12:48:10.28ID:7pwbZA71
インターフェイスが決まってからデータベースを設計するのに今更気づいた。

505NAME IS NULL2015/11/24(火) 20:00:17.75ID:dq6F7Xc9
>>504
インターフェイスって何?

506NAME IS NULL2015/11/24(火) 21:21:06.03ID:bTXxqVP9
> 748 名前:名無しピーポ君 :2015/11/24(火) 12:28:48.30
> 噂の日教組保育士がまた報復やったってさ
>
> 749 名前:名無しピーポ君 :2015/11/24(火) 12:41:16.38
> あーーーー在日居住地にある能満幼稚園の

507NAME IS NULL2015/12/10(木) 17:38:16.52ID:9MpJNZja
>>504
システム間インターフェイスだとしても、ユーザーインターフェイスだとしても間違っているか?

508NAME IS NULL2015/12/10(木) 17:40:03.26ID:9MpJNZja
データをどう持つのかを初めから考えていないとUIもデータモデルも失敗する。

509NAME IS NULL2016/01/21(木) 04:46:50.28ID:???
途中で持ち方換える事もあるけどな

510NAME IS NULL2016/12/16(金) 06:28:37.13ID:???
柔軟に設計しろよ。ただしスタンダードはある。

511NAME IS NULL2017/08/18(金) 10:52:33.77ID:???
>>216
Googleの検索システムがKVSの御時世に何言ってっだこいつ?

512NAME IS NULL2017/08/18(金) 13:05:23.32ID:???
>>511
8年前の書き込みに何言ってっだこいつ?

513NAME IS NULL2017/08/18(金) 22:51:50.80ID:41NDIrx4
>>511
>>512
自演なのかも知れんがクッソワロタ

514NAME IS NULL2017/08/22(火) 21:43:07.29ID:???
スレタイが気になっから来てみたが
データベース設計を「テーブルレイアウトを決める」という作業と捉えてる時点でDB設計を軽視してるんだよね

テーブル設計はDB設計の中でも末端作業だから、そういう認識から変えたほうがいい気がする
経験上、DB設計出来ますってやつのうち概念設計や論理設計がまともにできるやつは20人に1人いればいいほう

515NAME IS NULL2017/08/23(水) 00:07:55.54ID:xUh+Pb4A
論理設計とかについて偉そうに語れるほど
論理設計が出来るとは思ってないが

テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことを

末端作業と言って軽視すのは
どうかと思うよ

516NAME IS NULL2017/08/23(水) 01:15:21.19ID:???
軽視してるってわけでもないんだがテーブルレイアウトを決めるのはDB設計全体の一部でしかなく
それも最後のほうにやる作業だって意味

ある業務に関わるデータをどういうデータ構造で管理するのが適切かを考えようとしてる時に
「Excelのフォーマットを決める」ような作業が、RDBなら「テーブルレイアウトを決める」という作業

「どういうExcelフォーマットにしようか」ってのと同じ観点から始めて
テーブル定義書と申し訳程度のER図を書くことがDB設計だと思ってる人がすごく多い
DB設計はテーブルレイアウトを決める作業じゃなくて、DB設計の結果としてテーブルレイアウトが決まる

517NAME IS NULL2017/08/23(水) 02:10:01.71ID:???
システム設計を「クラスの定義を決める」作業として捉えてるのと同じって言ったほうがわかりやすいか

クラス図とクラス定義書を書くのが設計だと思ってる人はほとんどいないけど
DB設計においてはそのレベルの人がたくさんいるよね

518NAME IS NULL2017/08/23(水) 08:18:56.25ID:ZPvWL1rI
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ

それだけの話

それらを必要に応じて
敢えて崩すのはアリだけど
正規化をやらないとかはありえない

519NAME IS NULL2017/08/23(水) 22:05:49.25ID:???
>>518
それって結局、DB設計をテーブルレイアウトを決める作業と捉えてて
テーブルレイアウトを決めるのにはそれらが最も大切だって言ってるんじゃねーの?

例えば正規化ってOOにおけるSRPやOCPみたいな設計原則に相当するものだよ
SRPに従ってクラスを分けることがシステムやプログラム全体の設計の中で最も大切だったりする?
クラス定義においてならまだ理解できるけどさ

それと同じで正規化の知識は必須だし、業務アプリなら当然その設計原則に従ったモデルを作るんだけど
DB設計において正規化することが最も大切なわけではないよ

520NAME IS NULL2017/08/23(水) 22:20:54.73ID:HAUVK0b0
>>519
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ

それより大切なことって何かな?

521NAME IS NULL2017/08/23(水) 22:52:53.62ID:???
>>1
>何故データベース設計は軽視されるのか?

理由を考えてみたが、教育不足と経験不足が大きな原因だと思う

まず一般的なプログラムの設計に比べてDB設計はその機会自体が圧倒的に少ない
それはプログラムに比べてDBは数も少なくライフライクルも長いし、プログラム設計に比べればDB設計は一人で担当できる規模が大きいから

機会自体が少ないから、業務アプリに関わるエンジニアの中で繰り返し何度もDB設計の経験が積めるような人も当然少ないし
その中でも優れたDB設計者となるともっと少ない

だから一部のDB設計に特化した会社や部門を除くと、かなり大手でもDB設計に関してまともに後進の教育や育成ができるような人はすごく稀
そうでない人たちに教育・育成されたエンジニアが大多数を占めるからDB設計が軽視されることが自然と多くなる

DB設計能力の低いと、どうしてもプログラムの処理に重きを置きがちで
プログラムからデータをどう使いたいかという観点でDBを設計しちゃう人が多い(=DB設計の軽視)
そういうやり方を見てきた人たちはそれが当たり前だと考えるからDB設計軽視が再生産される


個人レベルでは優れた教育を受けたり、数多くの経験を積むことで負の連鎖からは抜け出せそう
会社レベルではDB設計の機会の少なさと重要性を認識して、優れた育成者を多く育てる努力が必須かな

522NAME IS NULL2017/08/23(水) 22:56:37.93ID:???
>>520
DB設計において最も重要なことは
ビジネスドメインと要求を深く理解して適切なデータモデルを作ること

523NAME IS NULL2017/08/23(水) 23:33:45.34ID:HAUVK0b0
>>522
ビジネスドメインと要求を深く理解するというのは
そもそもデータベース設計レベルの話かい?

524NAME IS NULL2017/08/24(木) 00:54:44.89ID:???
>>523
そうだよ
ちゃんとしたデータベース設計には必須だよ
対象のドメインと要求を深く理解しないと適切なデータモデルは作れないから

だからプログラムの実装に近い人がDB設計するよりも
要求分析をする人で技術力もある人がDB設計をしたほうがまともな設計ができることが多いよ
後者の場合は組織や責任者がDB設計にとって何が重要か理解しててDB設計を軽視してないっていう理由も大きいけどね。

525NAME IS NULL2017/08/24(木) 01:09:48.34ID:3UP+EtyQ
>>524
ふむ

要求分析をする人で技術力もある人が
ビジネスドメインと要求を深く理解して適切なデータモデルを作れば

テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するのは
やらなくて良いと仰りたいなかな?

526NAME IS NULL2017/08/24(木) 01:22:40.19ID:???
>>523
大局的には「計算機で効率的に処理可能な形式で対象を表現したモデル」――「対象領域の計算機向けモデル」(数理モデルとか、あっちの意味でのモデル)の構築こそが根本であるので、
それを重要視する、ということ?

でも個人的には正規化などのtuple(型)の設計しながらフィードバックしていって上記の概念を理解・把握・構築している感じがある
具象から始まり抽象化する、というか、つまり何なのか、を追求していくとそこに至るというか


なので個人的には>>522>>520 ww

データベースに長けた人からみるとまた違うのかな?

527NAME IS NULL2017/08/24(木) 01:41:42.12ID:3UP+EtyQ
>>526
ビジネスドメインと要求を深く理解して適切なデータモデルを作る

という作業の中に

テーブルを正規化したり
適切なデータ型を決定したり
制約を定義する

という作業が内包されてるなら
そもそも比較することが間違い

528NAME IS NULL2017/08/27(日) 03:26:41.28ID:???
正規化も、データ型の決定も、それより上位の工程がちゃんとできてれば
ほぼ機械的に決定して薦めれるからなぁ

529NAME IS NULL2017/08/27(日) 11:26:11.65ID:???
DB設計と、要件定義やモデリングとかとを同一視しすぎてるような気もするな。
本質的に不可分なのだという主張なら、それはそれというか、方向性としてはわかる。
もっとも、そうなるとその線引きは難しいだろうけど。

530NAME IS NULL2017/08/27(日) 13:03:07.94ID:???
>>528
機械的にやれるからと言って軽視するのが
そもそも間違い

531NAME IS NULL2017/08/27(日) 16:06:51.20ID:???
>>529
DB設計の一部である概念設計は要件定義の一部
という考え方なので不可分といえば不可分

フェーズの呼び方は会社によって違うだろうけど
要件定義時に概念設計,
基本設計時に論理設計,
詳細設計時に物理設計が基本

DB設計の質を一番大きく左右するのが概念設計
エンティティの漏れやリレーションの間違いがあると
制約の定義漏れやデータ型の選択ミスとは比べられないレベルの悪影響が出る
(正規化の多くは概念設計で行われる)

もっと狭義のDB設計フェーズという考え方があるのかもしれないけど
そういう考え方自体がデータベース設計軽視につながっている可能性があるのかも

532NAME IS NULL2017/08/27(日) 19:45:14.75ID:???
>>531
その考え方を徹底すると、DB設計はなくなりそう。w

533NAME IS NULL2017/08/28(月) 10:28:40.21ID:???
>>530
機械的にやれるということと、軽視するということには関連性がない
君はいったい何と戦ってるんだ?

534NAME IS NULL2017/08/28(月) 19:01:17.75ID:???
>>531
概念設計、論理設計、物理設計のどの段階で正規化するの?

535NAME IS NULL2017/08/28(月) 19:05:55.75ID:pMau8GL2
>>534
普通は初めから正規化したようなまとまりで考える。

536NAME IS NULL2017/08/28(月) 22:24:53.78ID:???
概念モデルに正規化もなにも無いと思うけど
概念を正しく論理モデルにする作業が正規化だろ

537NAME IS NULL2017/08/28(月) 22:34:45.38ID:???
>>534

>>535の言うとおり、どこかで正規化の工程があるというよりは
最初からほぼ正規化されたモデルで考えて
モデルを改善するたびに正規化違反をチェックしながら都度対応する

なので概念設計が終わったらその段階まででの正規化も終わってる
論理設計時にはサロゲートキーや削除フラグみたいなのが追加されて
正規化が崩れる場合があるからその場合も都度判断して対応する
物理設計では正規化に関わるようなところは基本的にいじらない

DB概念設計のインプットになるようなドメインモデリングをする時は
概念間の関係とわかりやすさを重視するので正規化されてるかどうかは気にしない

538NAME IS NULL2017/12/29(金) 11:16:22.87ID:dtNZwIie
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

DX2Z9GYZ7S

新着レスの表示
レスを投稿する