000000000
ざわざわ掲示板
[トップに戻る] [留意事項] [ワード検索] [過去ログ] [管理用]
お名前
Eメール
タイトル
メッセージ
参照先
イメージ   [イメージ参照]
暗証キー (英数字で8文字以内)
文字色

無題 投稿者:TY 投稿日:2008/12/01(Mon) 23:09 No.160  
doraemon3.gif 元気か?ざわめきの中の管理人さん?


Re: 無題 888 - 2008/12/01(Mon) 23:20 No.161  

doraemon3.gifはーい


Re: 無題 TY - 2008/12/02(Tue) 23:18 No.162  

doraemon3.gifざわめきの中の管理人さん
仕事のほうはどうだ?
http://www6.plala.or.jp/t7857873y/


Re: 無題 888 - 2008/12/02(Tue) 23:56 No.163  

doraemon3.gifまずまずだよ。
お前さんが書込んだこと、専門の友達に話したらびっくりするだろうな。


Re: 無題 TY - 2008/12/02(Tue) 23:59 No.164  

doraemon3.gif いや何となく懐かしくてな。。


memot 投稿者:memo 投稿日:2008/07/17(Thu) 21:05 No.140  
doraemon3.gifhttp://zawameki.org/pm.txt

┌1 プロジェクトマネージャー論文用_素材集
│ │
│ ├1.1 品質
│ │ │
│ │ ├1.1.1 品質確保のための活動計画
│ │ │ │
│ │ │ ├1.1.1.1 与えられた品質上の目標
│ │ │ │
│ │ │ └1.1.1.2 目標を達成するための活動計画
│ │ │
│ │ ├1.1.2 テスト段階における品質管理
│ │ │ │
│ │ │ ├1.1.2.1 テスト段階で確認した項目、判定基準
│ │ │ │
│ │ │ ├1.1.2.2 原因の分析方法
│ │ │ │
│ │ │ └1.1.2.3 分析に基づいた対策
│ │ │
│ │ ├1.1.3 設計レビュー
│ │ │ │
│ │ │ ├1.1.3.1 重視した評価項目、理由
│ │ │ │
│ │ │ ├1.1.3.2 評価基準と設計レビュー方法
│ │ │ │
│ │ │ └1.1.3.3 レビューによって発見された設計上の問題点
│ │ │
│ │ └1.1.4 請負契約における品質の確認
│ │ │
│ │ ├1.1.4.1 発注した工程の範囲
│ │ │
│ │ └1.1.4.2 期待通りの品質を得るため、品質に関しての確認
│ │
│ ├1.2 コスト
│ │ │
│ │ ├1.2.1 予算超過の防止・費用管理
│ │ │ │
│ │ │ ├1.2.1.1 費用管理の仕組み
│ │ │ │
│ │ │ ├1.2.1.2 予算超過に繋がる兆候とそう判断した理由
│ │ │ │
│ │ │ └1.2.1.3 実施した対策
│ │ │
│ │ ├1.2.2 費用管理(開発側起因)
│ │ │ │
│ │ │ ├1.2.2.1 費用管理上の留意点
│ │ │ │
│ │ │ ├1.2.2.2 開発側に起因する問題
│ │ │ │
│ │ │ └1.2.2.3 実施した施策
│ │ │
│ │ └1.2.3 人件費以外の費用管理
│ │ │
│ │ ├1.2.3.1 プロジェクトの特徴と留意事項
│ │ │
│ │ ├1.2.3.2 工夫した施策(人件費、その他費用)
│ │ │
│ │ └1.2.3.3 評価(人件費、その他費用)
│ │
│ ├1.3 体制
│ │ │
│ │ ├1.3.1 チーム再編成
│ │ │ │
│ │ │ ├1.3.1.1 再編成が必要となった問題
│ │ │ │
│ │ │ ├1.3.1.2 原因分析と再編成の内容
│ │ │ │
│ │ │ └1.3.1.3 編成変更後の管理
│ │ │
│ │ ├1.3.2 連帯意識
│ │ │ │
│ │ │ ├1.3.2.1 メンバ構成
│ │ │ │
│ │ │ ├1.3.2.2 取り組み
│ │ │ │
│ │ │ └1.3.2.3 管理
│ │ │
│ │ ├1.3.3 チームリーダの育成
│ │ │ │
│ │ │ ├1.3.3.1 チームの特徴
│ │ │ │
│ │ │ ├1.3.3.2 特に伸ばそうとしたチームリーダの能力
│ │ │ │
│ │ │ └1.3.3.3 実施した施策
│ │ │
│ │ ├1.3.4 協力会社の選定
│ │ │ │
│ │ │ ├1.3.4.1 請負契約で依頼した内容とその理由
│ │ │ │
│ │ │ ├1.3.4.2 評価基準、評価内容、選定理由
│ │ │ │
│ │ │ └1.3.4.3 評価結果の検証
│ │ │
│ │ ├1.3.5 要員交代
│ │ │ │
│ │ │ ├1.3.5.1 交代となった要員の担当作業
│ │ │ │
│ │ │ ├1.3.5.2 要員交代が発生した際のプロジェクトの問題
│ │ │ │
│ │ │ └1.3.5.3 対応策と要員交代の方法
│ │ │
│ │ ├1.3.6 社外からのチームリーダ採用
│ │ │ │
│ │ │ ├1.3.6.1 チームの役割及び社外リーダ採用の理由
│ │ │ │
│ │ │ ├1.3.6.2 求められた具体的能力と理由
│ │ │ │
│ │ │ └1.3.6.3 確認方法
│ │ │
│ │ └1.3.7 オフショア開発で発生する問題について
│ │ │
│ │ ├1.3.7.1 発生する問題を明らかにするために調査したこと
│ │ │
│ │ ├1.3.7.2 調査結果を分析して明確になった問題
│ │ │
│ │ └1.3.7.3 問題に対して実施した対策
│ │
│ ├1.4 共通コンテンツ・小ネタ
│ │
│ ├1.5 納期
│ │ │
│ │ ├1.5.1 変更要求
│ │ │ │
│ │ │ ├1.5.1.1 開始日を変更できない背景・変更要求
│ │ │ │
│ │ │ ├1.5.1.2 変更要求に対する検討
│ │ │ │
│ │ │ └1.5.1.3 要求に対する結果
│ │ │
│ │ ├1.5.2 プロジェクト計画
│ │ │ │
│ │ │ ├1.5.2.1 制約事項
│ │ │ │
│ │ │ └1.5.2.2 解決策
│ │ │
│ │ ├1.5.3 本格稼動開始の可否
│ │ │ │
│ │ │ ├1.5.3.1 運用投入への判断材料
│ │ │ │
│ │ │ ├1.5.3.2 本稼動を阻む問題
│ │ │ │
│ │ │ └1.5.3.3 対応策
│ │ │
│ │ ├1.5.4 クリティカルパス上の進捗管理
│ │ │ │
│ │ │ ├1.5.4.1 重点的に管理した工程及び理由
│ │ │ │
│ │ │ ├1.5.4.2 兆候の発見のために組み込んだ手続き
│ │ │ │
│ │ │ ├1.5.4.3 兆候に対しての措置
│ │ │ │
│ │ │ └1.5.4.4 進捗遅れに対しての分析と対策
│ │ │
│ │ └1.5.5 業務仕様の変更を考慮したプロジェクトの運営
│ │ │
│ │ ├1.5.5.1 変更があると予測した業務仕様と理由
│ │ │
│ │ ├1.5.5.2 変更に柔軟に対応するための検討事項
│ │ │
│ │ └1.5.5.3 業務仕様の変更に対しての対応
│ │
│ ├1.6 共通コンテンツ・小ネタ
│ │
│ └1.7 その他
│ │
│ ├1.7.1 交渉による問題解決
│ │ │
│ │ ├1.7.1.1 交渉を要した問題と背景
│ │ │
│ │ ├1.7.1.2 問題解決への手順
│ │ │
│ │ └1.7.1.3 双方の主張、説得・譲歩の内容、合意に至った解決策
│ │
│ ├1.7.2 プロジェクトの評価
│ │ │
│ │ ├1.7.2.1 プロジェクト評価における目的と項目
│ │ │
│ │ ├1.7.2.2 評価のために収集したデータ
│ │ │
│ │ └1.7.2.3 データを収集する仕組み
│ │
│ ├1.7.3 ★プロジェクト全体に波及する問題の早期発見
│ │ │
│ │ ├1.7.3.1 立ち上げ時に抱えていた問題
│ │ │
│ │ ├1.7.3.2 想定されたプロジェクトに波及する問題
│ │ │
│ │ └1.7.3.3 問題の兆候を早期に発見した方法とその分析項目
│ │
│ ├1.7.4 開発規模の見積もりに関するリスク
│ │ │
│ │ ├1.7.4.1 見積もりに関して想定したリスク
│ │ │
│ │ ├1.7.4.2 リスクを軽減するために実施した施策
│ │ │
│ │ └1.7.4.3 リスクを管理するために実施した施策
│ │
│ ├1.7.5 問題発生プロジェクトへの新たな参画
│ │ │
│ │ ├1.7.5.1 機能不備や品質不良などの状況
│ │ │
│ │ ├1.7.5.2 問題点の調査と分析
│ │ │
│ │ └1.7.5.3 明確になった原因と実施した対策
│ │
│ ├1.7.6 開発支援ソフトウェアの効果的な使用
│ │ │
│ │ ├1.7.6.1 開発支援ソフトウェアの概要及び特徴
│ │ │
│ │ ├1.7.6.2 ソフトウェアを効果的に活用するための工夫
│ │ │
│ │ └1.7.6.3 プロジェクトの途中での見直し方法
│ │
│ ├1.7.7 重要な関係者とのコミュニケーション
│ │ │
│ │ ├1.7.7.1 プロジェクトの関係者
│ │ │
│ │ ├1.7.7.2 重要と考えた関係者とその理由
│ │ │
│ │ └1.7.7.3 コミュニケーションの内容や方法についての工夫
│ │
│ └1.7.8 プロジェクトの機密管理
│ │
│ ├1.7.8.1 機密として管理した情報の理由や機密度
│ │
│ ├1.7.8.2 機密管理のルール、ルールに従って運用するための日常管理
│ │
│ └1.7.8.3 漏洩時の影響を少なくする対策

