質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.51%
MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

データ構造

データ構造とは、データの集まりをコンピュータの中で効果的に扱うために、一定の形式に系統立てて格納する形式を指します。(配列/連想配列/木構造など)

Q&A

解決済

6回答

14324閲覧

DB構築をしていますが、設計の部分で悩んでいます。

cicle

総合スコア35

MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

データ構造

データ構造とは、データの集まりをコンピュータの中で効果的に扱うために、一定の形式に系統立てて格納する形式を指します。(配列/連想配列/木構造など)

3グッド

2クリップ

投稿2016/08/26 07:04

DB初心者です。

会社で書類作成するシステム開発にあたり、DB設計をする事になりました。

しかし、使用するデータの量が多くどのように構築すればいいか悩んでいます。

具体的には
1:テーブル名、カラム名が長くなってしまう。
名前は略語、日本語などは使用しない方が良い、パッと名前を見てデータの意味がわかるほうが良いとの記事を読んだのですが、専門用語などを翻訳すると単語が3,4以上になる場合が多く、本当に良いのか?など不安です。

2:カラム数が500個程になってしまうテーブル or 項目毎に分けたテーブル30個。
正規化をしてテーブルを分けようと試みたのですが、繰り返し使うデータはほぼ無く、あっても「書類タイプ」などのものしかありません。
システムでは項目毎に作成したり表示したりするので、このような場合は1対1の構造になるが、項目別でテーブルを作った方が良いのか?など考えましたが、「出来るだけ単純に構築したほうが良い」との記事も読み、どうすれば良いかわからない状態です。

3:多対多の構造について。
テーブルA、テーブルBの多対多の中間テーブルZを使うにあたって、AはZを経由しないとBを保持しているかわからない。
Zを検索するなら、A自体に「has_b」というカラムをもたせた方が、保持していない場合はわざわざZを見に行く必要性が無くなり良いのでは無いか?
また、初めてAテーブルを見た人も中間テーブルの存在がわかりやすいのではないのでしょうか?

宜しくお願い致します。

akoro, stereo_code, yodel👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

coco_bauer

2016/08/26 09:03

本当に500ものカラムを持つレコードを作る必要があるのか、再検討したほうが良いと思います。500もあるとカラム名を把握(記憶)するだけで大変ですから。
guest

回答6

0

ベストアンサー

使用するデータの量が多くどのように構築すればいいか

社内システムとはいえ、初心者が大容量のDB設計をいきなりするのは、ちょっと酷な話ですね。
依頼者は「とりあえず、動けば良い」という気持ちなのかも知れませんが。。

なんとなく、1・2・3を解決して設計しても、後手後手になりそうな気がするので、
そうならないための情報を少し。

-- DB設計の前に~その1~
DB設計ではなく、システム全体の仕様を先に確定する必要があります。
要望があっても「できる」「できない」「難しい」「簡単」etc..の振分も大変かと思いますが、
初心者なので、挑戦するにしても2・3個程度に留めておいた方が良いと思う。
同じような要望も1つを挑戦して、それができてから、他の要望にも着手した方が良いかと。
・・・という感じで、開発するにもステップを踏むことをお勧めします。

-- DB設計の前に~その2~
次にやるのは画面設計(イメージ)と操作設計と帳票設計(イメージ)です。
全画面全帳票の1つ1つの項目に対して、「必須にするか・任意にするか」「何桁にするか」「どのタイミングでどうやって作成・更新・削除するか」etc..を考えます。

-- DB設計
画面設計(イメージ)と操作設計と帳票設計(イメージ)を見て、
これらのデータを抽出するためのテーブルを作ります。
テーブルの各項目を何の型にして、何桁にして・・・という設計はほとんど終わっているはず。
そのため、500項目くらいになっても、問題ありませんが、以下の点に気を付けてみてください。

-- DB設計注意点~その1~
テーブルのレコードが
「いつ登録されるのか」「いつデータが更新されるのか」「いつ削除されるのか」等を意識します。
500項目全ての登録タイミング、更新タイミング、削除タイミングが異なっていたら、
SQLもそれだけ作らなければならない。
大変ですので、分けましょう。
(画面設計の時点でも意識してください)

