モデリングのスタイル：意味論と統辞論 - 設計者の発言
ＤＯＡ（データ中心アプローチ。ＤＢシステム設計においてＤＢ構造の検討を優先させる手法）の考え方では、それぞれのテーブル（エンティティタイプ）について、「リソース」か「イベント」かを区別するやり方が主流である。 主流派の向こうを張ろうってわけでもないのだが、筆者はデータモデリング手法の前提としてそれらを区別しない。なぜかというと、それらの区別が各テーブルの「絶対的な特性」ではなく、「相対的な傾向」でしかないと考えるからだ。ある文脈ではイベントとみなされるテーブルが、別の文脈ではリソース的なものに見えるなんてことが実際にはある。 たとえば、イベントの代表であるような「受注」や「売上」も、一定期間向けキックバックの計算過程においては、「顧客」同様にリソース的なものとして見える。また、リソースの代表であるような「品目」も、品目分類や商品企画を云々するモジュールにおいてはイベント的なものに見える。
3 日坊主日記 - 6NFかわいいよ6NF
新着記事 2006-12-29 SQL Designer ThunderBird 送信済みトレイでフィルタを実行してしまったとき 2006-12-27 高知出張 Rails 勉強会＠関西第6回 (2) 2006-12-26 cocoa surround.vim 2006-12-24 聖剣1 2006-12-18 rakeがエラー 2006-12-17 Temporal Data on Rails: #1 Collection Item の生成 2006-12-15 WEB+DB PRESS Vol.36 2006-12-11 Rails 勉強会＠関西第6回 2006-12-10 トランザクション処理, 読書について 2006-12-06 6NFかわいいよ6NF 2006-12-01 UnSpun by Amazon 最近のツッコミ rkyntggejp (06-19) カテゴリ Apach
T.Teradaの日記 - ログイン直後のレスポンスの返し方
多くの会員制Webサイトでは、ID/PWによるログイン処理がある。ユーザにログイン画面を提示し、ユーザがフォームにID/PWを入力してsubmitする。ID/PWがOKであれば、ユーザのブラウザにはログイン後の画面が表示される。 以下に、これを実現するための2通りのシーケンス図を描く。セキュリティの観点で望ましいのはA、Bのどちらだろう？というのが今回のテーマ。 Aではログイン要求に対してHTTPステータス200応答とともにログイン後画面をブラウザに返している。Bではログイン要求に302応答を返して（HTTP1.1では303応答）、ログイン後画面にリダイレクトしている。 結論を言うと、セキュリティの観点では、私はBの方が望ましいと考えている。 逆に言うと、Aにはどうにも気に入らないところがある。それは、ID/PWを含むリクエストに対して200応答を返していることだ。200応答のページは、ブ
マスタメンテナンスで未来のデータを入力したいんですけど - 極北データモデリング
マスタメンテの扱いは毎回困るところ。 どうもマスタデータには「最新」系のものと「無時間」系のものがあるらしい。 いつのトランザクションデータと結合しても問題ないのが「無時間」のマスタで、問題を起こすことがあるのが「最新」のマスタ。 元号マスタなんてのは無時間。 商品マスタとか部門マスタなんかが「最新」のマスタ。属性が今時点の値になっているので、古ーいトランザシクョンデータと結合すると「商品名が(過去の事実と)違う」「部門の所属セグメントが違う」みたいなことになる。 そういう属性はトランザクションデータ側にコピーしておけばとりあえず問題ないんだけど*1、ほんとに困るのは未来のデータを前もって入力したいとき。 例えば4/1から新入社員が1000人入ってくる会社で、3月中に新人の情報をちまちま入力していると、3月中の社員数が狂ってしまう。正しくは4/1の明け方に1000人分入力しなくてはならない
RDBアプリケーションのためのデザインパターン
[Contribution to Japan PLoP] RDBアプリケーションのためのデザインパターン RDB とオブジェクト指向 パターン記述のきっかけ パターンの紹介 このパターンに期待すること RDBとオブジェクト指向 リレーショナルデータベースとオブジェクト指向アプローチには、「表を中心とする集合演算」と「オブジェクトの相互作用」という、セマンティクスギャップ（意味的ギャップ）があり、両者のマッピングは水と油などと言われることもあります。確かにオブジェクト指向データベースを適用できれば非常に簡単に永続化をすることができますが、既存システムとの共存やSQLベースの検索ツールへのニーズなどから、RDBを適用するケースはまだまだ多いようです。 データベースの概念スキーマ設計や、論理レベルの実体関連図は、オブジェクト指向アプローチでの分析段階のモデリング（概念モデリングやドメイン分析など
複雑さに金が落ちる時代は本当に終わるのか？ - アンカテ
RailsやChuraのいけてないところ これは、Ruby on Railsに対する実に的確な批判だと思う。だが、これによって逆にRailsの意味が見えてきたような気がする。 (このエントリ、入口はソフトのやや専門的な話ですが、例によって大風呂敷で、そこから"The World is Flat"の話につながっていくので、できればプログラマ以外の方もおつきあい下さい) Railsというソフト開発ツールの良さは、単に便利とかフルスタック(必要な全ての機能盛合せ)ということではなく、実践的な仕事の流れが背後に想定されていることだ。頭をひねってツールを使いこなすというより、ツール(が想定しているソフト開発手順)に「乗る」という感覚で開発を進めることができる(まさに On Rails)。 だから、Railsの個々の機能の過不足を問題にするのはあまり意味が無い。仮に不足があったとしても、オープンソース
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IT化でいいじゃん - 2008年のはぶにっき
今年も僅かだはぶにっき-バランスということ
ABD（はぶにっき 2006/9/30)
not found
not found
[を] バックアップ用の送電線が意味をなさなかったのか…