├2 共通コンテンツ・小ネタ

├3 論文準備対象のテーマ

├4 【事前準備】プロジェクト・組織概要

└5 事前準備題材でとにかく書いてみる


無題 memoa - 2008/07/17(Thu) 21:07 No.141  

doraemon3.giftest

・どんなにその人を愛していても、その人のために全てを犠牲にしてはならない。
なぜなら、必ず後で、その人を憎むようになるからだ。
by曽野綾子


愛欲より憂いを生じ、愛欲よりおそれを生ず。愛欲を離れたる人に憂いなし
仏教聖典  大乗経典8巻の0つ
「法句経(ダムマパーダ)」より


水前寺清子

さわやかに恋をして 
さわやかに傷ついて 
さわやかに泣こう

さわやかに夢を見て 
さわやかにあきらめて 
ただ一人泣こう



離れればいくら親しくってもそれきりになる代わりに、いっしょにいさえすれば、たとい敵(かたき)同志でも
どうにかこうにかなるものだ。つまりそれが人間なんだろう。 夏目漱石『道草』


Re: memot memo2 - 2008/08/30(Sat) 22:33 No.145  

doraemon3.gif少年時代から王宮を出て征旅を行い、ノルウェーのニーベルンゲン族を倒してその財宝と魔法の隠れ蓑、名剣バルムンクを奪う、悪竜を倒すなど、多くの軍功を立てる。この悪竜退治の際、魔力のこもった竜血を浴びて全身が甲羅のように硬くなり、いかなる武器も受け付けない不死身の体となる。しかしこの時、背中に菩提樹の葉が一枚貼り付いていて血を浴びられず、この一点のみが彼の弱点となった。


