Path: sran265!katsu From: katsu@sran14.sra.co.jp (WATANABE katsuhiro) Message-ID: Date: 11 Nov 92 17:32:44 Organization: Software Research Associates, Inc.,Japan In-reply-to: hokimoto@jaist-east.ac.jp's message of 21 Oct 92 04:28:55 GMT Newsgroups: fj.comp.oops Subject: translation mistakes on OMT book Distribution: fj.comp.oops References: フォローの遅さなら jp で十指に入るであろう渡邊＠ＳＲＡです。 記事 で hokimoto@jaist-east.ac.jp (Akihiro Hokimoto) さんいはく > オブジェクト指向モデリングに関しては、 > RUMBAUGH,他 「オブジェクト指向方法論ＯＭＴ」 トッパン > が比較的良いと思います。 　最近この訳本や原書があちこちでとりざたされているようですね。しかし、 訳本の第１刷には誤訳や誤植あるいは曖昧な表現などが結構あるようです。 　私の周囲で訳本を読んだ人たちの間でも、いくつか問題が指摘されました。 これを集めてみましたので、投稿します。 　単に集めただけで、下の主張の方が正しいという保証はありませんし、 そもそも特別に高い集中力で「検査」を行なったわけでもありません。ですから 正誤表のようには考えないでください。原書をあたって自分で確認することを お勧めします。 　なお、１１月中ぐらいには訳本の第２刷が出るそうで、この第２刷では 下に指摘してある問題点などは基本的にすべて修正されているそうです。 　他にも訳本（第２刷でも）で怪しいところがありましたら、個人的に 興味がありますので、投稿するかメールで知らせていただけると嬉しいです。 -- 渡邊克宏＠ＳＲＡソフトウェア工学研究所 ===== BEGIN ===== オブジェクト指向方法論ＯＭＴの訳（第１刷）の変なところ集 （3,4,5,6,8,9,10,17,20章について） Contributors: mari@sra.co.jp, m-tuchi@sra.co.jp, katsu@sra.co.jp ・複写、引用、再配布等は自由である。 ・-10L などは、最後から１０行目を意味する。 ・集まったコメントを、それが正当なものか検査することなしに、そのまま載せた。 ３章 p30 -1L 意味がよく分からない オブジェクトのとり得るべき状態に関する過度の仕様化は オブジェクトの状態を沢山指定しすぎるのは p31 -2L 誤訳 それは単に方向を定めるための名前である。 方向性があるのは名前の上だけでの話である。 p32 図3.6 本文との対応がとれていない 図中のリンクの名前を「首都をもつ」にするか、 本文の 18L のボールド体の部分を「首都」にすべきである。 p32 -4L 誤訳(common),(find connectivity networks) 共通作業の１つにネットワークの接続性を見つけることがある。 よくある作業として、（もの同士の）接続関係のネットワークを 構成することがある。 p34 -4L 誤訳(designated) エラーメッセージを受け取るコンソールとして設計されたウィンドウ の１つを持つ エラーメッセージを出すためのコンソールとして指定されたウィンドウを １つ持つ p35 16L 誤訳(nonexistent) 非存在行列管理をするより望ましい。 実際にはありえない状況にまで対応するために上司対部下の関係を マトリックス（表）で管理してしまうより望ましい。 p40 3L 誤訳 チームと年の両方が投手の集合を得る必要がある 投手の集合を得るには、チームと年を両方決めなければならない。 p41 12L他（図3.19 も） 誤訳(list) 会社を掲示する。 会社を上場している。 p41 13L他 自然に日本で通用している言葉を使ったほうが……… 銘柄シンボル 銘柄名 p41 -3L 取締役(Drector) 取締役(Director) p42 -3L 日本語の構造が変 関係を表す線分の終端に組立（全体）側を示す小さなダイヤモンド以外は 関係を表す線分の終端の組立（全体）側を示す小さなダイヤモンド以外は ↑ p42 -1L 誤訳（may の解釈） 部品オブジェクトの存在は、それを部分として持つ集約オブジェクトの 存在に依存している。 部品オブジェクトの存在は、それを部分として持つ集約オブジェクトの 存在に依存している場合もある。 これに関連して p43 1L 別の例では部品オブジェクトは、貯蔵庫の機械部品のように独立して 存在している。 倉庫の機械部品のように、部品オブジェクトが独立して存在する場合もある。 p45 のおわりから p46 へかけて、行の欠落や移動等が何箇所かある。例えば ■ P.46 × 1 行目 "図3.24は..." ← 行がずれている ○ 1 行目 "図3.24は..." の１行分を、 11 行目 "作に関する継承を..." の前に移動 p50 -3L 不自然さ(use) useを常に「使用」と訳すのはよくない それにもかかわらず、この単純なモデルはオブジェクトモデル化を 使用する雰囲気を与えてくれる。 それにもかかわらず、この簡単なモデルでもオブジェクトモデルを 構成するやりかたの雰囲気は伝えている。 p50 -3l 誤訳(precise)、誤植 なぜならなら、このモデルはなにかしら正確に表現しているからだ。 なぜならば、このモデルはなにかしら明確な対象（ウィンドウシステム）を 表現しているからだ。 p50 -lL 不自然さ 「したがって」が「なぜならば、………表現しているからだ。」の文を 指しているように読めてわかりにくい。この最後の部分は、例えば 以下のようにしてはどうか？ このモデルはなにかしら明確な対象を表現しているので、細部について 批評することができる。といったように、このモデルを叩き台と することで、より完全なモデルを構築できるであろう。 p51 5L 誤訳 relevance to the solution は the solution に{相対的に,関連して}って ことでは？少なくとも現在の訳では読んで意味が分からない。 (p52 L3 も同様に「適切さ」という訳になっているが、こっちはこれで 意味が通らないでもない。） オブジェクトモデルの内容は問題解決に対する適切さに依存して決まる。 オブジェクトモデルの内容は、解決しようとしている問題に応じて決まる。 p51 13L 誤訳(general) ここの general は special の反対語としてではなく specific の 反対語でしょ。で、「明確でない」ことを表現してるはず ３項関連や多項関連といった一般的な関連は避けるよう ３項関連や多項関連をはっきりした理由もなく使うのは避けるよう p51 -8L 誤訳(document) オブジェクトモデルはそれ自身文書であることと矛盾 常にオブジェクトモデルを文書化する。 常にオブジェクトモデルに説明文書を添えるようにする。 p51 -6L 原書との語調の不整合 should を「義務」として訳したような気がする。 説明を記述することによって、モデル中の名前の意味を明らかにし、 各クラスと関係に対する理由を伝えなければならない。 説明を記述すれば、モデル中の名前の意味が明らかになり、 クラスや関係の存在理由が伝わることとなろう。 ４章 p67 5Lから6L にかけて、文の移動がある。 ■ P.67 × 4.1.3 再帰的集約 ← 行がずれている がある。 ○ がある。 4.1.3. 再帰的集約 p71 -12L 直前の文とのつながり。文の構造がわかりにくい。 規則によって、あるクラスに属するための条件を条件を定義し、 規則によってあるクラスに属するための条件を定義する場合、 p71 -2L 「制約を無効にする」とは、普通制約を取り払うことでは？ その帰属関係の制約を無効にするような その帰属関係からくる制約と矛盾するような p73 -8L 誤訳(all kinds of ... can) 色々な混合規則があるがそれらはどれも、原則として別々の継承パス上で 定義された特性の間の衝突を解決する方法を定義することができる。 別々の継承パス上で定義された特性が衝突する場合があるが、その場合に 特性をどう混合したらいいかという規則は一般に何通りでも考えられる。 p73 -4L 不自然さ(paralell) 並列に定義された特性の衝突はあいまいさを生み出すため、 実行時に解釈されなければならない。 複数の個所で特性が定義されていると意味が曖昧になり、 システムによって適当に解釈されてしまう。 p77 -2L 意図不明確(identity) 同一性とはインスタンスオブジェクトの同一性のことか？もしそうならば、 3.1.4 章での「アイデンティティ」と用語を統一して例えば次のように すべき。 オブジェクトのアイデンティティを厳格に保存し、概念上単一のものを 実現上も単一のインスタンスで表現することが重要かどうか考えよ。 p78 -3L 誤訳("a" system) 技術設計書はシステムを記述している。 技術設計書は１つのシステムを記述している。 あるいは、 技術設計書は具体的な１つのシステムを記述している。 p79 -1L 不明確さ("the" class) クラスのインスタンスに関する そのクラスのインスタンス群に関する p82 -7L 誤訳(functional) 機能的な関係のことである。 関数的な関係のことである。 p83 11L 日本語として不自然、直訳調。 （all kind of の all は「全て」じゃない。could は can じゃない。） 原理的には、さらに多くの構造的制約を表現するために、 特殊なモデル構成要素のすべての種類について、オブジェクトモデル化 技法を飾り立てることも可能である。 実のところ、さらに多くの構造的制約を表現するために沢山の種類の 特殊な記号を持ち込み、モデル化の記法をごてごてしたものにする ことも可能だったのである。 p83 14L 不自然（represents） 表現能力と簡潔性の間の妥協点を表現している。 表現能力と簡潔性の間のはざまで妥協したものなのである。 p83 -12L 誤訳(delimited) 中括弧によって限定され、 中括弧で囲まれ、 p84 7L 誤訳(a function, in turn) 派生オブジェクトは、一個以上のオブジェクトの機能として定義される もので、それらが順番に派生として導出される。 派生オブジェクトは、一個以上のオブジェクトを引数とする関数として 定義される。ここで引数となっていたオブジェクトもまた 派生オブジェクトであってもよい。 p84 -5L 不自然（geometrical) 幾何学的オフセット 位置のオフセット p87 7L 不自然(supress) サブクラスはスーパークラスの属性を抑制したり サブクラスでスーパークラスの属性を隠してしまったり、 ５章のへんなとこ p.108（３行目） ←つまり、第１層の状態または第２層の状態またはもっと先の１つの状態を とらねばならない。 →つまり、下位層の中の第１の状態か、または第２の状態か、または その他の状態のうちのどこかに属さなければならない。 p.113（後ろから１０行目） ←動作状態となる →活性化される p.128 問題 5.8の最後 ←５回の呼出しで電話が最初の呼出し音で応答する場合と、５回の呼出し音の後で 応答する場合を区別せよ。 →最初の呼出し音で電話が応答する呼出し５回分と、５回の呼出し音の後で応答する １回の呼出しを区別せよ。 p.130 問題 5.1 ←交直両用 →汎用 ６章のへんなとこ この本では、６章を含めて specify を「仕様化」と訳しているところが 多数あるが、原書では「仕様」までは意識せずに「明確に述べる」程度の ことしか言っていない部分も多いように思える。そもそも「仕様化する」という 日本語はなくて、「仕様を与える」「仕様記述」のように表現するものだと思う。 逆に「仕様」を強く意識している時には、これを英語で表現すれば、 provide the specifications とか、state the specifications のように techinical term の "specification" を用いることが多いんじゃないだろうか？ p.138 ５行目 ←婚姻状 →配偶者の有無 １６行目 ←機能的な関係 →関数的な関係 p.139 ３行目 ←全体のデータフロー図は上位のプロセスになる。 →データフロー図全体も一つの抽象度の高いプロセスである。 p.140 ２行目 ←上位プロセスは →抽象度の高いプロセスは p.142 最後の文 ←従来のデータフローの記法は、集約として図中で後に使われるオブジェクトの 動的な生成や選択を適切に表現できなかった。 →従来のデータフローの記法は、後で使われるオブジェクトの動的な生成や選択を、 集約のように適切な形では図中に表現できなかった。 p.143 ５行目 ←機能性と →機能および 最後の行 ←経路の判断と →条件判断と p.144 最初の行 ←経路の判断は →条件判断は ２行目 ←こうした判断に預かる機能からの入力値を持たない機能にとっても、 →こうした判断に与る機能から値が入力されることは機能にとってありえないのだが、 それでもなお ４行目 ←判断かかわる →判断にかかわる p.145 後ろから１４行目 ←（これは必ずしも実装する必要はない） →（これは必ずしも属性として実装する必要はない） p.147 ２行目 ←アクターすなわち自分自身の操作を生成するオブジェクト →アクターすなわち自分自身で操作を生成するオブジェクト １７行目などなど。specify をいつでも「仕様」と結び付けるのは無茶 ←仕様化する →しめす。 終りから７行目 ←小さな効果 →小さな影響 p.152 ７行目 ←それらの順序は、順次、繰り返し、分岐選択として →それらの順序は、文の並びや繰り返しや分岐として 終りから１２行目 ←もし同じクラスのオブジェクトが入力と出力であれば、 →もし同じクラスのオブジェクトが入力と出力にあれば、 p.153 終りから１６行目 ←複数のプロセスへの入力データフローのいくつかは、それらのプロセスの 対象となる複数のオブジェクトを表している。 →複数のプロセスへの入力データフローの中には、それら複数のプロセス 全部の対象となっているオブジェクトを表しているものもある。 終りから１２行目 （注）still another = yet another だと思う ←その他の場合でも、データフローは、まだカプセル化されたままのオブジェクトを 表現している。それはあるプロセスで生成され、変更されることなく他のプロセス へと通過していく。 →さらにまた別な場合として、あるプロセスで生成されたオブジェクトが、 変更されることなく他のプロセスへと通過していく時のように、データフローが カプセル化されたままのオブジェクトを表していることもある。 p.154 ２行目 （自信はないが、動的モデルはあるクラスに対して記述され、一方、対応する オブジェクトモデルのクラスでは属性と操作が書き添えられているのだから） ←何が状態を変化させ、操作を受けるのか →何の状態が変化し、何が操作を受けるのか １１行目 ←１つのデータフロー図は１つのプロセスである。 →データフロー図自身が、それで１つのプロセスとなっている。 終りから１３行目 「動作は………操作である。」の後ろに追加 →これは手続きとして実装することができる。 ８章 p163 6L 誤訳(implications) 帰結を分析し 隠された仮定を明らかにし p163 -2L 誤植 明らかする。 明らかにする。 p165 8L 不自然さ 追加的なもの 選択的なもの p165 14L 誤訳(compelling) 特定の計算機や言語を使用しなければならない強い理由が存在するかも しれないが、 特定の計算機や言語を使用するよう強制されることがあるかもしれないが p165 -2L 不自然さ ある要求は、単に間違っている。 要求がまったくの間違いであることもある。 p170 2L 用語の不統一 図 8.5, 8.7 では、Customer は「客」ではなく「顧客」となっている。 p170 18L 誤訳(underspecified) は仕様化されていない については明確に述べられていない p175 -14L 訳語の統一（identify この語が「一つに定める」ことを示す文脈で 用いられている場合５行後で用いられている「同定」が最もふさわしい。 でなければ「特定」でもいいかもしれない。） ある文脈の範囲内でオブジェクトを識別する ある文脈の範囲内でオブジェクトを同定する。 p175 -12L 訳語の統一 ユニークに識別する。 ユニークに同定する。 p177 1L 不自然さ(any) ２つのオブジェクト間の任意の関係を表すには、関連を使用しなさい。 ２つのオブジェクト間の関係を表すには、いつでも関連を使用しなさい。 p178 13L 曖昧さ(subtle -> 微妙 では、注意が必要な重要な問題になるのか、 問題の重大さがごく小さくなるのかわかりにくい。） リンク属性の必要性は、多対１の関連上ではより微妙になる。 多対１の関連上では、リンク属性を用いるべきかがはっきりしなくなる。 p178 15L 不自然（「微妙な問題」という言葉では、非技術的な危険性を感じ過ぎる） リンク属性の必要性は、１対１関連においても微妙な問題である。 同様に、１対１関連でもリンク属性の必要性は把握しにくい。 p182 -5L 誤訳(in addition) クラス人とクラス会社に新たなクラスとなる。 クラス人とクラス会社に加えて、新しいもう１つのクラスとなる。 p183 -7L 訳語の統一(identify) 特定の銀行のカード認証を識別する。 特定の銀行のカード認証を同定する。 p183 -6L 訳語の統一(identify) 対応する１つ以上の口座を識別する。 対応する１つ以上の口座を同定する。 p185 10L 誤訳(among) クラス間の切断点を見つけ出しなさい。 切断点はクラスの中から見つけ出しなさい。 p188 -11L 誤訳（原書の意図を反映していない） 動的モデルは、アプリケーションの制御ロジックを表現するものである。 動的モデルが、アプリケーションの制御ロジックの方を表現する。 p190 -10L 不自然 したがって、 しかしながら、 p196 -11L 改良の提案 （「機能的な依存関係」は、functional model でプロセスを入れ子にしたり、 dynamic model で activity を分解して示すことによって行われることを 想像して意味が分からなかった。プロセスにおける出力の入力に対する 依存関係を意図している "functional dependencies" を、「機能的な 依存関係」と訳すのは不適当と感じた。「入力」と「出力」の対応に 着目してる部分なら、やはり「関数的」となっていた方がわかる気がする） 機能的な依存関係を表すのに有効である。機能は、 関数的な依存関係を表すのに有効である。関数は、 p196 -4L 機能的な依存関係 関数的な依存関係 p199 7L 誤訳(can, may, functions of) （６章では、図がわかりにくくなる等、制御も併せて表現することの 危険性を指摘している。よって、常に有用ではないという原書での 含意をとりはらうべきでない） とはいえ、判断の機能は入力値に基づく複雑な関数なので、 データフローモデル上にこれを表現しておくことは有用である。 とはいえ、判断の機能は入力値に対する複雑な関数になっている場合も あり、データフローモデル上にこれを表現しておくとよいこともある。 p200 1L 誤植 行末の「8.」削除 p200 3L 誤植 行末の「図」削除 p200 4L 不自然さ 全ての場合に何が起こるかを指定することである。 全ての場合について何が起こるかを指定することである。 p200 8L 誤訳(functional) 機能的な依存関係 関数的な依存関係 p202 2L 以降の数行 訳語の統一 図と、本文とで、操作の名前が違っている パスワードを確認する --> パスワード検証 など。 p204 2L 誤訳(define) 議論の範囲を定義する。 議論の範囲を限定する。 p204 7L,8L 訳語の統一(application domain experts) p203 の 6L と統一したほうがよい 業務領域の専門家 -> アプリケーション領域の専門家 p205 11L 誤植 ひとまとめしてしまう ひとまとめにしてしまう ９章 p219 -15L 誤訳(subtle) 微妙な設計エラー 把握しがたい設計エラー p.219 9.2.1 の3行目 現在: どうし 修正後: 同士 言い訳: この部分は平仮名が続くので漢字の方がわかりやすいよ うな気がする。 p220 -6L 誤訳(successively) 連続的に 繰り返し繰り返し p222 2L 不自然さ 物理的に並行な入力はもちろん、別々のセンサーによって 物理的に並行な入力は、もちろん別々のセンサーによって p.222 上から5行目 現在: 問題記述に、オブジェクトが区別されたハードウェア単位 として実装しなければならないと指定されていることが しばしばある。 修正後: 複数のオブジェクトが別々のハードウェア単位に実装さ れなければならない、ということが問題記述に指定されて いる場合がある。 言い訳: この方が意味が正しく伝わるような気がする。 p222 14L 誤訳(until, and, another, ...) （原書との１対１対応より、意味を正しく表現する方が大事と思う。） あるスレッドは、オブジェクトが他のオブジェクトに事象を送るまでは 状態図内に残り、他の事象を待っている。そのスレッドは最後に元の オブジェクトへ戻るまで事象の受け手になる。 スレッドは普段は一つの状態図内にとどまっている。しかし、オブジェクトが 他のオブジェクトへ事象を送って返答の事象を待つようなことが起きると、 スレッドは事象の受け手に引き渡される。そして事象の処理が終わると、 最終的に送り手のオブジェクトへと帰って行く。 p222 -7L 不自然さ 専用の機能単位 専用の機械 p222 -1L 誤訳(connectivity) 接続性 接続関係 p223 1L 誤訳(multiple processor"s") （uni か multi かの選択の節である） マルチプロセッサやハードウェア機能単位を利用するかどうかの決定は マルチプロセッサにしたり、ハードウェアユニットを複数使う構成に するかどうかの決定は p223 8L 誤訳(both ... as well as) ある活動と同期してシステム負荷が突発的に上昇するようなときは、 そのさまざまな組合せによる一時的な影響を考慮に入れるために 見積もりの量を増やすべきである。 負荷の突発的上昇が同時に起きてしまう場合を含めて、さまざまな 負荷の組合せからくる一時的な影響があっても大丈夫なように、 見積もりの量を増やしておくべきである。 p223 14L 誤植(operates) 並行に操作する 並行に動作する p223 15L 不自然さ どのサブシステムがハードウェアまたはソフトウェアで実装されるか 各サブシステムがハードウエアとソフトウェアのどちらで実装されるか p223 16L 不自然さ サブシステムは次の２つの主な理由による場合、ハードウェアで実装される。 サブシステムをハードウエアで実装しようとする理由としては、主に次の ２つがある。 p224 1L 不自然さ ある種のタスクは、 ある種のタスクが、 p224 10L 訳の曖昧さ(independent) 独立したサブシステムは 他と関係しないサブシステムは p226 10L 不自然 DBMS は、実際の問題での利用を複雑にし、ときどき利用を妨げるという 不便さをも持っている。 DBMS にも不便なところはあり、このため現実の問題への適用が複雑に なったり、不可能だったりすることもある。 p226 12L 不自然 一般用途のサービス重視のために 汎用性のために p226 16L 意図不明確 １つの単純トランザクションは関係 DBMS の表の１行を更新する。 トランザクションのうち単純他ものでは、関係 DBMS の表の１行を 更新するだけなのにである。 p227 13L 不自然(allocating) 確保する 割り当てる p228 14L 曖昧さ 多重アドレス空間あるいは呼出しスタックが 多重アドレス空間あるいは多重呼出しスタックが p230 -10L 不自然 他の独立オブジェクトの初期化が 他の独立オブジェクトの初期化より p230 -7L 誤植 開放 解放 p230 -4L 曖昧さ きちんとした障害にに対する見通しを立てる。 障害に対するきちんとした見通しを立てる。 p231 2L 不自然 トレードオフを導く トレードオフを解決する p232 5L 誤訳(have) 持っているのなら 設計しているところなら p.232 9.10.1 の 5,9,11行目 現在: バッチ変換 修正後: 一括変換 言い訳: "batch transformation" の訳が不統一。 p233 図9.2 誤訳(parsing) 「統語解析」ではなく、「構文解析」という定着した訳語を使うべき p.233 図9.2 （データフロー図中のプロセスの名前） 現在: 最適可 修正後: 最適化 p234 9L 不自然さ 与えるために 得るために p236 6L 誤訳 アクターおよび能動的な実世界オブジェクト アクターすなわち能動的な実世界オブジェクト p237 -4L以降 訳語の統一（８章との間で） 銀行協会 銀行コンソーシアム （p238 -4L コメント "little more than" は熟語だと思う。「表現された以上のものではない」 という言い回しは間違ってなさそうだが、あまり滑らかに聞こえない。） p239 10L 意味不明（「いわゆる」） いわゆる複雑な承認プロトコルが要求されるだろう。 複雑な承認プロトコルが要求されるだろう。 p239 18L 曖昧 それは最小の機能性を満たしている。 そこには最小限の機能しかのっていない。 p239 -5L 誤訳 （自分自身のサービスを上の階層に対して提供するのであって、上の階層の サービスを提供するわけではなかろう） その上の階層のサービスのサプライアである。 その上の階層に対してのサービスのサプライアである。 p240 10L 誤植 データストア、 データストアは、 p240 -13L 誤訳(concurrent) 事象駆動や制御の実装は、 事象駆動型や並行型による制御の実装は、 p.241 文献ノート の13行目 現在: フラフィックプロセッサ 修正後: グラフィックプロセッサ p242 11L 不自然 ルールにかなった移動だけをさせるべきであり、 ルールにかなった移動だけをするべきであり、 リジェクトすべきである。 拒否するべきである。 p242 -10L 誤植 セクターでからなる。 セクターとからなる。 p246 9L 誤訳(four function) ４機能の 四則演算用の p248 7L 不自然 データの腐敗である。 データの化けである。 １０章の変なところ p.250 最後から１３行目 ←最構成 →再構成 p.251 最後から１３行目 ←具体的な描画情報は、必要ない後処理プログラム →具体的な描画情報を必要としない後処理プログラム p.252 １１行目 ←最初の事象が動作を引き起こし２番目の事象が、値を返したり →最初の事象が動作を引き起こし、２番目の事象が値を返したり p.252 最後から１４行目 （a composite object から a component を取り出すような場合を指している） ←もしプロセスが入力フローから値を取り込んでいるのならば、 →もしプロセスが入力フローの中から値を取り出しているならば、 p.272 １行目 ←数学的に正しいので、 →まったく正しく、 p.273 ９行目 ←参照したりできる →参照したりすることがある １５行目 ←定義することと →限定することと １７章のへんなところ p.401 最初の行 DB の世界では functional dependency は「関数的従属」と訳すと思う。 ←機能従属性 →関数的従属関係 p.404 １１行目 訳語の統一 ←外部キー →外来キー p.404 １２行目の後ろが、「17.2.4 正規形」の節へ食い込んでしまっている。 p.408 ２０行目 ←すでに割り当てられている ID をたどったり、 →どの ID がすでに割り当てられたものかを管理し、 p.409 最後から３行目 ここは一般的な話じゃなくて、表17.5を説明しているのである。 ←インデックスをつけることで検索を高速化できる。 →インデックスをつけて検索を高速化してある。 最後から２行目 "also" は "map" にかかるのであって、"The SQL" にかかるのではない。 ←SQLレベルにおいても、各定義域をデータ型に写像する。 →各定義域をデータ型に写像するのも、SQLレベルにおいておこなう。 p.413 最後から４行目 ←黒丸の多重度記号は、 →白丸の多重度記号は、 p.414 １４行目 ←３つの各クラスのインスタンスに ID を与えることができ、 →３項関連のインスタンスに ID を与えることができ、 最後から１１行目 訳語の統一 ←探索経路 →ナビゲーションパス （p.415 図7.12 の一番上の図の "Pitcher" の箱は "Person" の箱の間違い だよねえ………原書でも "Pitcher" にはなってるんだけど。） p.420 ６行目 ←多くのクラスの各表の外来キーとして →多重度が多側のクラスの各表の外来キーとして ８行目 ←別のクラスに対する表の中に →どちらかのクラスに対する表の中に p.421 最後から１３行目 ←こうして、先進的な RDBMS は、………システムを提供する。 →したがって、先進的な RDBMS は、………システムを提供すべきである。一般の →RDBMS が閉鎖的なアーキテクチャーをとっているのに対比して、先進的な →RDBMS はオープンアーキテクチャーでなければならない。 p.422 最後から１６行目 ←データベースの構造を表現するのに、最も生産的なパラダイムはどれか。 →データベースの構造の表現するとき、どのパラダイムが最もよく内容を伝えるか。 p.423 最後から４行目 ←DMBS →DBMS ２０章 p472 L23 < 可汎性 > 可搬性 p472 L25 < 電力分配システム > 電力配給システム p474 L13, L17 ・・・ 図20.5 と訳語を統一する。 < パスアイテム > 経路アイテム p477 L17 < メニューアイテムを選択すると、ときどき他のメニューが立ち上がるといった < ことがあった。 > あるメニューアイテムを選ぶことで、ネストした別のメニューが立ち上がるように > なっている場合もある。 p483 L10 < 他のアプローチで起きるコンテキストの変更時に ... 必要となる、という問題を > コンテキストの変更時に ... 必要となる、という他のアプローチで起きる問題を p483 L16 < システムは完全に不用になるまで常に改良が加えられ、それから捨てられる < べきである > システムの改良は、結局捨てなければならないほどぐちゃぐちゃになるまで > 進められてしまうものである。 p483 L19 （"too much of a good thind" = 「ありがためいわく」） < ソフトウエア生産性向上ツールはよいものだが、多数のものを同時に < 使おうとすると問題が生じることがある。 > ソフトウェア生産性向上ツールというのは、ありがた迷惑なこともある。 ===== END =====