| testt 投稿者：test 投稿日：2008/02/15(Fri) 19:26 No.121 | |
|
 | memoa |
| memo12/13 memo - 2008/02/15(Fri) 19:30 No.122 | |
|
|
| CREATE 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つの情報の保存から、二つ以上の情報の保存として大幅に拡張できる。
（主）注意事項・副作用番号、注意事・項副作用など、薬番号１、薬番号２
においては二つの薬の間の副作用しか管理できないが、通版を主キーに組み込むことで、3つ以上可。
薬番組を主キーとし、副作用番号を冗長に持たせられるようにしても可。
権限の粒度が細かすぎると、異動の際などに発生する作業量が増える。
権限の変更可能性よりも上記を意識するべき。
データ移行の再利用するテーブルとしては、元データ主キー→移行後データ一意に、というようなテーブルを。
同一情報を履歴として数年残す、かつそのデータをリアル年月で更新してゆく場合
エントリー用のテーブルを作成し、パッチ処理で履歴テーブルに移行させることによって
インデックス更新を避けられる。
修正データの保存の為に、修正テーブルを持つ。また、その場合内部に後先区分を持つことで修正前、修正後データを保存できる。変更区分は主キーの一部となる
変更年月日を持たせ、主キーに組み込むか
通番を主キーに組み込み、年月日は属性にするか
開始、終了年月日を持たせ、開始を主キーに組み込むか。
（主）組み合わせ番号、適用年月日、サービスポイント
（主）組み合わせ番号、（主）品目コード
適用年月日を主キーに組み込むためには別テーブルとする必要がある。
ポイントは主キーより一意に従属し、品目コードは複数従属することを念頭におき、同じ性質の属性があれば、まとめる。
サブタイプは複数のスーパータイプとサブタイプ関係を結ぶことがある。
出庫・入庫のように、性質が似たテーブル構造が既存である場合は、構造を参考にすること。
スーパータイプに共通属性を持たせることを意識しすぎず、年月日などはサブタイプ独自に持たせる可能性がある。
また必ず識別子としての区分をスーパータイプに持たせるかどうか意識。
http://homepage1.nifty.com/samito/prepositions.htm |
| Re: testt memo - 2008/02/20(Wed) 19:38 No.124 | |
|
|
| CHECK() はNOT EXISTを利用し、条件文は違反の条件を記述する。
通番の利用法として、予約者カナ氏名などを主キーの一部に設定し得るとき
属性の一意性が、属性そのものの性質によって保証されない場合
通番を利用することが有効。
カナ氏名は同姓同名で重複するため。
希望客室・代替客室の予約管理テーブルなどに、残高情報などを持たせる必要があるかどうか、きちんともらさず考察する。
査定日など、～日という属性を見て、時系列性を意識する。
同じ車体であったり、その製品固有の識別子で特定できる属性と
特定のために時系列性も主キーに含める必要があるかどうか。
例えば車の走行距離は、査定日が異なると、同じ車でも異なる。平成19年午後1問1、重要な着眼点。
区分属性が必要か不必要かの判断。既存属性である状態の区分が正常に出来るかどうか。
何が何でも開始終了年月や期間を併記したテーブルを作って時系列管理するのではなく
対象のトランザクションテーブルに該当の属性を含ませることでも
時系列管理は可能。 |
| Re: testt memo - 2008/03/05(Wed) 19:58 No.127 | |
|
|
 | 売り上げ見込み表を時系列管理するために、更新年月、更新年期などを保持するかどうか