Re: memot4 memo25 - 2008/09/29(Mon) 17:47 No.148  

doraemon3.gifちぇ
PSあいらぶゆー
まんまみーあ
ベンジャミン・バトン


testt 投稿者:test 投稿日:2008/02/15(Fri) 19:26 No.121  
doraemon3.gifmemoa


memo12/13 memo - 2008/02/15(Fri) 19:30 No.122  

doraemon3.gifCREATE TABLE テーブル名
(列名 データ型 NOT NULLなど,
 列名2 データ型 NOT NULLなど,
 列名3 データ型 NOT NULLなど,
 列名4 データ型 NOT NULLなど,
constraint 制約名 PRIMARY KEY (列名、列名2、列名3),
constraint 制約名 FOREIGN KEY (列名、列名2)
 references 参照先テーブル (列名、列名2) ON DELETE CASCADE)

grant select on TABLE/VIEW to public

外部キーを設定するときは、参照先の主キーが同じ性質、ドメインを持つことを確認。

外部キーとして参照されるのは、参照先のテーブルの主キーであるため
主キーが決定できたり、外部キーが決定できたりする。

繰り返し部分を縦持ち化させるために連結する際、繰り返し部分のみで一意になる属性がある場合は、通番を利用する。
通番的な情報を利用するのにテーブルには通版がない場合は、SQLが複雑になるので通版を利用
通番のノウハウについては以下追記。



