JPAのサンプルは、たいていデータ構造が手抜き - 極北データモデリング
O/Rマッパーに対してネガティブな意見を見つけた。 O/Rマッパーの話 - 工夫と趣向と分別と。 http://d.akinori.org/?date=20060926#p01 一般に、テーブル設計をクラス設計に擦り寄せれば、リレーションを駆使する必要は減る。この罠にはまると、 オブジェクトクラスにそのまま対応させたテーブルを作ってしまい、コードの見かけはきれいでもデータは ぐだぐだな代物ができがちだ。 オブジェクトグラフの構造をそのままデータ構造にしたらグダグダになりますよ、ということだな。 これ読んで思い出すのが、ちょっと前にJPAの正しい使い方を知ろうと思ってサンプルを漁ってみた時のこと。 実戦で使えるデータ構造を作っているサンプルが無くて、結局JPAてどうやって使えばいいのか分からなかった。 焦点は event の扱いで、サンプルは以下の３パターンに分かれる。 1. そもそも ev
おれおれサブセット実装 - 極北データモデリング
サブセットを実装するとできなくなってしまうことに unique制約 外部キー制約 がある。 例えば、社員マスタを正社員とパート社員というサブセットに分割したとして、 正社員(R) = { 社員ID, 社員コード, 名前, ... } パート社員(R) = { 社員ID, 社員コード, 名前, ... } 社員コードは全社員を通じてユニークである必要があったら、それをチェックするのが面倒になる。 サブセットの社員コードにそれぞれ unique 制約をつけても、「社員全体で一意」かどうかのチェックにならないから。 また、社員の扶養家族マスタというのがあったとして、 社員の扶養家族(MO) = { 社員ID, 続柄コード, 扶養家族名 } このテーブルの社員IDには外部キー制約をつけることができない。 認知番号しかない「サブセット」を作ったらどうか 上記の問題を回避するために、スーパーセットはそ
主キーが「圧倒的多数の関数従属性が成立しないことを保証する」ものならば、受注ヘッダに顧客名を置いてはならないのだろうか - 極北データモデリング
渡辺先生がミステリアスな記事をupしている。 http://watanabek.cocolog-nifty.com/blog/2014/08/post-b7d8.html つまり主キー設計というものは、「いくつかの関数従属性が成立することを分析する仕事」というよりは、 むしろ「圧倒的多数の関数従属性が成立しないことを保証する仕事」である。その責任の重大さがおわかりだろうか。 これはわからない。 情報処理試験なんかに出てくる主キー設計手順では、テーブル上の複数の候補キーから主キーを選択するのではなかったか。 であれば「主キーじゃない候補キー → その他の属性」という関数従属性がテーブル内にあるのは普通のことではないのか。 具体例を考えてみる。 元記事のセミナーの例に倣って、こんな受注ヘッダを想定する。 { 受注番号(PK), 顧客番号(PK), 顧客名, 受注日時 } 実データにおいて、関数
「ドメイン駆動設計」感想(1) - なぜファットモデルになるのか - 極北データモデリング
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (131件) を見る 正月にこれを第2部まで読んだ感想を書こうと思って、何ともう2月後半になってしまった。 いろいろ考えさせられたことを忘れてしまう前に感想文を書きます。 (DBばっかりいじっててコードを書かない)俺みたいなのから見たオブジェクト指向設計の特徴に、「実体(エンティティ)の存在は認めても、関係(リレーションシップ)の存在をなかなか認めない」、つまり関係を極力クラスとして立てない、というのがある。 例えば、部門と社員の関係を「所属クラス」として独立させるより、オブジェクト間の関連
SQLアンチパターン「健忘症的サロゲートキー」の提案 - 極北データモデリング
SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る本書の著者はサロゲートキーに対して消極的なのだから、「サロゲートキーの使い方がおかしい」とか言うのはお門違いなのかもしれないが... 健忘症的サロゲートキー 「SQLアンチパターン」第3章の記述を総合すると、著者はサロゲートキーについて以下のように考えていると思う。 自然キーの一意性・不変性が当てにならない場合に「自然キーの変更の影響を受けないようにする」という目的でサロゲートキーを導入する。 自然キーの重複を防ぐために、自然キーにUNIQUEインデックスを振ることを推奨する。 自然キーの代わりにサロゲートキーを外部キーにする。自然キーは他のテーブルに転
SQLアンチパターン「IDリクワイアド」の再検討 - 極北データモデリング
SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る話題のSQLアンチパターンの目次に「アンチパターン：すべてのテーブルにID列を用いる」とあるのを見て、大胆にもサロゲートキーを否定しているのかと思って読んでみたが、どうも主張がはっきりしない。論点が尽くされていないような... 「SQLアンチパターン」の主張 第3章には以下のようなことが書いてある。 「IDリクワイアド」アンチパターン IDリクワイアドは「すべてのテーブルに"id"という列名の無意味な連番の列を追加し、PRIMARY KEY制約を付与する」というパターンのこと。 何がいけないのか 自然キーにUNIQUE制約を付けないなら、自然キーの重複を
データモデル自体はアジャイルなのだが... - 極北データモデリング
全体に与える影響が極めて大きく、後戻りしにくい「スポンジ層」というのが存在する。そのひとつが渡辺さんの言われているデータモデルである。 データモデリングなきアジャイル開発は危ういか？：An Agile Way 平鍋さんが「(業務システムの)データモデルの変更コストは非常に高い」という意味のことを書かれている。これについて。 データモデル自体の変更コストは非常に低く、後戻りし放題である。新しいスキーマでcreate tableして、データをロードして、drop table/rename tableするだけだからな。 しかし、データモデルに手を入れるためには、同時に既存アプリケーションへの影響を調査して、漏れなく修正しなければならない。 プロジェクトが進行するほど、データモデル改変の影響範囲は広がり、修正点も増えていくだろう(元記事でデータモデルを「高リスク制約」つまり「プロジェクト開始からの
nullについて最後まで考える(1) --- T字形で消せるnull，消せないnull - 極北データモデリング
正美氏とかDateの本を読むと、Codd論文を理解するとnullの存在が許せなくなるのだなあ、と思う。 私はこのnull徹底排除の感覚が理解できていない。Codd論文読んだことないし。 比較演算や集計演算の対象に null が混入していると、直感に反する結果が出てくることがあるのはわかる。 同僚がnot null制約を付けていないのを見つけると「付けないとだめっすよ」と言ったりもする。 でも、これはわかった振りをしているだけなのだ。 nullがよくないのは当たり前として、あらゆるアプリケーションでnullを発生させないことができるのだろうか？ どうしても発生するケースがあるのだとすれば、どのnullはあってもよくて、どのnullはあってはならないのか？ where句に出現するnullと、サブクエリが返すnullと、アプリケーションに返されるnullと、罪の重さは全部同じなのか（違うんじゃな
「データベース設計論」を読む(3) -- ここが理解できないうちはサブセットは使えない - 極北データモデリング
T字形でnullを排除する方法に、「形式的サブセット」の導入がある。 形式的サブセット 顧客マスタに「携帯電話番号」を置くと、携帯を持っていない人の同属性がnullになってしまう。 （まあ、nullにしないで空文字列でも入れておけばいいのかもしれないが*1） そこで、nullを回避するために、顧客マスタを「携帯所有者」「携帯非所有者」に分割する： 携帯所有者 = { 顧客番号, 顧客名, 携帯電話番号 } 携帯非所有者 = { 顧客番号, 顧客名 }という例がデータベース設計論 T字形ER―関係モデルとオジブェクト指向の統合をめざして P-100に出てくる。 これをそのまんまの意味に受け取ると非常に困ったことになる。 FAX番号とかメールアドレスとか、顧客が持ってたり持ってなかったりするものが他にもあったらどうするか。 いちいちサブセットに分割していくと、収拾がつかなくなる。 携帯とFAX
うちの会社は休み放題にすべきだ - 極北データモデリング
勤怠管理なんてやめてしまえばいいのだ。休みたかったら休む。会社に行きたい日だけ行く。そういう会社を目指すべきだ。 行っても行かなくてもいいなら、たまには行きたくなる日もあるだろう。行くのが義務だから毎日行きたくないのだ。 40年前の実証研究で否定された、時代遅れの成果主義なんて止めてしまえばいいのだ。 「がんばった分だけ見返りがある」なんて仕組みには何の魅力もない。「やってもやらなくても見返りがある」なら魅力あるけど。 そんな会社なら職場を守るために狂ったように働いてもいい。 「そんなふざけた制度では誰も働かない」なんて言ってはいけない。会社はソ連じゃないのだ。参加者を選べるのだから、そういう会社をこの世に成り立たせることに使命感を持つ人間だけで回せばいい。俺なら狂ったように働くね。 気が向いたときだけ働いて、めんどくさくなったら休む。それでも誰も文句を言わない。そんな会社なら全身全霊をか
日常用語でnullを理解する(1) - 極北データモデリング
セルコの本なんかには、nullを参照するSQLが直感に反する結果を返すことがあると書いてあるのだが、3値論理は「論理」というぐらいだから人間にとって*常に*不可解なものであるはずがないし、だったらnullがらみのSQLの挙動を直感的・日常的な用語だけで（＝ドモルガンの法則とか使わないで）説明することができるはずだ... と思って新人研修で試してみたところ良好な結果を得られたので、ブログにも書く。 どこが直感的ではないか nullが何かすごくやばいものだとされる根拠のひとつに、 NOT INのサブクエリがnullを1行でも返すと、メインクエリの結果が常に0件になる という現象がある。 たとえば「3値論理とNULL」には、サブクエリがnullを1つ返したために「Bクラスの生徒と年齢が一致しないAクラスの生徒」が特定できない、という例が挙げられている。 この結果が直感に反するように思われるのは、
県と市町村を属性に持つ顧客マスタは非正規形 - 極北データモデリング
新人研修で正規化理論を解説しなきゃならないので復習してみたが、やっぱり実践との関係がよくわからない。 例えば第三正規形の定義は 第二正規形である すべての非キー属性が、キーに対して推移従属していない だと思うんだけど、であれば次のような顧客マスタは非・第三正規形ということになるよな。 顧客マスタ = { 顧客番号(PK), 顧客名, 住所(県), 住所(市町村), ... }市町村が決まれば県が一意に定まるので、 顧客番号 → 市町村 → 県 という推移従属が成り立つ。よって上の顧客マスタは非正規形である。 ... という理解でいいのかな。 正規化しなくても困らない場合がある 上の顧客マスタの推移従属を解消するには 顧客マスタ = { 顧客番号, 顧客名, 住所(市町村), ... } 住所マスタ = { 住所(市町村), 住所(県) }に分解することになるが、現場でこんなことする人が居る
元請から下請に変わって、仕事で理不尽な目に遭うことがなくなった話 - 極北データモデリング
人材募集広告の取材の人が会社に来て、私も転職者代表でインタビューを受けた。 前職と比べて何がよいか聞かれたので、こっちではお客さんに賞賛されたり社内で労われたりすることがあって、そんなこと期待したこともなかったので驚いた話をした。 これは何でなのかというと、以前よりお客さんが儲かるシステムを扱っているからだ。 あたりまえだと思われそうな話だが書いてしまう。 年間1億のコスト削減になるシステムなら、10画面ぐらいのWebアプリに数千万円の予算が付いて、納期もまっとうなものにできる。 逆に、できてもお客さんが大して儲からないシステムを企画すると、予算は付かないし納期も無理なものになる。 先方の担当者の構えも違ってくる。稼動しても社内で評価されないシステムなら、担当者に指名されてもやる気が出ないだろう。 また予算がないと、担当者が我々にタダで追加仕事をさせたくなるので、どうしても不幸なネゴシエー
「自己責任」という言葉の意味が「熟女」の意味のようにずり下がっている - 極北データモデリング
俺が中学生ぐらいのときに「熟女」という言葉が出てきて、それは今なら石田ゆり子とか壇れいとか、あのへんの「あんまり若くないところがいいよね」というゾーンを指す言葉だったんだけど、なぜかだんだん対象年齢が上がってきて、サッチー＆浅香光代の喧嘩が「熟女バトル」と報道されたところでこの言葉の命脈は尽きた。 今「○○さんて熟女ですよね」と言われて喜ぶ女の人はいないだろう。 自己責任という言葉の使われ方も、昔はぜんぜん違ったと記憶している。 俺が最初にこの言葉を意識したのは相場師の林輝太郎の本の中で、そこには「相場で損をしたら『市場の地合が悪い』『証券会社が悪い』とひとのせいにするのは素人で、相場で生活するつもりなら儲けるのも損するのもすべて自己責任と考えるのが当然」という意味のことが書いてあって、あー立派な考え方だなあと思ったものだ。 林氏は「一般人にない自己責任という倫理を、我々相場師は持っている
「俺が知っていることは大事なこと・俺が知らないことはどうでもいいこと」病 - 極北データモデリング
転職したばっかりのとき、Accessのリンクテーブルの作り方がわからなくてもたもたしていたら上司に「えー？こんなことも知らないの？」みたいな感じで「クックックックッ」て笑われてカチンと来たんだけど、カチンときた内容を明文化するならば 今まで知らなくても今日覚えたらそれでいいじゃねえか Accessなんてしょうもない*1ツールを知らなくても別に恥ずかしくないだろ みたいなことを感じたわけだ。 で、この上司にあるプロジェクトのソースのありかを聞いたら「どこ行ったかな...」「うちに帰ったらあるかも」「やっぱり無いかも」とか言われて、びっくりして社内にSubversionか何か立てるから既存のプロジェクトは全部そこに放り込んでくれと言ったら、「Subversionて何だ。何の役に立つんだ。XCOPYでいいんじゃないの」等々と言われて拒否された*2。 この時思ったのが「えー？バージョン管理システム
ウィトゲンシュタインの物差し・「いやらしい体」・他人の商売の悪口 - 極北データモデリング
今年No.1の名著「まぐれ」を読む。 まぐれ―投資家はなぜ、運を実力と勘違いするのか 作者: ナシーム・ニコラス・タレブ,望月衛出版社/メーカー: ダイヤモンド社発売日: 2008/02/01メディア: 単行本購入: 28人 クリック: 585回この商品を含むブログ (174件) を見る この中に「ウィトゲンシュタインの物差し」といういい話が出てくる。 書評は本そのものよりも書評を書いた人のことをいろいろと描き出す。私はこの仕組みをウィトゲンシュタインの物差しと 呼んでいる。物差しでテーブルの長さを測っているとき、とても信頼できる物差しでなければ、同時にテーブルで物差しを 測っていることになる。物差しが当てにならなければ当てにならないほど、得られる情報は物差しに関するものが多くなり、 一方テーブルに関するものは少なくなる。 これ、気付かないでやってしまうと恥ずかしいことになるから注意が必要
JITとTOCの関係 - 極北データモデリング
ジャストインタイム生産(以下JIT)には制約条件という考え方がないから、制約理論(以下TOC)の敵のはずだけど、何だか似てる部分もあるような。 JITとTOCの関係はどうなっているのだろう。この本には サプライチェーン理論と戦略―部分最適から「全体最適」の追求へ 作者: ダイヤモンドハーバードビジネス編集部出版社/メーカー: ダイヤモンド社発売日: 1998/12メディア: 単行本 クリック: 6回この商品を含むブログ (1件) を見る P-72TOCでは制約条件を認定したうえでのシステムになっているのに対して、JITでは制約条件が出てこない。 これはかんばん方式では、問題がなければ工程間のかんばん枚数を順次減らし、そこで問題を起こした 工程が制約条件であり、これを見出し強化するサイクルを繰り返すことに目的があるからである。 すなわち、制約条件を活用するというよりも、常に連続的な体質強化(
極北データモデリング : クラス設計をデータ設計に転用できない理由
2つの集合なり概念なりがあったら、それらの関係は以下のうちどれかになるが、 1. まったく重ならない 2. 一部重なる（けど包含関係じゃない） 3. 包含関係 4. 全部重なる TMでは、2項の関係が上記のうちどれなのかに激しくこだわる。 例えば取引先の区分に「納入先」「支払先」がある場合、納入先かつ支払先の会社があるかどうかで、データ構造が変ってしまうから。 データ設計に比べると、アプリケーションの設計では「2つのクラスが示す概念が、一部重なるかどうか」みたいなことはあんまり問題にならない。 ドメインモデリングするなら（＝問題領域の構造をクラス図で表そうとするなら）問題になるのかもしれないが、私の場合はクラスを単なる実装技術として使っているので。 例えば納入先・支払先のオブジェクトを要求するユースケースが別々なのであれば、取引先の情報を、ある機能では納入先クラスのインスタンスにし、別の機
極北データモデリング : 意味ありコードの実装
ユーザが意味ありコードを要求する理由がよくわからないのだが、西田順生「作る前にコストダウンする技術―景気はいいのになぜ儲からないのか (PHPビジネス選書)」に意味ありコードの実例が載っていたので実装方法を考えてみる。 以下はGroup Technology*1を実現するために、個々の製品にGTコードを付与する話。 GTコードは、製品番号や部品番号に単なる連番を付与するのではなく、下図のように意味のあるコードを持たせます。 大分類では機能や用途、中分類では材質や大まかな形状、小分類では細かな形状や特性、その他の補足情報を意味づけしていきます。 大分類 中分類 小分類 意味 機能 材質 形状 桁 1桁目 2-3桁目 4-6桁目 「あの時の図面は使えないかなー。でもどこにあるのかなー？」 「○○課長、こんな使用の材料は過去使っていませんか？」「さて、どうだったかな？」 GTを活用すれば、このよ
どんな作業のマニュアルでも３時間あれば作れる - 極北データモデリング
例えばお客さんから預かってるサーバの監視とか、いつもの道具立て(ウチなら JSP + Struts + Spring + Spring JDBCとか)でWebアプリケーションを構築するとか、そういう「おおよそ決まった手順があるけど、細部は毎回異なる」作業については、マニュアルを用意して担当できる人を増やさなくてはならないのだが、ウチはそういうものの整備が甘い。これは「マニュアルとは何か」の考え方が統一されてないから。 個人的には以下のようなマニュアル観は間違っていると思う。 不完全なマニュアルを配られても困る マニュアルに書いてある通りにやって問題が起きるぐらいなら、そんなの無いほうがいいんじゃないの 書いてある通りにやって問題が起きても作業者の責任ではない。嘘のマニュアルを書いたやつが悪い マニュアルとは「書いてある通りに作業するためのもの」なのだから、例外事項がたくさんある作業のマニュ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