テーブル設計時に注意
案件分割などが発生する際、自己参照などによって、分割前後を対応付けるかどうか
属性は元案件番号を持ち、データモデルにも自今参照を。
図表に繰り返し項目として、例えばスキルごとに複数タプルのスキルレベルという項目があったとしても
実際にデータとして選択されるのが特定の一項目だった場合は、主キーに含めない。
図上では繰り返し項目だからといって、安易に候補キーに組み入れない。
外部キーとして参照する場合は、候補キーの組み合わせ単位ということを忘れずに
書き出しの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 | |
|
|
| 分析に利用する情報系テーブルでは求められる粒度の集計単位より上位の階層を示す属性（店舗コードだけでなくエリアコードも）も保持し、あえて非正規化する。
実績金額等は、何ごとの金額なのか。集計単位を明確にして捉える。
カレンダなどはどういった階層構造になっているのか、年なのか年度なのか確認する。
たな卸し等で、実績調査段階と集計段階にて時間差が生じることで実数に差異があり
かつ、たな卸しの結果を実数データに反映させるような処理をする場合
単純に集計後、たな卸し結果の数値を実数データにコピー出来ない。
その場合はたな卸しデータに差異を保持し、集計後演算する。
拠点内の部品移動など、対応する出庫を参照で要る入庫などでも基本的に実数はテーブルに保持する。
変更、削除の処理について、3種類のデータもしくはそれ以上を保持し、処理をするのか
最新のデータのみ、1種類を保持し、それを常に最新のデータに保つことで変更、削除処理を行うのか
DB的にどうなのかを意識する。
連関テーブルに持たせる属性として、履歴管理のための期間保持についても考慮する。
集計テーブルのリレーションの設定の仕方。
効率が悪い、などの問題を改善する際、対象の処理が期間を割り出す物であり、かつ割り出すのに利用するテーブルが単一年月日しか保持してなければ
期間保持によって効率を上げられるかのうせいがあることを考慮
外部参照されるのは対象の主キー。リレーションと外部キーがあれば、それによって主キーを特定できる。
～別という言葉に敏感に。
通常派遣依頼と延長派遣依頼、出庫入庫など、処理が関連するテーブルがある場合は必ず確認し、共通して持たせる属性があるかどうかを見ること。
新たに延長派遣依頼を設計する場合に、問題文に明文されていなくとも、通常派遣依頼にあった依頼日をもたせる、など。 |
| memo memo - 2008/03/20(Thu) 17:51 No.129 | |
|
|
| ある外部キーに対してリレーションを持つか持たないかの判断。
時系列性の保持のための追加であればリレーションは必要だが
非正規化のために保持しているのであれば
関連を辿って得ることのみで目的は達せられるため、あえてリレーションを持たせない。
H12は要再チェック。
属性値の変換について。
変換テーブルの意義としては、元を主キーにして、先の属性を持たすテーブルを作成。
値が一致すればそのまま移行すればよく、変換に処理が必要な物はアプリケーション側で実施するため、それらは含めない。
修正した勤務データのみ表示、などの要件を求める処理がある場合は、区分を利用。
変更による差分データを受け渡せるようにするためにDB側で出来る事は差分データをテーブルとして持つことだが
受け渡し先のシステムの仕様がはっきりしない場合は、単純に変更前データと変更後データを持つようにする。
その場合、変更区分を持ち主キーに組み入れることによって、元からの主キー単位からさらに2分割する。
横持ちがあるテーブルを拡張性の追加やSQLを簡単にするために縦持ちにする際、そのまま記述エンティティにならず、繰り返し属性が特定のキーだけで一意に特定できる場合がある。
この場合、通番などをもたせ、記述エンティティ化する。 |
| Re: testt memo - 2008/03/25(Tue) 18:50 No.130 | |
|
|
| Aによって、Bを特定できる。
場合、つまり、BはAのキーを外部キーとして持ち、多側になると判別出来る可能性がある。
問われる単位に気をつける。
受注単位に問われる場合で、受注が複数の出荷に分割される場合、その全ての出荷が特定のケースになることで、初めて受注に影響を与える場合がある。
出荷単位に焦点を当てて回答すると、求められた回答を提示できない。
空き室数なども、主キーが３つあるとすれば、3つの軸で個別に設定されるということなので
主キーごとに集計しないと、実際のタプルの空き室数は得られないことをちゃんと頭にいれておく。
第3正規系でないことを答えさせる問いで、部分関数従属と、推移的関数従属性を同時に持たせたテーブルを指定される場合がある。
その場合は問題文の定義をきちんと考慮し、どちらか適切な要素を選択し、不具合を答えたり、正規分割しないといけない。
通番を入れて、主キーの粒度を高める手法に再度留意
その主キーごとに何が決定するのか。一意に決定するのか、複数決定するのか。
作成したテーブルを前にこの基本事項をきちんと確認すること。
単一の例でいいから、実際必要なタプルは何かも想像すること。
藤原カムイ
|
|