ある情報を一箇所管理していない場合に、その情報との関連・履歴を、一つのテーブルで管理する手法として自己参照が利用できる

一つ通番を追加することで、2つの情報の保存から、二つ以上の情報の保存として大幅に拡張できる。
(主)注意事項・副作用番号、注意事・項副作用など、薬番号1、薬番号2
においては二つの薬の間の副作用しか管理できないが、通版を主キーに組み込むことで、3つ以上可。
薬番組を主キーとし、副作用番号を冗長に持たせられるようにしても可。

権限の粒度が細かすぎると、異動の際などに発生する作業量が増える。
権限の変更可能性よりも上記を意識するべき。

データ移行の再利用するテーブルとしては、元データ主キー→移行後データ一意に、というようなテーブルを。

同一情報を履歴として数年残す、かつそのデータをリアル年月で更新してゆく場合
エントリー用のテーブルを作成し、パッチ処理で履歴テーブルに移行させることによって
インデックス更新を避けられる。

修正データの保存の為に、修正テーブルを持つ。また、その場合内部に後先区分を持つことで修正前、修正後データを保存できる。変更区分は主キーの一部となる

変更年月日を持たせ、主キーに組み込むか
通番を主キーに組み込み、年月日は属性にするか
開始、終了年月日を持たせ、開始を主キーに組み込むか。

(主)組み合わせ番号、適用年月日、サービスポイント
(主)組み合わせ番号、(主)品目コード
適用年月日を主キーに組み込むためには別テーブルとする必要がある。
ポイントは主キーより一意に従属し、品目コードは複数従属することを念頭におき、同じ性質の属性があれば、まとめる。

サブタイプは複数のスーパータイプとサブタイプ関係を結ぶことがある。

出庫・入庫のように、性質が似たテーブル構造が既存である場合は、構造を参考にすること。
スーパータイプに共通属性を持たせることを意識しすぎず、年月日などはサブタイプ独自に持たせる可能性がある。
また必ず識別子としての区分をスーパータイプに持たせるかどうか意識。



http://homepage1.nifty.com/samito/prepositions.htm


Re: testt memo - 2008/02/20(Wed) 19:38 No.124  

