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

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

ただいまの
回答率

89.99%

ぐちゃぐちゃなデータベースを正規化して作り直したい! でもどうやって…?

解決済

回答 1

投稿

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

hacosato

score 38

先日の質問に関連しています。

SQLiteのファイルがあって、テーブルがふたつあります。
J-POPの曲をテーブルに収めてあります。

CREATE TABLE oriconranking(
        year int,
        rank int,
        title text,
        artist text,
        releasedate text
    );
CREATE TABLE songs(
        artist text,
        title text,
        lyricist text,
        composer text,
        releasedate text,
        lyricURL text,
        memo text,
        lyric text);


テーブルoriconrankingには、年ごとにランクインした曲のタイトル、アーティストなどが入っています。
select * from oriconranking where title = '恋';
するとこういう感じです。

2017|24|恋|星野源|2016/10/05
2016|32|恋|星野源|2016/10/05
1980|34|恋|松山千春|1980/01/21

2017年に恋という曲が24位にランクインし、同一の曲が2016年に32位にランクインしていて、さらにちがう曲が1980年にもランクインしていることがわかります。

テーブルsongsには、たくさんの曲の情報が入っています。いまはオリコンにランクインしている曲しか入っていませんが、いずれオリコンには関係なく、いろんな曲の情報を入れたいです。
select * from songs where title = '恋するフォーチュンクッキー';
するとこういう感じです。

AKB48|恋するフォーチュンクッキー|秋元康|(略)|oricon2014|(略)
AKB48|恋するフォーチュンクッキー|秋元康|(略)|oricon2013|(略)

何年にランクインしているかがカラムmemoに「oricon0000」の感じで書いてあります。

テーブルsongsには、1曲につき1レコードにしたいのに、いま重複があるのでだめです…。
解消してきれいに作り直したいです。

作り直す方針としては、先日の質問でyonaさんに回答いただいたようにしたいです。
oriconranking2テーブルを以下のように作ろうと思っています。

oriconranking2テーブル
id:プライマリーキー
song_id:songsのプライマリーキー
year:ランクインした年(2017,2016等)

このように作り替えるにはどうしたらいいでしょうか?

わたしは、

  1. テーブルsongsにカラムsongidを作って、rowidを当てる。
  2. Pythonを使って、forループでテーブルsongsを1レコードずつなぞる。
  3. カラムmemoを見て、それをテーブルoriconranking2に転記する。
  4. カラムtitleとカラムartistを見て、いま注目しているレコードと重複していたらそのレコードを削除?

とかってやったらできるかな?と思うんですが、重複を解消する方法を考えていたら混乱してきました…。

SQLのほかにはPythonならすこし使えると思います。

お知恵を貸していただけたらうれしいです!

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

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

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

    クリップを取り消します

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

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

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

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

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

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

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

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

    質問の評価を下げる

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

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

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

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

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

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

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

    詳細な説明はこちら

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

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

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

回答 1

checkベストアンサー

+5

重複を解消する方法を考えていたら混乱してきました

困っておられるようなので、
シンプルになるアイディアだけ言ってみてもいいですか。
(SQLは自力で考えてください)

ランキングと曲でテーブルを分けるのなら、
曲にランキング、ランキングに曲のデータは不要なのでは?

曲の方はJANコードを使えば重複を排除できます。
ランキングの方はそのJANコードだけ入れるとか。


ID 年度 順位 JAN
1 2015 1 123...
2 2015 2 456...
3 2016 1 789...
JAN 曲名 歌手
12345... 恋しtail? LoveLoveWomen

上は単純化したサンプルです。
これがDB設計として良いかどうかともかく、
シンプルなのはシンプルだと思います。
少なくとも、質問の題の正規化はしてます。

なお、年度と順位の複合キーが自然ではありますが、
もし、オリコンのランキングが同率2位とかを許すなら、重複するので、
自動連番のIDを主キーにした方が確実かもしれません。


オリコンには関係なく、いろんな曲の情報を入れたいです

それならむしろ、JANコードが主で、ランキングの方を従、
と考えた方が、シンプルになりそうです。

アプリのドメインが、ランキングなのか、CD全体なのかの違いです。
かりに、本やゲームもDB化するなら、たとえば、AmazonのASINでもいいわけです。

投稿

編集

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2017/11/24 23:25

    ご回答ありがとうございます。
    今回はCDになっていないような楽曲も含めたいため、
    IDはわたしこのデータベース用に自動連番のIDを付与しようと思います。
    JANやASINの話題で盛り上がっているところすみません…!!

    > ランキングと曲でテーブルを分けるのなら、
    > 曲にランキング、ランキングに曲のデータは不要なのでは?

    じつは申し上げにくいのですが、当初からそういうふうにしようと思っていました…。
    文面伝わりにくかったようでごめんなさい…!

    > それならむしろ、JANコードが主で、ランキングの方を従、
    > と考えた方が、シンプルになりそうです。

    こちらも、(JANではないですが)テーブルsongsのidを主として考えていました!

    いまは、このぐちゃぐちゃな感じのデータベースを前にして、
    どういうアルゴリズムのプログラムを書いたらきれいなデータベースに整理し直せるのかについて、
    アイディアをいただけたら助かるなと考えています。

    わたしの誤認がありましたらお知らせください…。

    引き続きよろしくお願いします!

    キャンセル

  • 2017/11/24 23:54 編集

    >どういうアルゴリズムのプログラムを書いたら
    >きれいなデータベースに整理し直せるのか
    あー、「旧DBから新DBへ、データを移行したい」って意味でしたか?

    DBのデータ取得がスクレイピングなど自動的なものなら、
    今のデータは全部捨てちゃっても問題ないでしょうが、
    手作業で大量に入力したりして、捨てたくない場合もあるでしょう。

    その場合の、データを移行するプログラムのアルゴリズムですが、
    前提として、外部に公開するものではない、一度きりの書き捨てですから、
    パフォーマンスとか気にしない、泥くさい愚直なものでいいわけです。

    そこで、一番単純な方法としては、結果から逆算して、【新DBを基準】にします。

    たとえば、2015年1月の1位、2位、3位……と並んでいるなら、
    それを旧DBから検索して順番に取ってくるプログラムを書きます。
    こうすると、並べるだけで、重複がどうとか考える必要がなくなります。

    処理がすごい遅くなると思いますが、別に何時間かかってもいいでしょう。
    逆に、「最小手順で移行するアルゴリズム」とか考える方が時間が掛かります。

    キャンセル

  • 2017/11/25 10:33

    あーそっか、わかりました! ありがとうございます。

    いままで、既存のテーブルsongsを順番にさらいながら、
    必要ない部分を書き換えたり取り除いたりする方法を考えてたんですが、
    テーブルsongsはそのままほっといて、新しいテーブルを作っていけばいいんですね。
    で、最後にいらなくなったテーブルsongsを消せばいいんだ…天才……!

    スクレイピングした部分もたくさんあるんですが、結局手作業で名寄せしたりしてたので、
    データを失うのはつらかったんです。でもこれなら大丈夫!

    ちょっとすぐに時間をつくれないんですが、あとでやってみます。
    お付き合いいただいてありがとうございます〜。

    キャンセル

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

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

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