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

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

ただいまの
回答率

90.47%

  • データベース

    857questions

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

テーブルの設計がどうしたらいいかわかりません

解決済

回答 4

投稿 編集

  • 評価
  • クリップ 0
  • VIEW 1,709

shiho

score 8

ジャニーズの情報をまとめたWikiみたいなWebアプリを作っています。
ページのデータをデータベースに保存しようとしていて、現在以下のようなテーブルを考えています。
  • TOP - TOPページの情報を入れています。
  • profile - グループ個人のデータを入れています。
  • TV - TVごとの情報を入れています 
  • movie - 映画ごとの情報を入れています。
  • radio - ラジオごとの情報を入れています。
  • CM - CMごとの情報を入れています。
  • magazine - 雑誌ごとの情報を入れています。 
それぞれに以下のようなカラムがあります。
  • artist -パラメーターで使う名前です。
  • group - 画面にのせるグループ名です。
  • name - 個人の名前やTVのタイトルなどを入れます。
  • setumei - 内容を入れています。
このような設計でどうでしょうか?

TOPページは編集させないことにし等と思うのでテーブル管理はしないことにします。
グループごとに以下のようなページがあります。
  • TOPページ - グループの説明を入れます。
  • profileページ - グループ個人のプロフィールを人数分入れます。
  • mediaページ - グループのメンバーのTV,movie,radio,CM,magazineの情報を入れます。

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

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

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

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 4

checkベストアンサー

+1

面白そうなテーマでしたので、私なりに設計してみました。

ただし、これはあくまでご提示いただいた情報から推測した
「私ならこうするだろう」
というものであって、質問者様が想定されているWEBアプリに即したものかどうかは保障いたしかねます。

採用するとしても、適宜カスタマイズするか、
お近くに先輩エンジニアなどがいらっしゃれば、レビューしていただくのが良いと思います。