doraemon3.gifCHECK() はNOT EXISTを利用し、条件文は違反の条件を記述する。


通番の利用法として、予約者カナ氏名などを主キーの一部に設定し得るとき
属性の一意性が、属性そのものの性質によって保証されない場合
通番を利用することが有効。
カナ氏名は同姓同名で重複するため。


希望客室・代替客室の予約管理テーブルなどに、残高情報などを持たせる必要があるかどうか、きちんともらさず考察する。


査定日など、~日という属性を見て、時系列性を意識する。
同じ車体であったり、その製品固有の識別子で特定できる属性と
特定のために時系列性も主キーに含める必要があるかどうか。
例えば車の走行距離は、査定日が異なると、同じ車でも異なる。平成19年午後1問1、重要な着眼点。

区分属性が必要か不必要かの判断。既存属性である状態の区分が正常に出来るかどうか。


何が何でも開始終了年月や期間を併記したテーブルを作って時系列管理するのではなく
対象のトランザクションテーブルに該当の属性を含ませることでも
時系列管理は可能。


Re: testt memo - 2008/03/05(Wed) 19:58 No.127  

vin.gif売り上げ見込み表を時系列管理するために、更新年月、更新年期などを保持するかどうか
テーブル設計時に注意

案件分割などが発生する際、自己参照などによって、分割前後を対応付けるかどうか
属性は元案件番号を持ち、データモデルにも自今参照を。


図表に繰り返し項目として、例えばスキルごとに複数タプルのスキルレベルという項目があったとしても
実際にデータとして選択されるのが特定の一項目だった場合は、主キーに含めない。
図上では繰り返し項目だからといって、安易に候補キーに組み入れない。

外部キーとして参照する場合は、候補キーの組み合わせ単位ということを忘れずに

書き出しのSQLのFROMにて複数のテーブルを参照する場合、かつ左外部結合を利用する場合には、FROM欄の右端に持ってくるテーブル名に留意する。
穴埋めの場合でかつON部分が記述されている場合、その条件式に利用されているテーブルをみれば、特定可能。

2段以上のexist述語は、2段目である対象の属性の全ての組み合わせについてそれぞれ真偽判定する。
1段目のexist述語で、始めのselect文の対象について、2段目のexist述語の結果を"まとまり"、として真偽判定する。
これによって、全ての販促対象品を購入した会員、などを抽出する。

複数エンティティタイプが必要な場合かつ、回答が単一のエンティティを要求している場合
自己参照の可能性を意識する。
手詰まりになって悩む前に、そのような再帰的な構造になる可能性を、とにかく意識する。

業務要件に合わせて3パターンほどのデータモデルを検討するタイプの問題の場合。
まず、リレーションシップ先に元の主キーを持たせるという基本事実は変わらないので抑える。(1対1の場合はどちらに持たせるか記載あるはず)
持たせた側に着目し、主キーを、参照先からもって来た外部キー単位に分割するというイメージを持つ。
すなわち、主キーが細かいテーブル側に外部キーをもたせて参照させたパターンのほうが、細かいタプルを持ち
それが結果として履歴保持の可能を意味する場合がある。
連関テーブルを作るパターンは、互いが互いに分割可能というイメージを持つ。
お互いの主キーの共通していない部分単位に。


Re: testt memo - 2008/03/16(Sun) 19:59 No.128  

doraemon3.gif分析に利用する情報系テーブルでは求められる粒度の集計単位より上位の階層を示す属性(店舗コードだけでなくエリアコードも)も保持し、あえて非正規化する。

実績金額等は、何ごとの金額なのか。集計単位を明確にして捉える。

カレンダなどはどういった階層構造になっているのか、年なのか年度なのか確認する。

たな卸し等で、実績調査段階と集計段階にて時間差が生じることで実数に差異があり
かつ、たな卸しの結果を実数データに反映させるような処理をする場合
単純に集計後、たな卸し結果の数値を実数データにコピー出来ない。
その場合はたな卸しデータに差異を保持し、集計後演算する。

