0

基本的に、私のグループと私は 3NF までのユーザー ビューの正規化を作成する必要があります。現在、すべてのユーザー ビューはセネカ カレッジ デイケア用です。合計で 5 つのユーザー ビューがあり、それぞれが多くのことに関係していますが、主にユーザー ビュー 1 です。 -4 は子、親、およびワーカーに関するもので、userview 5 は支払いフォームです。

例: ユーザービュー 1

        CHILDREN
NAME    OHIP#      DATE OF BIRTH       ALLERGY(S)   TYLENOL PERMITTED
Kevin   5334447772  Nov 2, 1999    Penicillin, Egg      Yes
Mary    4333445355  Sept 4, 1997    Egg                 Yes

私たちの 3NF は (私のパートナーがしたこと) に行き着きました

フォーム [ F_ID, Campus, Sign, DateP]

登録 [ R_ID, L_Name, F_Name, Relation, Apt, PosC, Hphone, Wphone, E_Call, OHIP]

Addr [PosC、住所、都市]

FormReg [F_ID、R_ID、日付]

RegOAA [R_ID、OAA_ID、関係]

OAA [OAA_ID、F_Name、L_Name、HPhone、WPhone]

子供[OHIP、L_Name、F_Name、誕生、アレルギー、タイレノール]

ユーザービュー 2

http://i.imgur.com/4yEkqvZ.jpg?1 (詳細が多すぎてここに貼り付けられないので、prnt scrn をアップロードしました)

今私が降りてきた3nfは

3NF
ChildDetail [Campus, Child#, ChildName, ChildBday, Allergy]
Manager [Manager#, Manager]
Supervisor [Supervisor#, Supervisor]
Worker [ChildWrkrs#, ChildWrkrs]
Family [Fam#, FamPhone#]

ただし、私のパートナーは、Userview 1 から思いついた OHIP プライマリ キーを引き続き使用する必要があると言っています。

そして彼はこれを思いついた

StaffAssign [キャンパス、Manager_ID、L_Name、F_Name]

部屋 [RoomNum, RDescript]

Room_Staff [キャンパス、RoomNum、Staff_ID、OHIP]

スタッフ [Staff_ID, L_Name, F_Name, Occupation]

子供[OHIP、L_Name、F_Name、アレルギー、出生、F_ID、E_Call]

さて、私の理解では、私の理解が正しければ、ユーザービューに存在しない属性を使用することはできませんよね? userview 1 から OHIP を取得し、それを userview 2 に追加しても機能しないはずです。

私たちはそれについて行ったり来たりしていましたが、残念ながら私たちの教授と連絡が取れていないので、誰かがここで助けてくれることを願っていました.

ありがとうございました。

4

1 に答える 1

0

ということで、条件さえ満たせば可能だということがわかりました。

異なるユーザービューの属性がある場合、主キーが同じである限り、それらを結合できます。これが累積設計になります。

そのような条件の例は次のとおりです。

1ST USER VIEW – OLD CUMULATIVE DESIGN

Part[Part#, description, unit_price, qty_on_hand]
Order_part[Order#, part#, sold_quantity, sold_price]
FK  order#  order
FK  part#  part

ORDER[order#, ordDate, cust#]
FK  cust#  customer
CUSTOMER[Cust#,  cName]

NEW CUMULATIVE DESIGN

PART[Part#, description, class, price, qty_on_hand]
CLASS[Class, class_desc]
ORDER_PART[ Part#, order#, quantity,  quotedPrice]
ORDER[ ord#,  ordDate, cust#]  
CUSTOMER[cust#, cName, street, city, zip, prov, country, balance, creditLimit, rep#]
REP [Rep#, rName, com_perct]

例でわかるように、PART フィールドには同じデータがありますが、新しいデザインでは、追加された条件として「クラス」が表示されます。これは問題ありません。追加のユーザービューでは、Parts テーブルに「クラス」として定義された追加の属性があり、主キーは変更されていないため、古い設計と見つかった新しい情報をマージして作成しただけです。新しい累積設計。

したがって、条件が満たされている限り、以前のユーザービューから別のユーザービューへの属性の「転送/使用」またはむしろマージを行うことができます (それらが関連しており、主キーが同じである限り)。

編集 また、メモを作成するために、ユーザービューに存在しない場合でも、独自の属性を作成することもできます。

その例として、フォームに記入する場合、使用する基準はたくさんありますが、そのフォームは多くの場所に送信でき、そこに登録している限り各場所を使用でき、属性を作成できますこれにより、例として「registration_id」などの各フォームを追跡できます。

于 2013-10-23T23:25:13.507 に答える