あと、個人的に"artists=グループ名"がどうしても納得できなかったので、
artistという言葉を(個人の)アーティスト、と言う意味で使用しています(^^;

見本
table1 : テーブル1
  column1 : カラム1
  column2 : カラム2
  ...
  * key1 : 複合キーなど
  ...

table1.column1の外部キー … table1テーブルのcolumn1カラムの外部キー


 ジャニーズWikiアプリ テーブル設計

groups : グループの情報を管理するテーブル
  group_id : プライマリキー
  group_name : グループ名
  description : 説明文

artists: アーティストの情報を管理するテーブル
  artist_id : プライマリキー
  artist_name : アーティスト名
  description : 説明文(生年月日・出身地などを細かく管理したければ、別途カラムを用意する)

group_artist_relations : アーティストが、どのグループに所属しているかを管理するテーブル
  group_id : groups.group_id の外部キー
  artist_id : artists.artist_idの外部キー
  * pk_group_artist_relations : group_idとartist_idの複合プライマリキー

media : テレビ・映画などの出演媒体を管理するテーブル
  media_id : プライマリキー
  title : タイトル
  genre : 媒体のジャンル。テレビ=1, 映画=2, ラジオ=3, ...
  description : 説明文

media_artist_relations : アーティストが、どの媒体に出演しているかを管理するテーブル
  media_id : media.media_idの外部キー
  artist_id : artists.artist_idの外部キー
  * pk_media_artist_relations : media_idとartist_idの複合プライマリキー

 補足

1. group_artist_relationsテーブルについて
ジャニーズについてはよく知りませんが、一人のアーティストが複数のグループに所属することがありえると考えたため、n対mのリレーションを表現できるよう、group_artist_relationsテーブルを定義しました。
一人のアーティストは一つのグループにしか所属しないのであれば、artistsテーブルにgroup_idカラムを設けてもよいでしょう。

2. mediaテーブルについて
ジャンルごとに異なる情報を管理したい場合、
(例えばTVはテレビ局と放送時間、映画は配給会社と公開日、・・・など)
私なら
tv_additional_info : TVの追加情報を格納するテーブル
  media_id : media.media_idの外部キー
  broadcaster : 放送局
  ...

movie_additional_info : 映画の追加情報を格納するテーブル
  media_id : media.media_idの外部キー
  ...

...
のような感じで各ジャンルの追加情報テーブルを定義しますが、、
アプリ側の実装の難易度が高くなると思われるので、
そこまでやる必要があるのか、慎重に検討することをお勧めします。

3. アプリからのデータ読み出しについて
/TOP.jsp?artist=グループ名
というURLを想定してるようですが、これはまずい設計です。

もし、グループが改名したらどうしますか?
また、関ジャニ∞の"∞"をURLに含めて、アプリが正しく読み取れると確信できますか?

このような場合、各レコードに不変で一意な値(IDのことです)を割り振り、それを使用して
/TOP.jsp?group=[group_id]
と、やるのがよいでしょう。
もちろん、IDは数字(最悪でも英数字)です。

4. 用語について
当回答には、質問者様がご存じない言葉が使われているかもしれません。
しかし、私は努めて一般的な用語を使用しているつもりですので、がんばって調べてみてください。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/10/20 02:49

    自分ならさらに、group_artist_relations に加入日・脱退日を持たせるかな。

    キャンセル

  • 2015/10/20 11:57

    Kosuke_Shibuya様、コメントありがとうございます。

    ご提案いただいた設計を加えると、
    例えば加入日・脱退日で検索やソートなどもできるようになりますね。

    ただ、今のところ、私は
    「そこはアプリの要件しだい」
    という立場を取らせていただきますw

    ご提案の設計だと
    同じグループへの"加入 -> 脱退 -> 再加入"を表現できなかったり、
    あるアーティストが所属中のグループを検索するために"脱退日 IS NULL"という条件を加えなければならない
    など、メリットだけではない側面もあるためです。

    キャンセル

  • 2015/10/24 23:46

    詳しくありがとうございます
    参考にさせていただきます

    キャンセル

0

この情報だけでは適切な設計か判断できません.
たとえば,データベースとのやり取りを極力減らしたい場合(古い携帯端末などスペックが低い場合など)は,管理はしづらいですが,すべてを1つのテーブルにまとめ,1度で必要な情報すべてを取れるようにします.

ある程度の人数で管理し,データベースに厳密な設計が求められる場合は,データベースの正規化などについて検討する必要があるでしょう.

個人的に作成する場合には,自分で管理しやすければ十分でしょう.他人にこの形が正規化されていて完全なテーブルだって言われたものを管理するより,ずっと長く続けられると思います.

いくつか指摘すると,TOPページの情報をデータベースで管理するということがいまいちピンときません.
TOPページをデータベースの中身から生成するのでしょうか.
また「artist -パラメーターで使う名前です。」には複数の値が入ることが予想されますが,複数の値を同じフィールドに持たせることは,データベース正規化の点からみると適切ではありません.別テーブルに分けるべきでしょう.

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/10/19 22:58

    /TOP.jsp?artist=グループ名
    などのようなURLになるので、複数の値が入ることはないです。

    キャンセル

  • 2015/10/19 23:06

    グループ名なのですね.失礼しました.それならば分ける必要はないでしょう.

    キャンセル

0

どのような目的でDBを使うかによるかなぁと思います。
ただ、運用がしやすいようなデータストラクチャだといいですね。

列挙されたテーブルを大きく分けると、
・TOPページ
・コンテンツ (TV, movie, radio, CM, magazine)
・入力値チェック用の情報 (artist, group, name, setumei?)

という感じでしょうか?

最もメインになるコンテンツ部分のデータストラクチャは一定にして、
アプリ側のインターフェースを簡単にするのはどうですか?
(例) -> 記事ID、タグ、タイトル、本文、作成日時、更新日時

TOPページはContentsから更新日時が近いものを列挙していく感じでしょうか。
インターフェースの構築が容易な形で
(例) -> 最終更新日時、最近の更新内容1、最近の更新内容2、最近の更新内容3

入力値チェック用の情報はアプリ側からコンテンツテーブルにinsertを行う時の
バリデーションに使うだけかと思うので、あっても無くてもいいんじゃないかなぁって思います。

という感じでしょうか?

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/10/19 22:37

    更新日時を記録することはありません。

    キャンセル

-2

・TOPは要らないと思います。静的コンテンツ(タイトルなど)はWEBアプリで実装する話でしょうし、動的なものは、TV, movie, radio, CM, magazineと同列にother(その他)として管理したほうが良いです。
・TV, movie, radio, CM, magazineは全部で1テーブルにまとめたほうが良いです。管理の仕方は、TV, movie, radio, CM, magazineの列を追加して、1or0のフラグ管理が良いです。こうすることで、重複情報を扱いやすくなります。
・列名に「group」は避けたほうが良いです。扱いづらくなる可能性があります。
・profileとTVのひも付けがイメージできません。ただ、管理かなり面倒になるんじゃないかと思いますので、思い切ってprofileは削除してみては如何でしょうか。
・掲載フラグの列を追加してやると、下書き的情報を管理しやすくなります。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/10/19 22:30

    profileで一つのページでTV,movie,,radio,cm,magazineで一つのページです。

    キャンセル

  • 2015/10/19 22:31

    1or0フラグの管理とは何ですか?

    キャンセル

  • 2015/10/19 22:37

    データパターンが1か0という管理方法です。

    キャンセル

  • 2015/10/19 23:00

    すみません、何を1or0で管理するのかわかりません

    キャンセル

  • 2015/10/19 23:05

    記載の通りの列です。

    キャンセル

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

  • ただいまの回答率 90.47%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

同じタグがついた質問を見る

  • データベース

    857questions

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