タグ

DatabaseとDB設計に関するmytechnoteのブックマーク (5)

  • 素早く正規形を見抜く実践テクニック(1/4) - @IT

    今回のテーマはデータベースエンジニアの必須知識の1つである「正規化」です。正規化は、リレーショナル・データベースのテーブル設計を行ううえで非常に重要なテクニックであり、データベースを設計、実装したことのある方なら一度は正規化に触れているのではないでしょうか。 それほど基的な知識であるにもかかわらず、正規化を説明できる人はなかなかいません。多く聞かれるのが「何となくテーブルを作ると自然に第3正規形になる」とか「実務上は第3正規化まで行えば問題ない」というものです。 ではなぜ「第3正規化まで行えば問題ない」のでしょうか。稿ではひととおり正規化について確認しながら、あまり触れられることのない第3正規化より先の正規化を紹介して、この疑問に答えていきたいと思います。 正規化の位置付け 正規化は、データベース設計全般にかかわる基礎知識ですが、特に論理データモデリングの作業の中で必要になります。稿

    素早く正規形を見抜く実践テクニック(1/4) - @IT
  • DB設計でこだわりたい三つの要素

    This document discusses Spark, an open-source cluster computing framework. It begins with an introduction to distributed computing problems related to processing large datasets. It then provides an overview of Spark, including its core abstraction of resilient distributed datasets (RDDs) and how Spark builds on the MapReduce model. The rest of the document demonstrates Spark concepts like transfor

    DB設計でこだわりたい三つの要素
  • その選択、ちょっと待った!NoSQLデータベースへ乗り換える前に検討すべき3つのポイント

    最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い!!絶対にだ!!」と私は考える。今日はその理由について語ろうと思う。 トランザクション先日、リレーショナルデータベースにおけるDB設計についてセミナーで解説したばかりだが、リレーショナルデータベースにおけるデータの整合性は何もDB設計だけが担保しているわけではない。リレーショナルモデルと同じかそれ以上に欠かせないのがトランザクションだ。 トランザクションがあるおかげで、トランザクション終了後のステータスは「成功」か「失敗」の2つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの

    その選択、ちょっと待った!NoSQLデータベースへ乗り換える前に検討すべき3つのポイント
  • 「達人が語る こんなデータベース設計はヤダ!」へ参加してきました - 虎塚

    あの『達人に学ぶDB設計 徹底指南書』を書かれたミックさんが講演されると聞いて、Club DB2さんの勉強会に初めてお邪魔してきました。 「第146回 達人が語る こんなデータベース設計はヤダ!」 https://www.ibm.com/developerworks/wikis/display/clubdb2/146 非常に面白く、勉強になりました。せっかくなので、備忘メモをupしておきます。 (内容に誤りがあったり、もし掲載自体に問題があったりしましたら、修正・削除しますのでお知らせください。>関係各位) 編 (追記)発表資料にリンクしました。 http://d.hatena.ne.jp/mickmack/20120714/1342246442 ミックさんが「これだけは覚えて帰ってください」とおっしゃった3つのポイントを引用します。 トレードオフ うまい話には裏がある。 物理 vs 論

    「達人が語る こんなデータベース設計はヤダ!」へ参加してきました - 虎塚
  • 複合主キーを避けるべき理由 - 虎塚

    データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 (2011/07/25 追記)複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり

    複合主キーを避けるべき理由 - 虎塚
  • 1