拠点内の部品移動など、対応する出庫を参照で要る入庫などでも基本的に実数はテーブルに保持する。

変更、削除の処理について、3種類のデータもしくはそれ以上を保持し、処理をするのか
最新のデータのみ、1種類を保持し、それを常に最新のデータに保つことで変更、削除処理を行うのか
DB的にどうなのかを意識する。

連関テーブルに持たせる属性として、履歴管理のための期間保持についても考慮する。

集計テーブルのリレーションの設定の仕方。

効率が悪い、などの問題を改善する際、対象の処理が期間を割り出す物であり、かつ割り出すのに利用するテーブルが単一年月日しか保持してなければ
期間保持によって効率を上げられるかのうせいがあることを考慮

外部参照されるのは対象の主キー。リレーションと外部キーがあれば、それによって主キーを特定できる。

~別という言葉に敏感に。

通常派遣依頼と延長派遣依頼、出庫入庫など、処理が関連するテーブルがある場合は必ず確認し、共通して持たせる属性があるかどうかを見ること。
新たに延長派遣依頼を設計する場合に、問題文に明文されていなくとも、通常派遣依頼にあった依頼日をもたせる、など。


memo memo - 2008/03/20(Thu) 17:51 No.129  

doraemon3.gifある外部キーに対してリレーションを持つか持たないかの判断。
時系列性の保持のための追加であればリレーションは必要だが
非正規化のために保持しているのであれば
関連を辿って得ることのみで目的は達せられるため、あえてリレーションを持たせない。

H12は要再チェック。
属性値の変換について。
変換テーブルの意義としては、元を主キーにして、先の属性を持たすテーブルを作成。
値が一致すればそのまま移行すればよく、変換に処理が必要な物はアプリケーション側で実施するため、それらは含めない。


修正した勤務データのみ表示、などの要件を求める処理がある場合は、区分を利用。

変更による差分データを受け渡せるようにするためにDB側で出来る事は差分データをテーブルとして持つことだが
受け渡し先のシステムの仕様がはっきりしない場合は、単純に変更前データと変更後データを持つようにする。
その場合、変更区分を持ち主キーに組み入れることによって、元からの主キー単位からさらに2分割する。

横持ちがあるテーブルを拡張性の追加やSQLを簡単にするために縦持ちにする際、そのまま記述エンティティにならず、繰り返し属性が特定のキーだけで一意に特定できる場合がある。
この場合、通番などをもたせ、記述エンティティ化する。


Re: testt memo - 2008/03/25(Tue) 18:50 No.130  

doraemon3.gifAによって、Bを特定できる。
場合、つまり、BはAのキーを外部キーとして持ち、多側になると判別出来る可能性がある。

問われる単位に気をつける。
受注単位に問われる場合で、受注が複数の出荷に分割される場合、その全ての出荷が特定のケースになることで、初めて受注に影響を与える場合がある。
出荷単位に焦点を当てて回答すると、求められた回答を提示できない。

空き室数なども、主キーが3つあるとすれば、3つの軸で個別に設定されるということなので
主キーごとに集計しないと、実際のタプルの空き室数は得られないことをちゃんと頭にいれておく。

第3正規系でないことを答えさせる問いで、部分関数従属と、推移的関数従属性を同時に持たせたテーブルを指定される場合がある。
その場合は問題文の定義をきちんと考慮し、どちらか適切な要素を選択し、不具合を答えたり、正規分割しないといけない。


通番を入れて、主キーの粒度を高める手法に再度留意

その主キーごとに何が決定するのか。一意に決定するのか、複数決定するのか。
作成したテーブルを前にこの基本事項をきちんと確認すること。
単一の例でいいから、実際必要なタプルは何かも想像すること。

藤原カムイ

| 1 | 2 | 3 | 4 |

NO: PASS:

- KENT & MakiMaki - antispam edition -