4

データベースを使い始めたばかりで、正規化を member_address エンティティと関連付けるのに問題があります。担当者がいないため写真を投稿できないようですので、テーブルについて説明します。

メンバー (テーブル)
PK Member_ID
FK Member_Zip_Code
FK Membership_Type_code
ATT: First_Name
ATT: Last_name
ATT: Member_Phone
ATT: Member_Email

Member_Address (テーブル)
PK Member_Zip_Code
FK Member_ID
ATT: メンバーの住所
ATT: Member_State
ATT: Member_City

これにアプローチする方法がよくわかりません。データを正しく表示するには 2 つの別個のテーブルが必要だと考えていましたが、ここでは PK と FK が正確に正しくないようです。テーブルを州と都市でいっぱいにするのが最善ですか? または、郵便番号で都市を調べますか? ここでかなり迷った...

4

3 に答える 3

2

http://en.wikipedia.org/wiki/Database_normalizationを見ると、正規化に関する興味深い点がたくさんあります。さまざまな程度の正規化を検討する必要があります。

あなたの場合、いくつかのメンバーがあり、各メンバーにはアドレスがあります。メンバーが持つことができるアドレスは 1 つだけであることは、設計上暗示されています。同様に、あなたのデザインは、メンバーが 1 つの電話と 1 つの電子メール アドレスしか持っていないことを意味します。これはさまざまな方法で処理できますが、まず、次のような方法を検討することをお勧めします。

Member (Table)
MemberID (PK)
MemberAddressID (FK)
MembershipType (FK) -- To a dictionary-table with membership types.
FirstName (ATT)
LastName (ATT)
Phone (ATT) -- (*OR* it could be placed in a separate side-table with phonenumbers)
Email (ATT) -- (*OR* it could also be placed in a separate side-table)

Member_Address (Table)
Member_ID (FK)
Member Address (ATT)
Member_Zip_Code (ATT) -- (*OR* it could be FK to a separate table with Zip-codes, states and cities)
Member_City (ATT)
Member_State (ATT)

WithMember_cityとMember_StateYou は厳密に言えば、第 2 正規形に違反しています。都市と州は郵便番号に暗黙的に含まれていると想定しているためです。Phone と Email をテーブルの属性として保持する場合、設計が複数の電話番号 (自宅/職場/セル) または電子メール アドレスを処理できないため、正規化に違反しています。

多くの場合、そして実用的に、これはいくつかの追加の属性を追加することで解決され、差し迫った問題は解決されますが、正規化の違反は維持されます。クリーン/正しい解決策は、この情報をアドレスと同じように別のサイドテーブルに配置し、FK/PK 関係でそれにリンクすることです。

于 2013-04-07T15:35:32.087 に答える
0

物理モデル (テーブルとインデックス) を直接構築するのではなく、エンティティと関係 (概念設計) の観点から考えることから始めます。あなたは質問で一種のハイブリッドについて説明しています。

次に、各インスタンスを一意に識別する各エンティティの属性を識別します。これは (候補の自然な) 主キーです。エンティティごとに、追加の (候補、自然) 主キーがあるかどうかを判断します。

次に、対応する外部キーを使用して、エンティティ間の各関係を識別します。このような主従関係では、主エンティティの (候補の自然な) 主キーにマップされる詳細エンティティの属性のセットを決定し、この関係の外部キーを構成します。

これで、概念設計の物理モデルのテーブルとインデックスを設計する準備が整いました。

于 2013-04-07T15:27:05.393 に答える