JPAのサンプルは、たいていデータ構造が手抜き - 極北データモデリング
O/Rマッパーに対してネガティブな意見を見つけた。 O/Rマッパーの話 - 工夫と趣向と分別と。 http://d.akinori.org/?date=20060926#p01 一般に、テーブル設計をクラス設計に擦り寄せれば、リレーションを駆使する必要は減る。この罠にはまると、 オブジェクトクラスにそのまま対応させたテーブルを作ってしまい、コードの見かけはきれいでもデータは ぐだぐだな代物ができがちだ。 オブジェクトグラフの構造をそのままデータ構造にしたらグダグダになりますよ、ということだな。 これ読んで思い出すのが、ちょっと前にJPAの正しい使い方を知ろうと思ってサンプルを漁ってみた時のこと。 実戦で使えるデータ構造を作っているサンプルが無くて、結局JPAてどうやって使えばいいのか分からなかった。 焦点は event の扱いで、サンプルは以下の３パターンに分かれる。 1. そもそも ev
苦しまないと良い仕事はできない - 極北データモデリング
1月は元旦から休みなしで働いてたんだけど、29日あたりだったか、「絶対間に合わねえ」「何でここまでやらなきゃならないんだ」「誰か代わりにやってくれねえかな」「ていうか、やれよ」といったや恐怖感や被害者意識の果てに、久々にあれが来たのだ。 思考と感情と行動が完全に一致し、作業自体に全身で切り込んでいく感覚。あるいは自分が作業自体になり切る感覚。 人生でほんの数回しか入ったことのない状態。痺れるような、全身全霊で行動しているという実感。 科学者とか芸術家が、さんざん苦しんで試行錯誤した末に最重要なアイデアを手にする、という話がありますでしょう。 全て出し尽くして、もうダメーと思ったところからさらにアイデアを絞る。七転八倒しても何も出ない。倒れるように眠る。すると何かが降りてきて最高のアイデアを手渡してくれる。 輪になった蛇の夢を見て問題が解けたとか、そういう話がありますでしょう。 勘違いされが
「俺が知っていることは大事なこと・俺が知らないことはどうでもいいこと」病 - 極北データモデリング
転職したばっかりのとき、Accessのリンクテーブルの作り方がわからなくてもたもたしていたら上司に「えー？こんなことも知らないの？」みたいな感じで「クックックックッ」て笑われてカチンと来たんだけど、カチンときた内容を明文化するならば 今まで知らなくても今日覚えたらそれでいいじゃねえか Accessなんてしょうもない*1ツールを知らなくても別に恥ずかしくないだろ みたいなことを感じたわけだ。 で、この上司にあるプロジェクトのソースのありかを聞いたら「どこ行ったかな...」「うちに帰ったらあるかも」「やっぱり無いかも」とか言われて、びっくりして社内にSubversionか何か立てるから既存のプロジェクトは全部そこに放り込んでくれと言ったら、「Subversionて何だ。何の役に立つんだ。XCOPYでいいんじゃないの」等々と言われて拒否された*2。 この時思ったのが「えー？バージョン管理システム
人材募集中 - 極北データモデリング
うちの会社が人材募集を始めました。 http://rikunabi-next.yahoo.co.jp/rnc/docs/cp_s01800.jsp?fr=ci_s00860&nit_f=1&rqmt_id=0005330345 Teradataを使い倒してみたい方・大規模DWHの構築と運用をやってあげてもよくってよと思う方は、冷やかしに来てみませんか。 あとうちはWeb系の技術蓄積がまだまだだと思っているので、そっち方面がコアの方もがっちり噛み合うと思います*1。 記事の中で「前職ではいろんな不満があったけど転職してすごくよかった！」て寝言言ってるのが俺なんですが、これはテンプレに俺の名前を入れただけで本当はこんなこと言ってません。ていうか取材自体してもらえなかったの。 うちの親父も小学校の教員を定年退職するときに道新*2が取材に来て「再就職の予定は？」て聞かれたので「もう仕事したくないよ
DB Magazineの良記事 - 極北データモデリング
何ヶ月か前から、Struts + DI + O/Rマッパーのサンプルアプリケーションを集めている。 ソースがあるだけではダメで、なんでそういう設計になっているのか、作者の説明付きのものを探している。 で、DB Magazine 7月号の「DIコンテナをベースにしたアプリケーション実装モデルの作法」が、ぴったりの記事だった。 サンプルアプリは、特定顧客の売上情報(ヘッダ＆明細)を一覧する、というもの。 読みたかったポイントは２点。 このサンプルアプリは、データアクセス層が返すentityクラス(データベーステーブルと1対1に対応するJavaクラス)と、サービス層が返すdtoクラスを別々に作成しているが、それはなぜ、と説明しているか。また、entityクラス <-> dtoクラスのデータの詰め替えは、誰がどのように行うのか。 現代的なO/Rマッパーは、(業務アプリでは必然的に発生する)集計行を
マスタメンテナンスで未来のデータを入力したいんですけど - 極北データモデリング
マスタメンテの扱いは毎回困るところ。 どうもマスタデータには「最新」系のものと「無時間」系のものがあるらしい。 いつのトランザクションデータと結合しても問題ないのが「無時間」のマスタで、問題を起こすことがあるのが「最新」のマスタ。 元号マスタなんてのは無時間。 商品マスタとか部門マスタなんかが「最新」のマスタ。属性が今時点の値になっているので、古ーいトランザシクョンデータと結合すると「商品名が(過去の事実と)違う」「部門の所属セグメントが違う」みたいなことになる。 そういう属性はトランザクションデータ側にコピーしておけばとりあえず問題ないんだけど*1、ほんとに困るのは未来のデータを前もって入力したいとき。 例えば4/1から新入社員が1000人入ってくる会社で、3月中に新人の情報をちまちま入力していると、3月中の社員数が狂ってしまう。正しくは4/1の明け方に1000人分入力しなくてはならない
人に何かやってもらおうと思ったときの鉄則 - 極北データモデリング
組織の全員で何かをやりたいと思ったとき＝例えば「サーバの監視を全員持ち回りでできるようにしよう！」とか「みんなで勉強会しよう！」とか思ったときの鉄則。 朝礼の時とかに、全員に向かって「こうしましょう！」と言っても誰も動かなくて「だー、だからウチの会社はダメなんだー」という落ちになる。 全員にメールを出して檄飛ばすのも同じ。ではどうするか。 沼澤拓也 お客さんに良くなってもらいてぇんです。 P92 社内で人を動かすときは、まず一人からですよ。自分から見て、動かせそうな人をまず一人、 その気になってくれそうな人を作ってください。そして、この人がその気になったら次に。 ... そして次へ、次へと、こうやって広げていく。今までいろんなことをやったけど、これしかないと。 高塚猛 商売魂 P89 私の実感から言って、一同に社員を集めて話しても、意志が伝わる可能性はほとんどない。 だから私はいつも、本当
フラグを属性にするか、リレーションシップにするか - 極北データモデリング
オブジェクトモデリングで何だかよく分からないことに、あるデータ項目を属性にするか関連にするかの基準があいまい、というのがある。 怪しい世界だなあと思って見ていたが、考えてみるとデータモデリングの世界もおんなじです。 あるデータ項目を「属性にするのか、新しいエンティティを生成してそこに入れるか」が、流派によって違う。 どの流派も正規形であることは変わらないのだが... 例えばRDBでは、区分コード＝いわゆるフラグを、別のテーブルとのリレーションシップで表すことができる。 で、あんまりやったことないけど、これからは区分コードを極力排除して、区分をリレーションシップで表現することにしようと思ったのです。 例 商品マスタの中に、現役商品と廃盤商品の両方が入っているとする。 商品マスタ = { 商品ID(PK), JANコード, 商品名, 廃盤区分(Yes/No) ... } また、商品を集めてカタ
エンティティの見出し方・属性の割り振り方 - 伝統的設計・T字形ER手法・ABD - 極北データモデリング
非正規形の表が与えられたときに、その表を出力できるDBをどうやって設計するか。 伝統的DB設計法・T字形ER手法・ABDのやり方を並べて書いてみる。 伝統的DB設計法 伝統的なDB設計では、非正規形の表を正規化する過程で、エンティティを切り出していく。 また正規化しながら、関数従属性に従って属性を割り振っていく。 データ項目の意味は考えず、データ項目の重複が最小になるように分解するので、m:nの関係の時以外は交差エンティティは発生せず、「社員マスタに所属部門コードがある」といった結果になる。 T字形ER手法 上記を問題視したのがT字形ER手法。 T字形ER データベース設計技法 P-26 ER手法が大きく勘違いされた点は、データを正規化してから、ER手法を使ってデータ構造を表現する、という点にある。 つまり、ER手法が表現手段に成り下がってしまったのである。ER手法は、思考手段(解析手法)
2006-10-06
真野正 実践的データモデリング入門 (DB magazine selection) によると、CRUD分析とは別にIRUN分析というものがあるそうだ。 CRUD分析では、各アクティビティがCRUDするエンティティの中の、どの属性が読み書きされるのかまではわからない。 そこでエンティティの属性レベルまで降りて、各アクティビティがどの属性を Import/Refer/Update/Nullify するのかを明らかにするのが、IRUN分析。 分析の結果、同じエンティティの中で生成／消滅するタイミングが違う属性のグループを見つけたら、エンティティを分割する。 例えば、注文エンティティの中の｛ 配送先氏名, 住所, 郵便番号, 電話番号 ｝が注文発生時点では未確定で、後続の「配送・支払指定」アクティビティで値が入力されるとしたら、注文エンティティと配送先エンティティに分割する。 こうすると、それぞれ
今のDIが３年後に叩かれるとしたら - 極北データモデリング
半年前のエントリにトラックバック。 インタフェースの多用 最近DIばやりしていてインタフェースを多用する事例を良くみますが、どうなんでしょうかね。 １インタフェース＝１クラスになっていて、機能追加があったときにわざわざインタフェースと対応するクラス両方 直すようなことになっていたりすることはないのかな。そもそも密なものを疎に扱っているようなケースも多いような。 これ、３年後に絶対アンチパターン扱いになってると思う。 JavaWorld Online に「特集 DIを超えるホニャー」ていう記事が載って、そこで「従来のDIには、以下のような問題があった...」て指摘されると思う。 みんながめんどくさいなあと思っている手法も、代案が出るまでは生き延びる。 Spring が EJB にトドメを刺したときのような、すごい切れ味の代案が出てくるまでは、ツールなり人力なりで地味にシグニチャの同期を取って
delete＆insert するデータのIDを維持しなくてはならない ... のだろうか？ - 極北データモデリング
IDについてまだ考えている。 テーブルごとに必ずIDを振るという考え方に、まだ抵抗がある。 「今のところ誰も見ていないID」を振る意味が分からないのだが... 「誰も見ていないID」とは例えば、delete＆insert で一括登録するレコードに付けたID。 マスタに多値従属する属性を切り出したテーブルで発生する。 ちょっと前に書いた例： MO(=多値を外出ししたテーブル)にはIDを振らない。例えば社内システムで「社員がメールアドレスを 好きなだけ持てる」という場合、社員マスタに社員メールアドレステーブルを外付けする。これがMO。 こんなスキーマですね。 社員マスタ = { 社員ID(PK), 社員番号(UNIQUE), 社員名, ... } 社員メールアドレス = { 社員ID(FK), メールアドレス } ここで、全てのテーブルに機械的にID列を付ける、というルールに従って、社員メール
2006-09-06
とびきりくだらないエントリにはてなポイントくださった方、ありがとうございました！ またくだらないこと書きます！ 今、複合キー論が熱い！ 渡辺幸三氏の「設計者の発言」で、サロゲートキーがDOA派から嫌われている理由がわかった。 理由の一つは、サロゲートキーの導入によって、もともとある複合キーの実装が忘れられがちになる。だから危ない、ということだった。 ということは、 複合キーに忘れずに unique index を付けておけばよい サロゲートキー自体に問題はない ということだな。 代理キーは「スタイル」ではなく「テクニック」 http://watanabek.cocolog-nifty.com/blog/2006/09/post_d032.html じつは「サロゲートキーにこだわるモデリングスタイル」には、目立たないがやっかいな 問題がある。複数のidが複合してユニーク制約を構成している事実
おれおれサブセット実装 - 極北データモデリング
サブセットを実装するとできなくなってしまうことに unique制約 外部キー制約 がある。 例えば、社員マスタを正社員とパート社員というサブセットに分割したとして、 正社員(R) = { 社員ID, 社員コード, 名前, ... } パート社員(R) = { 社員ID, 社員コード, 名前, ... } 社員コードは全社員を通じてユニークである必要があったら、それをチェックするのが面倒になる。 サブセットの社員コードにそれぞれ unique 制約をつけても、「社員全体で一意」かどうかのチェックにならないから。 また、社員の扶養家族マスタというのがあったとして、 社員の扶養家族(MO) = { 社員ID, 続柄コード, 扶養家族名 } このテーブルの社員IDには外部キー制約をつけることができない。 認知番号しかない「サブセット」を作ったらどうか 上記の問題を回避するために、スーパーセットはそ
2006-06-02
「一般的には、第3正規形まででよい」理由について書かれた貴重な記事をきちんと読んでみた。 素早く正規形を見抜く実践テクニック http://www.atmarkit.co.jp/fdb/rensai/db_enginer03/db_enginer03_1.html 「なぜ第3正規形まででよいのか」の結論は以下の通り： テーブル構造からビジネスルールを排除すると、第３正規化までで正規化が完了する。 この記事でいうビジネスルールとは、要するに関数従属性・多値従属性・結合従属性とかのこと。 「ビジネスルールを排除する」とは、リアルワールドにあるｘｘ従属性をDB上の制約として実装しないこと。 つまり、「ビジネスルール」という表現を避けて、ものすごく砕いて書くと、こういうこと： とりあえず第３正規形にして、まだ非完全正規形のテーブルがあったら、サロゲートキーを付ける。 そしたら完全正規形になる。 だ
T字形ER手法でnullを認めない理由(3) - 極北データモデリング
T字形からどんどん離れていくが、SQLでの算術演算について整理する。 算術演算のnull しつこいようだがおさらい。 SQLでのnullは「何か値があるはずだけど、今は分からない」という意味。 なので、nullに対して四則演算すると、何でもnullになる。 「何だか分からない数」に100を足しても、答えは「何だか分からない数」にしかならないから。 ... 上記の説明にはごまかしがある。 例えば customer テーブルの age 列には顧客の年齢が収容されている 年齢の分からない顧客の age 列には、nullが入っている 顧客IDが 100 番の人の年齢は不明である とする。 nullが本当に「何か値があるはずだけど、今は分からない数」であれば、 select age - age from customer where customer_id=100の答えは0になるはずだし、 sele
「C.J.Dateの データベース実践講義」からいつか役に立ちそうな話をメモ(2) - 極北データモデリング
一応読了。 へぇと思ったところと、その他思いついたことをメモする。 ORDER BYはリレーショナル演算子ではない 理由は、タプルに並び順のあるもの＝リレーションではないものを返すから。 とはいえ、DateはORDER BYを否定しているわけではない。 便利な道具をリレーショナルモデルの上に積み増すことは、まったく問題ないと考えている。 しかし、積み増した道具が土台のリレーショナルモデルを破壊するなら、その導入には絶対反対の立場を取る。 例えば、ORDER BYはあっても構わないが、ビューの定義にORDER BYを含めることには反対する*1。 outer join否定論も同様。outer joinは便利だが、SQLの世界にnullを呼び込んでしまうのでDateは否定している。 第6正規形とnull 第6正規形の定義は以下の通り。 関係変数Rは、自明でない結合従属性を1つも満たさない場合に限
2006-04-24
ここでは３値論理のアウトラインを書いて、前回の課題のうち「maybe, unknown, undefined とはどういう意味の値か」だけ解決する。 ３値論理 SQLでは、nullは３値論理で扱われる。３値の真理値表は以下の通り。 NOT not true false null null false true AND true null false true true null false null null null false false false false false OR true null false true true true true null true null null false true null false nullがらみの論理演算結果、例えば nullの否定はnull. true AND null は null. true OR null はtrue. など
EJBみたいなすぐ消える技術がどうして標準になれたのか - 極北データモデリング
今EJB2.xでできてるパッケージの機能拡張をやってるのだけど、EJBてほんとに面白くないですね。 プログラミングの快感が全くないのね。 何でこんなのが標準になってしまったのかというと、ほんとに使えるのかどうか検証されてなかったから... って当たり前なんだけど。 科学の世界では、仮説の提唱者が検証を行う。検証してない仮説を言ってみたところで、話題にはなれても主流にはなれない。 が、我々の業界はそうはなっていない。 とりあえず何か作った人が目立ち、うまく転がったら標準になることもできる、というのはウチの業界の素晴らしいところだ。 1000件以上の成功事例を積むまでモノを言いません*1という世界だったら、新しい技術はさっぱり出てこなくなり、 いまよりずっと変化の少ない、つまらない業界になっていただろう。 問題は仮説の検証するのは誰なのかということで、ソフトウェア開発は科学じゃないから、提唱者
米国産牛肉は足で握った寿司だ - 極北データモデリング
友人と米国産牛肉の話になって、俺は気持ち悪いから食わないと言ったら「非科学的だ」「狂牛病信者」とか言われて馬鹿にされた。 そいつにも言ったけど、牛肉は食い物なんだから、科学的に安全かどうかなんて関係ないんだよ！ 気持ち悪いものは食いたくないって言ってるだけだよ！ 食い物に対して、生理的な嫌悪感を超えて科学的に対応するのは、すごく難しいことだ。 1. 俺は足の指が器用で、床に落ちてるものは何でも足で拾ったりするんだけど、1ヶ月ぐらい特訓すれば足で寿司も握れるようになると思う。 俺がきっちり消毒した足で寿司を握ったら、科学的な人はそれを喜んで食うはずだ。 俺は特上の素材を使うから「うん、うまい！」とか言ってくれるはずだ。 2. どっかの大学が牛の糞からバニラエッセンスを作ることに成功して、３年後に製品化すると言っている。やめろよ！ 「バニラビーンズで作ったアイスクリームと、牛の糞で作ったアイス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