-- DB設計注意点~その2~
テーブルの各項目が「更新型」なのか「履歴型」なのか意識してみてください。
このタイプの項目は同じテーブルには通常含めませんので、別テーブルで管理する必要が有ります。
(画面設計の時点でも意識してください)

-- その他
遠回りかもしれませんが、頭の中でSQLを作れるようになるまで、SQLに触れた方がよいかも。
頭の中でSQLを作れれば、画面設計しながら、頭の中でSQLを動かせるので、設計も早くなります。
1人で限界を感じるのであれば、納得いく人と出会うまで外注したり教えてもらうのもアリかと。

ちなみに、『設計の部分で悩んでいます。』とあるのに、『設計』とは違うところで
悩んでるようだったので、1・2・3ではなく上記のような回答をしました。

投稿2016/08/27 20:32

tomari_perform

総合スコア760

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

cicle

2016/08/31 08:14

ご回頂きましてありがとう御座います。 頂きました内容を元に、再度見なおしていましてお返事遅れました。 以前、システムを作るにあたり「画面案、機能など」を固めるよりも先にDBの構築が第一と聞いたことがまりまして(そこまで強く言い切ってなかったかも、、、)疑問を抱きながらも、そういうものなのか。と鵜呑みにしていたので、tomari_performさんから頂いた内容は凄く納得のいく、また、質問内容では記載していない悩みの「本質」を見ぬいていただいて、有難う御座います。
tomari_perform

2016/08/31 17:03

