Technology へようこそ
ここは技術者の「経験」と「ノウハウ」のブログです
2009年12月09日 |
ＢＩ考 |
| ＢＩとは、業務システムなどから蓄積される企業内の膨大なデータを、 蓄積・分析・加工して、企業の意思決定に活用しようとする手法の ことです。 実現方法としてはデータウェアハウス（DWH）やデータマイニングなど が挙げられますが、さて。DBを設計する手法（どう設計する）は？ というと、実際に経験のある方しかすぐには思い浮かばないのでは ないでしょうか？ もちろん、昨今のハードウェアにモノを言わせるという手もありますが、 膨大なデータをいかに処理するか、目的のデータにいかに早く行き着く か、ということはDWHに限らず求められる要件ではあります。 簡単な例を示しましょう。下記のような売上実績テーブルがあります。 これにキーテーブルを作成し、売上実績テーブルをアクセスする際には キーテーブルを通して検索を行う、というものです。一般に、売上実績 テーブルはファクト表、キーファイルはディメンジョン表と呼ばれます。 売上実績テーブル (年)(月)(日)(週)(曜日)(時刻)(営業日)(店コード)(レジ№)(取引番号) (商品コード)(商品名)(数量)(単価)(値引額)(取引種別) (キーファイル１) (時刻)(年)(曜日) (キーファイル２) (商品コード)(年)(曜日) (キーファイル３) (店)(年)(曜日) 一見、無駄に思えるキーファイルですが、適切に設計すれば安定した パフォーマンスを得ることができます。 SQLServerやOracleのフルテキストインデックスやクラスタ化インデッ クス、またはパーティショニングなど、DWHの敷居を低くする機能を搭載 したRDBもありますが、基本は設計時にアクセスパスを最適化するために どう工夫するか？ということだと思うのです。 Windows7の登場で肥大化する一方のOSは（動きは）軽くなりましたが、 あなたの設計したシステムは？さあ、どうでしょう。 [ posted by H.K ]
スポンサーサイト
|
2008年08月11日 |
ＲＤ工程作業 |
| 現在、ＲＤ工程作業のプロジェクトに関わっており、 今まで、ＰＳ、ＰＧ、ＩＴ工程が主体のプロジェクトばかりだったので 困惑や戸惑いが多く、苦戦しています。 要求定義仕様作成にむけて、現行業務フローと新システムの業務フローの 作成をしています。 現行業務のヒアリングを受け、現行業務フローに表現するまでは 良いのですが、新システムの業務フローを描き始めると、とたんに苦戦が始まります。 業務各部門の違いや改善要求の細かい点が気になり、うまく表現できなかったりしています。 また、 今まで経験した工程でのドキュメントでは、担当以外のドキュメントとの日本語表現の違いが 問題になるような事はありませんでしたが ＲＤ工程では、表現が異なると誤解を生むため統一が必要です。 長いことこの世界に関わっていますが、プロジェクトとは 奥の深いもののようです。 要件定義の方法論を知る といった記事なども見かけるので 今後、参考になる話題があったら紹介しようと思っています。 [ posted by izu ]
|
2006年11月20日 |
インデックス今昔 |
| 「えー！この表、インデックスが８つもあるの！？」 ありえません。せいぜい、ＰＫ含めて3つくらいじゃないですか？ それも設計時はＰＫのみとし、そのＰＫも順番を吟味します。 よく使用する項目の順番、または絞込みのキツい順番にするのが 理想的だと思っています。例えば、 A:得意先枝番 B:得意先 C:伝票区分 D:伝票番号 というPKがあった場合、それぞれの条件で一番データ件数が少なく なるものを第1キーとし、以下、それに準じます。つまり、 D:伝票番号 B:得意先 A:得意先枝番 C:伝票区分 とするわけです。最近のRDBMSは お利口なので、何番目のキーでも インデックスは効きますが、昔はそうでないことがあったのです。 RDBMSといえど、所詮、人の作ったもの。実行プランを見ていると よくわかります。 |
2006年09月06日 |
物理削除か論理削除か |
| 以前、とあるシステムのDB設計を行った際、「削除フラグ」が話題になった ことがありました。そのときは結局、「項目は保持するけど、未使用扱い」 ということで落ち着いたのですが、設計時の経緯を知らないひとがDB構造を 見た場合にどう思うか？ということは結構重要です。「保守性」がよいか わるいかということなんですが。 「削除フラグ」は「論理削除」を意味します。少し考えてみれば解るのです が、あるキーのデータが論理削除され、同一キーのデータが入力された場合、 1回目はよいのですが、2回目以降、キー重複になってしまいます。では削除 フラグをキーにすればよいかというとそういうことにはなりません。 本来、削除フラグを持つ、ということは「履歴を残したい」場合が多いので、 前回削除フラグが立ったレコードを削除後、今回削除されるデータをアップ デートすればよい、というのは意味がない場合が多いのです。 すっきりさせるためには「履歴テーブル」を別途用意して、本来のテーブル は「物理削除」というのがよいのかもしれません。 データベースの設計とは難しいものです。 |
2006年04月24日 |
ボイスコッド正規形と第３正規形の違い |
| 第２正規形から、推移関数従属を取り除くと第３正規形になります。 商品マスタなどの例を挙げると、 ・商品コード→仕入先コード→仕入先名 この場合、仕入先コード→仕入先名 の部分が推移関数従属です。 「こんなの、仕入先マスタを別に作って名称はそっちで管理するのが当たり前じゃん！」 って言わないでください。 そう、我々は無意識のうちにやっているのです。 さて、ボイスコッド正規形ですが、 以下のような商品マスタ、仕入先マスタがあったとします。前提条件として、 一つの商品に対して複数の仕入先が存在し、仕入先ごとに担当者が決められている ものとします。 商品マスタ（商品コード、仕入先コード、担当者コード） 仕入先マスタ（仕入先コード、仕入先名） この場合の商品マスタの候補キーは商品コード＋仕入先コード、あるいは商品コード＋ 担当者コードです。繰り返し部分がなく、推移関数従属が存在しないので第三正規形です。 しかし、この商品マスタにおいて、もしも、ある担当者が担当する仕入先から仕入れて いる商品が1つだけだったとすると、その商品が削除された場合、担当者が仕入先を担当 しているというデータも削除されてしまいます。 また、実際に商品が仕入れられるまで既存の仕入先と担当者との関係を登録することが できません。また、変更によっても同様のことが起こります。 このような更新不整合が生じるのは、仕入先コードを決定するものとして担当者コードが 候補キーとなっていないからです。そこで、仕入先コードと担当者コードの関係について 以下のように新規分割することによって、こうした更新不整合が起きなくなります。 商品仕入先マスタ（商品コード、仕入先コード） 仕入先担当者マスタ（仕入先コード、担当者コード） 仕入先マスタ（仕入先コード、仕入先名） この分割によって得られた新しい表においては、他の属性がある属性（X）に完全関数従属 である場合で、かつ属性（X）が候補キーであるというボイスコッド正規形の条件を満たす ものとなっています。 第三正規形には「かつ属性（X）が候補キーである」という条件がありません。 でも普通なら、 商品マスタ（商品コード、仕入先コード） 仕入先マスタ（仕入先コード、担当者コード、仕入先名） ですよね。 |
2005年12月02日 |
主キーの候補 |
| 主キーが解れば正規化は行えるということを前に書きました。主キーは、 「行を一意に識別できる」ことが前提ですが、主キーとなる列の値は 次の条件を満たしている方がよいと考えます。 ・NULL値ではない ・簡潔である（複数列にまたがるデータではない） ・単純である（値そのものに意味がない） ・数値または固定長文字列のデータである ・変化する可能性が低い ・値にばらつきがある そういう意味では、自動採番もありだと思います。 |
2005年11月10日 |
正規化 |
| 正規化とは、「データ構造についてデータの冗長性を少なくし、かつ更新不整合が起こらないよう にしていく作業」のことです。 なんとなくこなしているDB設計ですが、理論を勉強しはじめると結構深いものなのです。 正規化には6つの種類があり、それぞれの正規形は前者を包含する関係になっています。 （1）第１正規形 表において、属性の値として繰り返しなどの集合や複合値を持たない表のこと。 （2）第２正規形 表が第1正規形であり、かつすべての非キー属性が主キーに対して完全関数従属である場合の表のこと。 （3）第３正規形 第2正規形であり、かつすべての非キー属性が推移的に関数従属でない表のこと。 （4）ボイスコッド正規形・・・ （5）第4正規形・・・ （6）第5正規形・・・ などと言ってますが、(4)から(6)にかけてはほとんど使用しないので(1)から(3)を覚えていれば 実際の仕事には差し支えないのですが、情報処理試験（DB）ともなるとそうはいきません。 実際、午後Ⅰの問題で「どの正規形か答えよ」－「答え：第５正規形」というのがありました。 正規形といえども難しく考える必要はなく、要するに「主キー」はどれか？がわかれば正規化できる はずなのです。業務的な制約などで自然に「主キー」は決まってきますから、おのずからテーブル 分割を行い、主要なマスタを作成し、トランを作成し・・・・この作業の繰り返しでDB設計はできて しまったりするのです。 私の場合、第３正規形まで分割するタイミングでわざと多めに冗長な部分を残すようにします。 このへんは経験とセンス・・・あまり無いですが・・・。 |
2005年09月26日 |
物理ＤＢ実装の話 |
| 「新論理DBを作成し、新物理DBに展開する」 どこかの教本に出てきそうなフレーズですが、われわれは日常、DB設計を行うときに、 ほとんど意識せず、このことを行ってしまっています。 正規化の概念、意味、意義を知って設計を行っている人はどれくらいいるでしょうか？ 私のモットーは第3正規形が基本。第3正規形にするということは、 ・詳細設計書を書く人ができるだけ苦労しないこと ・プログラマが苦労をせずにDBに関連したコーディングができること を満たす最低条件です。 さらに、以下のようなガイドラインに沿って設計を進めます。 ・項目名は項目辞書を使って統一する ・DBの ・char型は使わず、varchar型を使用する ・smalldatetime型は使用しない ・日付型以外はnullを許可しない ・金額に関する項目は できるだけ金額を表す型にする ・項目の初期値をおおまかに決めておく（例えばint型なら0など） ・ドメイン（有効桁数）を設定し、全体を統一する ・PKは必ず設定する ・追加するIndexは必要なもののみとし、多くても5個以上にならないようにする ・FKは基本的には設定しない ・トリガは使わない ・ユーザ関数は多用しない（無用なオーバーヘッドが発生するため） ・ユーザ定義型は多用しない ある程度設計が進んだ時点で、機能とのすり合わせを行い、性能要件が満たせない 可能性のある部分については導出項目を設けるようにしています。 また、格納件数が数百万件を越える可能性のあるテーブルは分割方法を工夫 することも・・・。発想の転換が必要な場合もありますよ。 |
2005年09月12日 |
DBエンジニアとDB設計の話 |
| システム開発。ありていに言うならコンサルタントが要件を掘り起こし、SEが 業務要件をまとめてプログラマがPGを作成し、各種のテストを行い、納品した システムをユーザが運用する。 ちょっとまってください。 DB設計を行うとき、DBエンジニア（SEが兼務することもあるでしょうが・・・）に 与えられる時間はいかほどでしょうか？ 大きなシステムを開発する際でも、DBの設計にかけられる時間は非常に少ない、 または何かの片手間で行われるのがほとんどではないでしょうか？ DB設計はシステム開発を行う際、アプリケーション設計と並ぶ、いや、それ以上 に重要な作業だと思うのです。 しかし、今日に至ってもDB設計は軽視されています。 かくいう私もDB設計を行うとき、充分な時間を与えられた記憶はありません。 DB設計が適切であればアプリケーションはシンプルになります。（過大な機能を 無理やり実装する場合は別ですが。）また、データというものは時の移り変わり に対してそう変わっていくものではありません。これに着目したのがみなさんよく ご存知の「データ指向設計」です。 システム開発の工程のなかで、ユーザの要件を理論的に表現する必要のある最初 の関門がDB設計だと思うのです。 「優れたDB設計を見ればシステムがわかる」というのが私の持論です。 私がDB設計を行うときの3種の神器は ・項目辞書 ・ERダイアグラム ・コード定義表 です。 項目辞書はDBのテーブル名と項目名、関数名、ストアードプロシージャ名など のオブジェクト名称を決めるための辞書です。 たとえば、売上は SLS（salesから）、金額はAMT（amountから）というように 決めておきます。すると、項目名「売上金額」は SLSAMT となるわけです。 これを実践すると単純なコーディングミスが激減します。 ERダイアグラムは私の場合、少々誇大解釈していて、拡張ERとも少し異なる形式 のものを作成します。実際のテーブルの項目が一覧できることと、アプリケーシ ョンの実装を行う際、プログラマから好評なので、必ず作るようにしています。 項目名の一覧にも使えますし、PKの項目も参照できます。 コード定義表はコード設計じゃないの？といわれるかもしれませんが、私はDB設計 をしながらコード設計を並行して行うことが多いのでDB設計を行うときは必須です。 特に内部コード（外から見えないコード）はここで桁数とかその意味を決めておか ないと後で苦労します。 DB設計が適切に行われると後の工程が非常に楽です。 事実、私の経験したプロジェクトで、DB設計がうまくいった（と思われる）プロ ジェクトはすべてハッピーエンドで終了しています。 あなたが関わったプロジェクトはどうですか？ |
