誰かが次のデータベース設計について確認し、推奨事項を教えてもらえますか？実際のフィールドは無視してください。もっと関係をチェックしたいのですが。ありがとうございました ：）
バックグラウンド
顧客は多くのペットのプロフィールに言うことができます
1人の顧客：多くのペットプロファイルがありますペットプロファイルには1つのタイプがあります（たとえば犬）
犬には多くの属性セットがあります
身長体重
1つの属性セットには多くのペット属性の回答があります。
重量=1kg、2kg、3kg
このシナリオを与える：
顧客が自分のペットを追加します。たとえば犬の場合（ペットの種類から）、そのペットの種類、つまり体重と身長について質問のリストが尋ねられます。ドロップダウンから、彼らは最適なものを選びます。答えを比較する必要があるので、これをフリーテキストにすることはできません。
提案に基づいて更新
それをよく見ると、ペットのタイプまでは理にかなっています。ペットのプロファイルのその部分を作成してみませんか？同じことではないですか？とペットの画像？そうでない理由でペットのプロフィールに含まれている可能性がありますか？次に、代理キーを一意の識別子として使用します。すべてが正規化され、1つの場所にあるため、ペットの属性との相関が少し良くなると思います。3つの別々のテーブルとは対照的です。
基本的に、顧客を1つまたは複数のペットに関連付けます。これは、（petname、pettype、petpic、petattributes、ペットプロファイルへのルックアップの追加、およびペット属性）の組み合わせであるため、特性およびプロファイルで検索できます...
リマインダーについても同じです。そこにリマインダータイプを追加しますか？なぜそれらを分離しておくのですか？情報を取得するためにすべてが言われ、実行されると、多くの結合が必要になります...そしてそれはすべて個別のレベルであるため、何かをロールアップしているわけではありません...まだ