フォローありがとうございます。 >システムを作るにあたり「画面案、機能など」を固めるよりも先にDBの構築が第一と聞いたこと →ちょっと、誤解のないように補足しておきます。  画面が存在しないシステム(ツール)や、  他のシステムとの連携が発生するシステム、  既に動いているシステムの改修、  サンプルで作成するシステム等の場合には、  DB設計を先にした方が良いケースもあります。  あくまで、今回の場合(主に新規開発)に限ってくださいね。  ちなみに、熟練者であれば、システムの要件が決まった時点(あるいは、決める時点)で、  画面設計、DB設計(性能設計)、製造方法、試験方法、導入方法、運用方法等を全て同時に頭の中でイメージ出来てしまうので、順番はあまり関係ないんですけどね。 (数学に例えると、途中計算式を全く書かない人、をイメージして頂ければ分かりやすいですかね。) 以下のような流れになって、前に進まない事も初心者には良くある話なので、 変なループに陥いったら、何も進まないまま数ヶ月が過ぎることもあるので、 解決してくれる外注探した方が早い時もあります。 (例)書類作成業務システム 「”書類作成”するために必要な情報として、『書類情報・社員リスト・作成履歴・カテゴリリスト』etc...のテーブルが必要?」 「これらのうち、マスターテーブルを登録する画面が必要?」 「作成画面には何の項目があれば作成できる?」 「運用の時はどのテーブルを誰がいつ登録する?」 「運用で削除するタイミングは?」 「運用で変更はどうすれば?ここで変更すると、他のテーブルとの連携は大丈夫?」 「履歴を確認したいが、どうやって遷移する?」 「あれ?画面は決まってないぞ・・・」←無限ループの始まり。 「あれ?DBも決まってないぞ・・・」 「運用から決める?」 「画面から決める?」 「DBから決める?」  →どれも決められない!(ぉぃ。 etc... 疑問に思った事や確認したい項目を残した状態では、設計は完了しませんので、 羅列する事は良い事ですが、カテゴリは分けて管理しておきましょうね。 また、とりあえず動けばいいや感があったので、 あえてDB設計の注意点には記載しませんでしたが、 DB設計で大事なのは正規化ではなく「性能設計」です。 正規化を優先しがちですが、性能設計ができていないと、どんなに正規化されていても、 「DB設計して作ってみたけど、性能が出ない・・・作り直さねば。」となるのが、 DB設計初心者(中級者も)(たまに上級者も)がハマる内容です。 そのため、当初のご質問の2.3の私からの回答は、「性能設計次第」です。 (Orlofskyさんのコメントより) > 要件定義を明確にした上で、テーブル設計は熟練者を使った方が使い勝手の良いシステムが安上がりでできそうに思えます。 →非常に同感です。性能設計には経験と熟練技が必要です。
cicle

2016/09/01 00:35

更に詳しく教えて頂き、本当に有難う御座います。 私でさえ纏められなかった(何が原因で何を悩んでいるか)事を見通すような回答を頂いて驚いております。 "性能設計"初耳でした。 調べていこうと思います。 "無限ループの始まり" まさにその通りです!カテゴリ分けをし、全体を整理したうえで項目ごとに考えていけば、今の様な混乱した状況は避けられそうです。ここの部分で自分でも頭の中がグチャグチャになっていました。 "とりあえず動けばいいや感" 作るからにはきちんとした物を作りたいと思っているのですが、初心者ですし完璧なものは厳しい。しかし最低限でも、手直しが出来る・やりやすい様に作れないものかと考えておりました。しかし、頂いた内容”「DB設計して作ってみたけど、性能が出ない・・・作り直さねば。」”を拝見すると、私の考えの甘さが確認できました..... そう悩んでいる中で、今回の質問をした経緯があります。(tomari_performさんとのやり取りで気付きました。) 今回、ご回答を頂いて色々と整理出来たように思います。 ありがとうございます。
guest

0

テーブル設計はテーブルが50以上あったらERツールを使った方が良いです。
正規化 は理解されているでしょうか?
パフォーマンスチューニングで呼ばれて調査すると、正規化がめちゃくちゃでシステムのほとんどが使い物にならず、テーブル設計からやり直さないとほとんど対応できないお客様も何度か。テーブル設計から作り直すとデータの移行も必要になり、下手すると新規にシステムを作るより費用がかさみ現行のままになったことも。

投稿2016/08/26 08:46

編集2016/08/26 11:26
Orlofsky

総合スコア16415

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

cicle

2016/08/26 09:57

ご回答いただきましてありがとうございます。 正規化については少し触れた程度でしたので、改めて調べてまいりました。 (もちろん、完全に理解したなどとは思っておりません。) 参考ページ ・http://www.atmarkit.co.jp/ait/articles/1109/07/news124.htmlhttp://www.accessdbstudy.net/archive/category/%E6%AD%A3%E8%A6%8F%E5%8C%96 第1〜第5正規化まであるのですね。 1つ目の記事を読んでいて思ったのですが、 「第1正規化の繰り返しの排除」のためテーブルを作成する。 ということは、繰り返し使用しなデータであればテーブルを分けなくても良いのでしょうか? 今回の「書類作成」にあたっては、 「第1章テーブル」「第2章テーブル」・・・を作り、 「書類テーブル」に「第1章テーブル_id」「第2章テーブル_id」のようにしたほうが良いと思ったのですが、先程あげました「繰り返しの排除」の部分で引っかかり、どうしたものかと思った次第でございます。 また、第3正規化の「推移従属の排除」なのですが「推移従属」についてはわかるのですが、排除する理由がいまいちわかりません。 「排除する」という事は「A->B->Cの時 C->Aを特定出来なければならない」という事でしょうか? 色々と聞いてしまい申し訳ありません...
Panzer_vor

2016/08/28 04:57

> papermaruさん 横から失礼させていただきます。 「第3正規形の推移的関数従属を排除する理由がわからない」とのことについてのみ回答させていただきます。 正規化を行う目的について立ち返っていただくと分かるかと思います。 そもそも正規化を行うのは以下の目的です。 ・1事実1箇所を実現する ・更新時不整合を防止する 推移的関数従属があるということは、 主キー以外のある項目をキー(以下A'キー)に他のある項目群(以下A'名前)が決定されるということですよね? もし上記のA'名前に更新が発生した場合は、更新対象レコードのA'キーと一致する全てのA'名前を漏れなく更新する必要が発生します。 どこか一部でも更新が漏れると更新不整合による矛盾が起こるので、開発者もそこを意識しなければなりません。 それを防ぐ形に正規化を進めたものが、「第3正規形」です。
Orlofsky

2016/08/29 00:24

KotoriMaturi さん フォローありがとうございます。 正規化は通常「第3正規化」までやればだいたい大丈夫なはずです。 @ITの記事「「A->B->Cの時 C->Aを...」はもっと具体的に要件を詰めていかないとわかりません。 要件定義を明確にした上で、テーブル設計は熟練者を使った方が使い勝手の良いシステムが安上がりでできそうに思えます。
guest

0

1:テーブル名、カラム名が長くなってしまう。

テーブル名にもカラム名にもコメントが付けられますので
わかりやすく日本語のコメントをつければ問題ないでしょう。
それに翻訳する必要はなく単にローマ字でもいいんですよ

2:カラム数が500個程になってしまうテーブル or 項目毎に分けたテーブル30個。

正規化は分けることが目的ではありません
なんでもかんでも分ければ集計がしやすくなったり高速になるわけではないのです。
どういう結果を抽出、集計したいか設計段階で検討し
それにあわせて正規化していくのがただしいでしょう。
したがってカラムが大量にあってもかまわないと思います。

逆に項目自体がほとんどNULLだらけになるようなものであれば
詳細用のテーブルに別途まとめてしまうと管理も楽になると思います

3:多対多の構造について。

なんとも言えないです。
単にリレーションで処理できるかもしれないしサブクエリが必要かもしれない、
ビューを作れば済む話かもしれない

投稿2016/08/26 07:36

yambejp

総合スコア114505

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

cicle

2016/08/26 08:18

ご回答ありがとうございます。 ーーーー ローマ字でも問題ないのですね。 勉強になります。 ーーーー 私は「DB構築はシステム内容に左右されず、データ本来の形で無ければならない」と考えていました。しかし、頻繁に使用するデータ、例えばログインに使用するアカウントID、PWだけを保持するテーブルを付くたほうが良い。などの記事を思い出しました。システムに合わせた構築をしても多少なら問題無いということですね。 ーーーー 正解の無い物だとはわかって入るのですが、とどこまでも考えてしまいまして... その分、色々と考えれるので面白い!とは思うのですが、1人だと限界がありますね,,, ーーーー
guest

0

他の回答者様と同じく、
先ずはシステム要件を詰めることかと思います。

時間に余裕があれば、
ヒアリングとかも実施すると良いかもせん。

項目数が多くなるとあるのですが、
本当にその項目をDBに保存する必要があるのか再検討した方が良いかもしれません。
実は何かの表現の言い換えに過ぎず、
本質的には1つに纏まるもの
であればカラムをあえて分ける必要はなくなる訳ですし、
状況を聞くと要件レベルでまた詰めきれていないのかなと思う訳です。

###テーブル名、カラム名が長くなってしまう
他の回答者様もおっしゃっている通り、ローマ字や場合によって略称で問題です。略称の方が親しみやすいケースではむしろ略称を採用する方がよいケースあるかとしれません、下記は一例です。

例:到着予定時刻
フルスペル → EstimatedTimeOfArrival
略称 → ETA

ただいずれローマ字、略称だと意味が伝わらないという心配は当然あるので、コメント付だけはしっかり行うのが望ましいかと思います。

###カラム数が500個程になってしまうテーブル or 項目毎に分けたテーブル30個
カラムが500個を超えてくると結構しんどいかなというのが僕の意見です。

今はExcelも2007以降で「xlsx」が大分主流となってますが、
「xls」だと列数上限が256個までだったはずなので、
カラム数が256を超えてExcelに貼り付けた際に切り捨てられるようになると、
テスト時にストレスがかかること間違いなしです^^;

考えような所はありますが、
意味のある項目群ごとにはテーブルを作っておいて、
検索時には各テーブルを意識せず検索できるようビューを用いるというアプローチもありかなと思います。
(上記アプローチの場合、INSERT、UPDATE、DELETE時のテーブル更新漏れは怖いので、パッケージやストアドで各種一連処理を実装することを強くお勧めしますが)

###多対多の構造について
質問者さんのいうようなリレーション自体の属性持ちですが、
要件によっては有りかと思います。

それこそAテーブルの検索のみに留まる機会が多いとかの場合だと、
毎回リレーションテーブルとくっつけるのも無駄という考えからそのテーブルに属性として導出することはありなと思います。

ただ1点気をつけないとないといけないのが、
属性として導出したということは、
つまり事実を2重で管理することに他ならないので、
整合性が取れないという自体に陥らないよう十分注意する必要は出てきます。

ただ他の人がAテーブルだけ見て、
Bテーブルの存在を一目で分かるという意味での列追加ということでしたが、
その場合はそもそもER図さえしっかり用意すればそのあたりの心配は大抵は無用になると思います。
(ドキュメントを読まない開発者は知らんけど)

###テーブル分割の考え方について
テーブルの分割を行うケースですが、正規化(多:多、1:多)以外にも共通項目の導出などでも発生するということがあることは理解すると良いかもしれません。

例えば様々な書類がある中でも、
それぞれよ書類には共通する項目もいくつか存在する時です。

この場合は以下のイメージで導出テーブルを作成することもあります。

スーパタイプ:書類共通テーブル
サブタイプ:A書類テーブル、B書類テーブル、C書類テーブル

上記のようにすると、
以下のメリットが享受できます。

  • 各種書類の共通属性は書類共通テーブル内で管理可能
  • 各種書類の合計レコード数の総和 = 書類共通のレコード数となるので書類全体の作成数を書類共通より把握できる

投稿2016/08/28 04:37

Panzer_vor

総合スコア1636

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

cicle

2016/08/31 08:40

皆様から頂きましたご回答を元に、再度確認しておりまして、お返事が遅くなってしまいました。 やはり、要件をきちんとヒアリングすることは大切ですね。 書類というのも、専門的な内容の物になりすごい不安のなか開発が進んでいまして、、、 質問事項に関して、項目毎に丁寧にご回答頂きまして有難う御座います。 DBに関してもスーパータイプ・サブタイプ(オブジェクト指向のスーパークラス・サブクラス的な物?)もあるのですね。 ご指摘の通り、数パターンの書類が必要なので助かりました。
guest

0

他の方もおっしゃっているように、DB設計ありきではなく
DBを含めたシステム設計をまず形にするのが先じゃないかなあ。
そして、そのためのプロトタイピングですよ、と。

試作品を作って評価するってやつですね。
まあ、それにかけられる人手も時間もないかもしれませんが、
少なくとも紙の上でシミュレーションくらいやっておけば
多少なりとも方向性は見いだせると思います。

投稿2016/08/27 22:13

takasima20

総合スコア7458

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

cicle

2016/08/31 08:15

ご回答有難う御座います。 他の方からも頂きました様に、DBのみに焦点を当てた設計ではなく、システムとしてを考えるようにしてみようと思います。
guest

0

1:テーブル名、カラム名が長くなってしまう。

いいんじゃないでしょうか。
具体的にどのようなテーブル名を付けようとされているのかにもよりますが。
「the_ticket_for_reserver_with_prize_item」とかの文節表現になっていると改善の余地がありそうですが。
具体例の提示をいただけませんか。

2:カラム数が500個程になってしまうテーブル or 項目毎に分けたテーブル30個。

抽象的すぎて何とも言えませんが、カラム数が500と言うのは設計がおかしいのではないでしょうか。
こちらも具体例の提示が欲しいところです。

3:多対多の構造について。

コレも具体例がないと状況次第の回答となります。
が、ごく一般的な状況で考える場合、個人的にはtable Aに[has_b]を付けるというのはナンセンスだと思います。
仮に[has_b]がfalseなのに、関連するtable Zが存在する事態に陥った場合、システムがどういう挙動になるか即答できますか。
正規化はすればするほどいいわけではなく、適切な粒度が存在するモノですので。
中間テーブルを使うのが必ず正解と言うわけではありません。
絶対的な正解と言うのは難しいので、結局実例がなければゴニョゴニョとしか言えませんね。。

投稿2016/08/26 07:24

kunai

総合スコア5405

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

cicle

2016/08/26 08:00

会社での開発になっていまして、どうしてもこのような質問しか出来ないのです。 そのような中でご回答頂きまして、本当に有難う御座います。 ーーーーー 1 テーブル名に関しては、「占有部分における権利が所有者以外の場合についての事項」などをまとめてテーブルにした場合にそのまま翻訳すると大変なことになるな・・・と思ってしまい、このような質問をさせて頂きました。 ーーーー 2 「書類テーブル」を作成した時に、カラム数が500個(項目)になってしまうという事なんです。kunaiさんの仰るように設計に問題があるとしたら、「1対1の関係になってもテーブルを分けるべき。」なのでしょうか? ーーーー 3 確かに、仰られるようにそのような不具合が起きた場合。恐ろしくて想像したくもありません... 矛盾が起きた場合、どちらが正しいか?がわからなくなってしまいますものね。 有難う御座います。 ーーーー
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.51%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問