DB周り等、データの繋がりの考え方

Question

直接SQLの話というわけではなく、データベースの考え方に関する相談です。

私は複数のテーブルのデータの繋がりを理解して使用通りのSQLを組んだりすることが大変苦手です。
複数結合の中に自己結合なども加わってくる複雑なものなど本当にデータ構造の理解や整理が出来ず、業務で１時間未満で済むようなことを半日以上考えこんでしまい、仕事としては致命的な状態です。
このような、データの構造理解力を付けるにはどうしたらいいでしょうか。
何か、アドバイスや訓練方法、参考になる書籍、サイト等ございましたら教えていただきたいと思い質問投稿致しました。
宜しくお願い致します。

Answer 1

お使いのDBがなにかわかりませんが、ビジュアルなクエリビルダをとにかく動かしてみて、どういうクエリを書けばどういうデータが出てくるのかのいわゆる「できるパターン」を地道に増やしていく
またビジュアルなクエリビルダによっては、書いたSQLからビジュアルなクエリが生成できるものがあるので、それが使えれば理解しやすいかと

ボキャブラリーが増えると未知のものでも、なんとなく「あれ」と「これ」を組み合わせたらできそうだ的なものが増えてくるように思いますがいかがでしょう？

Comments

[DgRp_08]

回答有り難うございます。
使用が多いのはSQL Serverですが、これの場合は仰るとおりクエリを書いてみてデータを見てみて……としているのですが、マイクロソフトのCRMの場合FetchXMLメインでして、クエリを書くということがあまり出来ないです。それでもクエリに置き換えてみようと考えて書いてみたりもするのですが、合ってるのかも分からずで糸口が何も見えない状態になってしまいます。
データの構造が理解できないことにより、抽出するためのテストデータすら用意できず、実装が進まないなどの状況に陥ってしまいます。
今書いてて気付きましたが、データの構造理解が出来ないのは特にCRM利用の時だと思います。CRM自体大変使いづらく、SQL Serverに比べてすぐにデータを組合せたり見てみたりということが出来ないので尚更頭の中で混乱してしまうのだと思います。

[dojikko]

Dynamics CRMでLinqが使えるとインテリセンスが効いたりして職人芸的なことが減るのかもしれませんが、Linqのウケもいまいちですし
昔Dynamics CRMのぶっとい本を恵贈いただいたのですが、ささっと読んで「ここには手を出しちゃだめだ(笑」と直感しました
あっち方面はクエリのビジュアライザも期待できなさそうですね

[DgRp_08]

返事が遅くなってしまいすみません；；
正直CRMはDB云々より使いにくさ等もあり苦手意識が倍増している気がします。
とりあえず今回質問のきっかけになった、止まってしまっていた作業については職場の先輩が「これでOK！」と記述してくれたXMLが間違ってたせいでデータが取れてなかったというのが事実で、私の考え方は合ってました(^^;)
それでもやはりDBは苦手という感覚があるので、少しずつ簡単なものから慣れていけるようにしたいと思います！
回答有り難うございました！

Answer 2

プロジェクトによってER図のつながり方とかが変わってくるとは思うのですが、
だいたいは

・主にデータを取ってくるメインのテーブルがある
・それに付随した情報を一緒にとってこようとした場合に、各テーブルとメインのテーブルのカラムの関連性を考える

だと思うので、まずはメインのテーブルを決めてそのテーブルの取得条件を考えてみてSQLを作ってみて、
後から結合するテーブルと条件を増やしていくのがいいと思います。
DBによっては関数もいろいろ用意されているので、どんなのがあるのかを調べられるサイトを見つけておくのもいいと思います。

ちっちゃいことの積み重ねで、どんどん色々なSQLが書けるようになってくると思いますよ^^

テーブルがないとかデータを触れない場合などでも、オンラインでSQLを試せるサイトもあるので、
利用してみるのもd('-'*)
⇒SQL Fiddle

---

<追記：2016/06/15>
ER図はEntity Relationship Diagram：ERD を日本語略語表記してるのかな。
各テーブルやデータの関係や構成を記載したものです。
だいたいこんな感じ → webに転がってたER図サンプル
大きいプロジェクトだと こんな感じ にもなります。

SQL書くときは必ずER図を使ってますよ。
どこのテーブルの項目を取ってきたほうがいいかなど、考えをまとめやすいです。

Comments

[DgRp_08]

返事が遅くなってしまいすみません。
サイトのご紹介までいただきありがとうございます。
そもそもER図ってなんだろう。。。と思い、調べましたが業務でまだER図をあまり見たことがありませんでした。文字だけで「◯◯に紐づく△△を表示」とか書いてあるだけで。
まだまともな実装経験も１年ちょいで、SQLはまだまだ不慣れなので焦らず仰るとおり小さいところからこつこつ試していって慣れようと思います。
回答ありがとうございました！

Answer 3

苦手意識が先行してなおさら苦手になっているのかもね。
複雑なものを一気に解決しようとしても難しいので、
まずは簡単なパターンから考えてみてはどうでしょうか。
A B C D と結合する場合は、まずA Bだけ考えて、
その結果に順次 C D と追加していく感じ?
たぶん慣れれば時間かけずにできるようなると思いますよ。:-)

Comments

[DgRp_08]

返事が遅くなってしまいすみません。
結合自体はそのような考え方でなんとか大丈夫なんですが、なんといえばいいんでしょう、、、すみません自分がどういうデータの時に「わからない」となるのか曖昧なのでまずは基礎を固めつつその辺を見極められるようにしたいと思います。
回答有り難うございました！

Answer 4

参考になるかわかりませんが、
私の場合、複数のテーブルの関連性を考える際はまず、2つのテーブルを選択し
以下の3パターンを考えます。
1)親子関係か否か
2)無関係か
3)同じ親を持つ同レベルか

参考になれば幸いです。
私が複雑なデータベースを見たことが無いから
こんな考え方が通用するのかもしれませんが。

Comments

[DgRp_08]

回答有り難うございます。
いろんなデータベースに共通する考え方だと思うので、ぜひ参考にさせていただきます。
経験不足から、そういった考え方のアドバイスもとてもありがたいです。
回答有り難うございますした！

Answer 5

DB定義書やER図を見て、どのテーブルがどのようにつながっているかを理解していくのが
よいかと思います。
そして自分が欲しいデータがどのテーブルから取得できるか、どのテーブルと結合するのか、
内部結合か外部結合か等を考えてSQLを書いてみて、意図したデータが取得できているか
確認する。
取得できていなければ、どのテーブルの結合までは正しくデータが取得できているか
１つずつテーブルを結合していけば、だんだん慣れてくると思います。

私自身「FetchXML」を使用したことがないので、アドバイスになっているかわかりませんが…。

Comments

[DgRp_08]

返信が遅くなってしまい、すみません。
SQL系の実装経験が多くないのも苦手原因だと思います。焦らず簡単なものから一つずつ、ですね。
頑張ってみます。
回答有り難うございました！