データベースの関係を正しく解決しましたか？

Question

申し訳ありませんが、この質問の場所が間違っています。機密性の高いデータを保存しなければならないチャリティーグループのために私はボランティアを行っています。私たちは新しい形式のフォーマットであり、ニーズや予算に適合するシステムはありません。他の誰かがデータベースを構築し始めたのですが、関係を正しく解決しているかどうかわからないので、代替ERモデルを提示しましたが、今は彼から聞いたことがないので、自分でビルドするようになりました。
私たちは機密データを保存する必要があるので、データベース設計を完全にここに置くことには消極的です。私が個人的にこれを誰かと議論する方法があれば、それは私の好みです。誰かに完全にチェックをして、それがすべて良いかどうかを確認してください...しかし、今のところ、関係を正しく解決したかどうか、または元のデザインが良かったかどうかを誰かが確認できますか？

データベースの説明は次のとおりです。メンバーのさまざまな種類があります -

Client, Staff, Professional (Offsite), Supplier, Family, General. There are different types of Staff members: Managers, Volunteer, Professional (Onsite), Admin, Committee, Lecturer. A member can be one or many types eg: Client/Volunteer/Family, Supplier/Volunteer, Manager/Lecturer/Volunteer/Committee/Family. 

は、元の男が、各テーブルには、名前や住所などを格納し、ユーザーごとに別々のテーブルを作成することによって、これを解決：

Client - ClientName, ClientAddress 
Professional - ProfessionalName, ProfessionalAddress 
Employee - EmployeeName, EmployeeAddress 
Family - FamilyName, FamilyAddress 

私の唯一の問題は、理想的には1人のメンバーに名前と住所を持つ1人のメンバーがいるように思っていますが、元のデザインでは、それぞれの人は、 、住所、電話番号、メールなど

私は、メンバーテーブルを作成し、メンバータイプリストテーブルを結合したメンバータイプテーブルを持つ方がより良い設計になると考えました。

Member Tables

が、私はこれを正しく行っているか、私はオリジナルのデザインを継続すべきである：これは私が問題を解決してきた方法ですか？

おかげ

更新：

Staff Model

Answer 1

これは、1つのテーブル内のすべてのメンバーに関連するデータを格納するために理にかなっています。 プログラミングでは、各メンバータイプごとに異なるテーブルを持つことをサポートするユースケースは想像もできません。

これは非常によく似ているので、私はあなたに「ユーザー役割」の概念を調べることをお勧めします。

あなたは異なるユーザー（メンバー）を持ち、異なる役割（メンバータイプ）を持つことができます。あなたの役割に基づいて、異なるデータを表示したり、異なるアクションを許可したり、特定のメールを送信したりすることができます。

一般的にあなたのアプローチはよく見えます。私が思う唯一のことは、今のところあなたは誰が "スタッフ"メンバーかを記憶していないということです。異なる名前のリストが1つしかない場合は、構造体を保存しません。 あなたのユースケースに応じて、別の列をMemberTypeテーブル "isStaff"にします。また、より柔軟にする必要があり、今後異なるメンバータイプが存在する可能性がある場合は、別のテーブル（例：MemberTypeParent）を作成してMemberTypeテーブルの外部キーをそのテーブルに設定して接続できます。

これは、今後どのようなデータを使用したいかによって決まります。