バリデーションの双方向性問題を解く - 設計者の発言
何回かにわたって「動的参照関係」における整合性に関する問題をとりあげた。とくに、「参照先」が更新された場合に起こり得る不整合について説明した。ただしそれらは「静的参照関係（通常の外部キー制約）」を含め、あくまでも「参照レコードが存在するかどうか」の問題である。 しかし、「参照レコードが存在するかどうか」は多彩な制約の一部でしかない。それ以外にもさまざまな制約があって、それらすべてについて「参照先レコードが更新された場合の不整合問題」がつきまとう。「参照元」におけるバリデーション（制約にもとづく整合性の検証）はこれまでまともに対処されてきたが、何度か書いたように、「参照先」をバリデーションの起点とする不整合問題は見過ごされがちだった。これを、参照元と参照先の双方で対処すべき問題という意味で「バリデーションの双方向性問題」と呼ぶことにしよう。 具体例を見よう。たとえば次のモデルのテーブルＣにお
DBDesigner 4
General Information - What is DBDesigner 4? DBDesigner 4 is a visual database design system that integrates database design, modeling, creation and maintenance into a single, seamless environment. It combines professional features and a clear and simple user interface to offer the most efficient way to handle your databases. DBDesigner 4 compares to products like Oracle's Designer�, IBM's Rational
モデリングのスタイル：意味論と統辞論 - 設計者の発言
ＤＯＡ（データ中心アプローチ。ＤＢシステム設計においてＤＢ構造の検討を優先させる手法）の考え方では、それぞれのテーブル（エンティティタイプ）について、「リソース」か「イベント」かを区別するやり方が主流である。 主流派の向こうを張ろうってわけでもないのだが、筆者はデータモデリング手法の前提としてそれらを区別しない。なぜかというと、それらの区別が各テーブルの「絶対的な特性」ではなく、「相対的な傾向」でしかないと考えるからだ。ある文脈ではイベントとみなされるテーブルが、別の文脈ではリソース的なものに見えるなんてことが実際にはある。 たとえば、イベントの代表であるような「受注」や「売上」も、一定期間向けキックバックの計算過程においては、「顧客」同様にリソース的なものとして見える。また、リソースの代表であるような「品目」も、品目分類や商品企画を云々するモジュールにおいてはイベント的なものに見える。
RDBMSは本当に便利なのか:やむにやまれず - CNET Japan
最近スケーラビリティが花盛りですね。 一昔前からLAMPによるアーキテクチャが基本セットで展開されていました。大企業的思想では、「そんなおもちゃみたいなセットでミッションクリティカルは乗り越えられないのだ！」とか言われ、一部では無視すらされてきたわけですが、最近になってやっと先人のノウハウが少しずつ世に出てきて、古い世代の人達も「そんなに安くてスケールさせながら使えると言うのなら…」と重い腰を上げ始めました。 ミッションクリティカルをLAMPスタックだけで網羅的にやるのはさすがに用途が違いすぎてチャレンジになってしまいますが、その中でもアクセスの膨大な大規模サイトを安定的に動かす…といった要件には有効で、ニーズもあることがやっと理解されてきたように思います。 最近ではmixiや、Livedoorの中の人が何かの講演会や雑誌でノウハウの発表をしていたり、Flickrの中の人も"Buildin
極北データモデリング - ABD (Activity Based Modeling) の体系を想像する(1)
羽生章洋氏のABD (Activity Based Modeling) とはいったい何か、唯一のまとまった資料 http://event.seasar.org/sc2006spring/viewAttachment.do?_pageName_=Materials%2FD4.ppt からその全体像を復元するシリーズ。 もちろんご本人に伺えばいいんだけど、まずは自習から。 初回はざっと読んで分かった気になったことをメモする。全部俺理解だから正確な情報は原典を見てね。 今回は「ABDすると何が良くなるのか」という最重要な話題は避ける。それはABDで設計したデータベースに触ってから書く。 ABDで設計したら、データ構造はどうなる ABDでは、外部キーを、resourceだけでなくeventからも追放する。 つまり 売上ヘッダには顧客IDがない。 売上明細には商品IDがない。それどころか売上ヘッダI
DB Magazineの良記事 - 極北データモデリング
何ヶ月か前から、Struts + DI + O/Rマッパーのサンプルアプリケーションを集めている。 ソースがあるだけではダメで、なんでそういう設計になっているのか、作者の説明付きのものを探している。 で、DB Magazine 7月号の「DIコンテナをベースにしたアプリケーション実装モデルの作法」が、ぴったりの記事だった。 サンプルアプリは、特定顧客の売上情報(ヘッダ＆明細)を一覧する、というもの。 読みたかったポイントは２点。 このサンプルアプリは、データアクセス層が返すentityクラス(データベーステーブルと1対1に対応するJavaクラス)と、サービス層が返すdtoクラスを別々に作成しているが、それはなぜ、と説明しているか。また、entityクラス <-> dtoクラスのデータの詰め替えは、誰がどのように行うのか。 現代的なO/Rマッパーは、(業務アプリでは必然的に発生する)集計行を
スラッシュドット ジャパン | ISBN規格は2007年より改定され13桁に
Yet Another Coward曰く、"既報と思って過去記事を検索してみたが見つからないので改めて報告させていただく。 世界共通の書籍管理番号である ISBN が 2007年より改定される。 今回の改定は、2004年10月にＩＳＢＮ加盟国総会において決議され、2005年5月に日本出版インフラセンター（ＪＰＯ）・日本図書コード管理センター「ＩＳＢＮ（国際標準図書番号）規格改定等について お知らせ」として発表されている。 主な変更点は以下のようになる。 2007年1月1日以降ISBNは13桁とし、EANコード(日本ではJANコード)と一致させる。 現行のISBNの頭に978(EAN書籍出版業コード)を挿入し、CDは再計算する。 2007年以降、現行のISBNは無効。 ISBNを扱う企業の業務としての対応方法は [表示・記載方法] と [読み取り機器の対応] [スリップ標準仕様] [基本シス
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. など
真のデータベースエンジニアを目指そう！（1/3） ― ＠IT
本連載は、ITシステム開発の現場でプログラミングやSQLのコーディングを行っているエンジニア（データベース利用者）が、データ管理者（DA）やデータベース管理者（DBA）へステップアップするための第一歩として有効な基礎知識を紹介する（編集局） はじめに 本連載は、データベースを利用したアプリケーション開発にプログラマとして携わっている読者を対象として、データベースの利用者から設計者へとステップアップするために、いまから身に付けておきたい必須知識を解説していきます。いまはまだ「データベースエンジニア」が何であるか、どんな仕事をするのかがよく分からないといった方にも、本連載を通じて少しでもこの職種に興味を持っていただければ幸いです。 第1回は、「データベースエンジニアの役割、およびデータベースエンジニアに必要とされるスキル」について解説します。 データベースエンジニアとは？ データベースエンジニ
【レポート】Developer Summit 2006 - DBは超グローバル変数、どう設計するか (MYCOM PC WEB)
本稿では、2月9日に目黒雅叙園で開催された翔泳社主催のカンファレンス「Developers Summit 2006」から、スターロジック代表取締役兼CEO 羽生章洋氏のセッション「楽々ERDレッスン〜これが楽々DB設計の勘所！〜」の模様をレポートしたい。なお、羽生氏は、Seasarファウンデーションの理事を務めるなど、オープンソースソフトウェア開発コミュニティでも活躍中である。 さて、システム開発の現場において、データベースの設計は特に重要視されることが多い。では何故DB設計が重要なのか、という問いに対し、羽生氏は「DBはアプリケーションをまたがる『超グローバル変数』だから」だと語る。個別のプログラムにおいてさえグローバル変数の使用には注意が必要なのだから、時として複数のシステムに影響を及ぼすデータベースの設計に最大限の注意が必要なのは当然、というわけだ。データベースの設計がいい加減だと、
pgpool-II README
(*)The function of the replication and the load-balancing cannot be used for the table preserved by dividing data in Parallel Query Mode. Configuring pcp.conf pgpool-II provides the control interface where an administrator can collect pgpool-II status, and terminate pgpool-II processes via network. The pcp.conf is the user/password file for authentication with the interface. All modes require the
「インピーダンスミスマッチ」の本質は何か(3) - 極北データモデリング
本来の（OOP登場以前から言われていた）インピーダンスミスマッチの意味は、ものすごくおおざっぱに言うと、SQLはバッチ処理だが言語はレコード指向でしか処理ができないことだった。 そんなミスマッチは埋めようがないじゃないの。 仮にOOPとRDBの間に埋められない溝があるのだとすれば、我々にできることはどっちかに寄せて使うことしかない。 オブジェクト指向言語をオブジェクト指向言語的に使い、RDBを非RDB的に使う オブジェクト指向言語を非オブジェクト指向言語的に使い、RDBをRDB的に使う のどっちかを選択するしかない。 本来、２つのうちどっちかを選ぶという議論は不毛なので、極力避けなくてはならない。 プロなら、社会人なら、大人なら、両立させる方法を生み出さねばならない（Entity Bean や index-only は、その解の一種だ）。 が、それは置いといて。仮に二元論的な考え方で行くと
2006-01-04
2001年にJavaを始めたときにむなしさを感じたのは、ResultSetの形で取得したデータをJavaBeanのプロパティに詰め替えるコードを書いていたとき。 以来、 永続化層から取り出したオブジェクトをそのままViewに渡すと期待通りにレンダリングできて、 Viewから取り出したオブジェクトをそのまま永続化層に渡すとDBに書き込んでくれる そういうフレームワークを誰か作らないかなーと寝っころがりながら待っていたのだが、出てこない。 ていうかJavaオブジェクトの永続化手法は2001年時点よりも混乱しているように見える。ポジティブな言い方をすれば百花繚乱である。なぜだろう？ JavaとRDBとのギャップの本質とは何なのだろう。 で、インピーダンスミスマッチ。 ざっと調べると、インピーダンスミスマッチという言葉には、狭義と広義の使われ方があるようだ。 狭義のインピーダンスミスマッチは、 デ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
株式会社スタイルズ
メモリデータベースでコスト削減 | スラド
About the DBBrowser Application