テーブル•名前
最近学んだ単数形は正しい
はい。異教徒に注意してください。表の名前が複数あるのは、標準的な資料をまったく読んでおらず、データベース理論の知識もない人の確かな兆候です。
標準に関するすばらしい点のいくつかは次のとおりです。
- それらはすべて互いに統合されています
- 彼らは一緒に働く
- それらは私たちよりも優れた心によって書かれたので、私たちはそれらについて議論する必要はありません。
標準のテーブル名は、テーブルのすべての内容ではなく、すべての表現で使用されるテーブルの各行を指します（CustomerテーブルにはすべてのCustomersが含まれていることがわかります）。
関係、動詞句
モデル化された本物のリレーショナルデータベース（1970年以前のレコードファイリングシステム（Record IDsこれは、便宜上SQLデータベースコンテナーに実装されることで特徴付けられる）とは対照的）では、次のようになります。
- テーブルはデータベースの主語であり、したがって名詞であり、単数形です。
- テーブル間の関係は、名詞間で実行されるアクションであり、したがって動詞です（つまり、それらには任意の番号または名前が付けられていません）。
- それは、ある述語
- データモデルから直接読み取ることができるすべて（最後にある私の例を参照）
- （独立したテーブル（階層の最上位の親）の述語は、独立しているということです）
- したがって、動詞句は慎重に選択されているため、最も意味があり、一般的な用語は避けられます（これは経験とともに簡単になります）。動詞句は、モデルの解決に役立つため、モデリング中に重要です。関係の明確化、エラーの特定、テーブル名の修正。
ダイアグラム_A
もちろん、リレーションシップはSQLでは子CONSTRAINT FOREIGN KEYテーブルとして実装されます（詳細は後で）。以下は、動詞句（モデル内）、それが表す述語（モデルから読み取られる）、およびFK 制約名です。
Initiates
Each Customer Initiates 0-to-n SalesOrders
Customer_Initiates_SalesOrder_fk
テーブル•言語
ただし、特に述語やその他のドキュメントなどの技術言語で表を説明する場合は、自然に英語で使用される単数形と複数形を使用します。テーブルは単一の行（リレーション）の名前が付けられ、言語は各派生行（派生リレーション）を参照することに注意してください。
Each Customer initiates zero-to-many SalesOrders
ない
Customers have zero-to-many SalesOrders
したがって、「user」というテーブルを取得して、そのユーザーだけが持つ製品を取得した場合、テーブルの名前を「user-product」または単に「product」にする必要がありますか？これは1対多の関係です。
（これは命名規則の問題ではありません。これはdb設計の問題です。）user::product1 :: n かどうかは関係ありません。重要なのはproduct、独立したエンティティであるかどうか、およびそれが独立したテーブルであるかどうかです。それはそれ自体で存在することができます。したがってproduct、ではないuser_product。
とproductのコンテキストでのみ存在する場合user、すなわち。したがって、これは従属テーブルですuser_product。
図_B
さらに、（何らかの理由で）各製品についていくつかの製品の説明がある場合、それは「user-product-description」または「product-description」または単に「description」でしょうか？もちろん、正しい外部キーが設定されている場合。ユーザーの説明やアカウントの説明などがあるため、説明に名前を付けるだけでも問題があります。
そのとおり。上記に基づいて、user_product_descriptionxorのどちらかproduct_descriptionが正しくなります。それは他のものと区別することではありませんがxxxx_descriptions、名前にそれがどこに属しているかの感覚を与えることです、接頭辞は親テーブルです。
列が2つだけの純粋なリレーショナルテーブル（多対多）が必要な場合はどうなりますか？「ユーザーのもの」または「rel-user-stuff」のようなものですか？そして、最初の場合、たとえば「user-product」とこれを何が区別しますか？
リレーショナルデータベースのすべてのテーブルが、純粋なリレーショナル正規化テーブルであることを願っています。名前でそれを識別する必要はありません（そうでない場合、すべてのテーブルはになりますrel_something）。
2つの親のPK（論理レベルでエンティティとして存在しない論理 n :: n関係を物理テーブルに解決する）のみが含まれている場合、これは連想テーブルです。はい、通常、名前は2つの親テーブル名の組み合わせです。
最終的に2つのuser_productテーブルになる場合、それはデータを正規化していない非常に大きな信号です。したがって、いくつかの手順に戻ってそれを行い、テーブルに正確かつ一貫した名前を付けます。その後、名前は自動的に解決されます。
命名規則
どんな助けも高く評価されます。皆さんがお勧めする命名規則の標準がある場合は、自由にリンクしてください。
あなたがやっていることは非常に重要であり、それはあらゆるレベルでの使いやすさと理解に影響を与えます。ですから、最初からできるだけ多くのことを理解しておくのは良いことです。SQLでコーディングを開始するまで、このほとんどの関連性は明確になりません。
ケースは最初に取り上げる項目です。すべての大文字は受け入れられません。特にユーザーがテーブルに直接アクセスできる場合は、大文字と小文字が混在するのは正常です。データモデルを参照してください。シーカーが小文字の修飾されたNonSQLを使用している場合は、それを与えることに注意してください。その場合、アンダースコアを含めます（例に従って）。
アプリケーションや使用法の焦点ではなく、データの焦点を維持します。それは、2011年以来、1984年以来オープンアーキテクチャを導入しており、データベースは、それらを使用するアプリから独立しているはずです。
このようにして、それらが成長し、1つのアプリがそれらを使用する以上に、ネーミングは意味のあるままであり、修正する必要はありません。（1つのアプリに完全に埋め込まれているデータベースはデータベースではありません。）データ要素にはデータのみの名前を付けます。
非常に配慮し、テーブルと列に非常に正確な名前を付けます。データ型のUpdatedDate場合は使用せず、を使用してください。投与量が含まれている場合は使用しないでください。DATETIMEUpdatedDtm_description
データベース全体で一貫性を保つことが重要です。NumProduct1つの場所で製品の数を示しItemNoたりItemNum、別の場所で製品の数を示したりしないでください。一貫してNumSomething、numbers-of、および、SomethingNoまたはSomethingIdidentifierに使用します。
列名の前にテーブル名やのような短いコードを付けないでくださいuser_first_name。SQLはすでに修飾子としてテーブル名を提供しています：
table_name.column_name -- notice the dot
例外：
最初の例外はPKです。PKは常に結合でコーディングし、データ列からキーを目立たせたいため、特別な処理が必要です。常に使用しuser_id、絶対に使用しないでくださいid。
- これがあることに注意していない接頭辞として使用されるテーブル名が、キーの構成要素のための適切な記述名は：
user_idカラムであることを識別するユーザないidのuserテーブル。
- （もちろん、ファイルが代理によってアクセスされ、リレーショナルキーがないレコードファイリングシステムを除いて、それらはまったく同じものです）。
- PKがFKとして運ばれる（移行される）場合は、常にキー列に正確に同じ名前を使用してください。
- したがって、
user_productテーブルにはuser_idPKのコンポーネントとしてがあります(user_id, product_no)。
- コーディングを始めると、これの関連性が明らかになります。まず、
id多くのテーブルがあるので、SQLコーディングで簡単に混同されます。第二に、最初のコーダーが彼が何をしようとしていたのか誰も知らない。キー列を上記のように扱うと、どちらも簡単に防ぐことができます。
2番目の例外は、同じ親テーブルテーブルを参照する複数のFKが子で実行される場合です。あたりとしてリレーショナル・モデル、利用のロール名の意味や用法を区別するために、例えば。AssemblyCodeそしてComponentCode2名PartCodes。そしてその場合、それらの1つに未分化を使用しないPartCodeでください。正確に。
図_E
接頭辞
100以上のテーブルがある場合は、テーブル名の前にサブジェクト領域を付けます。
REF_
OE_Order Entryクラスタなどの参照テーブル用
論理レベルではなく、物理レベルでのみです（モデルが乱雑になります）。
接尾
辞テーブルでは接尾辞を使用しないでください。他のすべての接尾辞は常に使用してください。つまり、データベースの論理的な通常の使用では、下線はありません。ただし、管理側では、下線が区切り記号として使用されます。
_Vビュー（TableNameもちろんメインを前にして）
_fk外部キー（列名ではなく制約名）
_cacキャッシュ
_segセグメント
_trトランザクション（ストアドプロシージャまたは関数）
_fn関数（非トランザクション）など
形式は、テーブルまたはFK名、アンダースコア、アクション名、アンダースコア、最後にサフィックスです。
サーバーからエラーメッセージが表示されると、これは非常に重要です。
____blah blah blah error on object_name
違反したオブジェクトと、それが何をしようとしていたかを正確に把握できます。
____blah blah blah error on Customer_Add_tr
外部キー（列ではなく制約）。FKの最善の命名法は、動詞句（「それぞれ」と基数を差し引いたもの）を使用することです。
Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk
Parent_Child_fkシーケンスを使用するのChild_Parent_fkは、（a）探しているときに正しい並べ替え順序で表示され、（b）関係する子が常にわかっているためです。その場合、エラーメッセージは楽しいものになります。
____ Foreign key violation on Vendor_Offers_PartVendor_fk。
これは、動詞句が特定されているデータのモデル化に悩む人にとってはうまく機能します。それ以外の場合は、レコードファイリングシステムなどでを使用しますParent_Child_fk。
インデックスは特別なので、各文字の位置が1から3の順に構成される、独自の命名規則があります。
U一意、または_非一意の
Cクラスター化、または_非クラスター化
_セパレーター
残りについて：
テーブル名は常に次のように表示されるため、インデックス名には必要ありません。table_name.index_name.
したがって、Customer.UC_CustomerIdまたはProduct.U__AKエラーメッセージに表示された場合、それは何か意味のあることを伝えます。テーブルのインデックスを見ると、簡単に区別できます。
資格のある専門家を見つけてフォローしてください。彼らのデザインを見て、彼らが使う命名規則を注意深く研究してください。理解できないことについて具体的な質問をします。逆に、命名規則や標準にほとんど注意を払わない人からは地獄のように走ります。ここにあなたが始めるためのいくつかがあります：
- これらには、上記のすべての実際の例が含まれています。このスレッドで質問に名前を付けて質問してください。
- もちろん、モデルは、命名規則以外にもいくつかの標準を実装しています。今のところそれらを無視するか、特定の新しい質問を気軽に行うことができます。
- それらはそれぞれ数ページであり、Stack Overflowでのインライン画像サポートは鳥用であり、異なるブラウザで一貫してロードされません。リンクをクリックする必要があります。
- PDFファイルには完全なナビゲーションがあるため、青いガラスのボタン、または展開が識別されているオブジェクトをクリックします。
- Relational Modeling Standardに慣れていない読者は、IDEF1X表記法が役立つでしょう。
標準に準拠した住所での注文入力と在庫
シンプルなオフィス間速報 PHP / MyNonSQLのためのシステム
完全な一時的機能を備えたセンサー監視
質問への回答
コメント欄でそれを合理的に回答することはできません。
Larry Lustig：
...最も簡単な例でさえも示します...
顧客が0対多の製品を持ち、製品が1対多のコンポーネントを持ち、コンポーネントが1対多のサプライヤーを持ち、サプライヤーがゼロを販売する場合対多のコンポーネントとSalesRepには1対多の顧客があり、顧客、製品、コンポーネント、およびサプライヤーを保持するテーブルの「自然な」名前は何ですか？
コメントには2つの大きな問題があります。
あなたは自分の例を「最も簡単なもの」であると宣言しますが、それはそれ以外のものです。そのような矛盾があるので、技術的に能力があるかどうか、あなたが本気かどうかはわかりません。
その「些細な」推測には、いくつかの大きな正規化（DB設計）エラーがあります。
それらを修正するまで、それらは不自然で異常であり、意味がありません。あなたはそれらにabnormal_1、abnormal_2などの名前を付けることもできます
あなたは何も供給しない「供給者」を持っています。循環参照（違法、および不要）; 購入の基礎として、商品（InvoiceやSalesOrderなど）なしで製品を購入する顧客（または顧客が製品を「所有」しているか）。未解決の多対多の関係。等
それが正規化され、必要なテーブルが識別されると、それらの名前が明らかになります。当然。
いずれにせよ、私はあなたの質問に応えようとします。つまり、あなたが何を言っているのかわからずに、それに意味を加える必要があるので、ご容赦ください。重大なエラーは多すぎてリストすることができず、スペアの仕様を考えると、すべてを修正したとは思えません。
投機vs正規化モデル
ご存じない場合は、四角い角（独立）と丸い角（依存）の違いが重要です。IDEF1X表記のリンクを参照してください。同様に、実線（識別）と破線（非識別）。
...顧客、製品、コンポーネント、およびサプライヤーを保持するテーブルの「自然な」名前は何ですか？
- お客様
- 製品
- コンポーネント（または、AssemblyComponent、一方のファクトがもう一方のファクトを識別することを理解する人向け）
- サプライヤー
テーブルを解決したので、問題を理解できません。おそらく、特定の質問を投稿できます。
VoteCoffee：
2つのテーブル（user_likes_product、user_bought_product）の間に複数のリレーションシップが存在するRonnisの例に掲載されているシナリオをどのように扱いますか？私は誤解しているかもしれませんが、これにより、詳細な規則を使用してテーブル名が重複するようです。
正規化エラーがないと仮定すると、これUser likes Productは述語であり、表ではありません。それらを混同しないでください。主語、動詞、述語に関連する私の回答と、すぐ上のラリーに対する私の回答を参照してください。
各テーブルには一連のファクトが含まれています（各行はファクトです）。述語（または命題）は事実ではなく、真実である場合とそうでない場合があります。
クエリは、述語（またはチェーンされた多数の述語）のテストであり、結果はtrue（事実が存在する）またはfalse（事実が存在しない）になります。
したがって、テーブルは、私の回答（命名規則）で詳しく説明されているように、行、ファクト、および述語を文書化する必要があります（必ず、データベースのドキュメントの一部です）が、述語の個別のリストとして名前を付ける必要があります。
これは、それらが重要ではないという示唆ではありません。それらは非常に重要ですが、ここでは書きません。
すぐに。以来リレーショナル・モデルが FOPCに設立され、データベース全体がFOPC宣言の集合、述語の集合であると言うことができます。ただし、（a）述部には多くのタイプがあり、（b）テーブルは1つの述部を表していません（これは、多くの述部とさまざまなタイプの述部の物理的な実装です）。
したがって、「the」述語のテーブルに「それが表す」という名前を付けることは、ばかげた概念です。
「理論家」は少数の述語しか認識しておらず、RMがFOLに基づいて設立されたため、データベース全体が一連の述語であり、さまざまなタイプであることを理解していません。
そしてもちろん、彼らは知っている数少ない中から不条理なものを選びますEXISTING_PERSON。PERSON_IS_CALLED。それがそれほど悲しくなければ、それは陽気なことでしょう。
標準またはアトミックテーブル名（行に名前を付ける）は、すべての表現（テーブルにアタッチされているすべての述語を含む）に対して見事に機能することにも注意してください。逆に、ばかげた「テーブルは述語を表す」という名前はできません。これは、述語についてほとんど理解していないが、それ以外の点で遅れている「理論家」にとっては問題ありません。
データモデルに関連する述語は、モデルで表現され、2つの順序があります。
単項述語
最初のセットは、図ではなくテキストであり、表記自体です。これらにはさまざまな存在が含まれます。制約指向; および記述子（属性）述部。
- もちろん、それは、標準データモデルを「読み取る」ことができる人だけがそれらの述語を読み取ることができることを意味します。そのため、テキストのみの考え方にひどく障害のある「理論家」はデータモデルを読むことができず、1984年以前のテキストのみの考え方に固執します。
バイナリ述語
2番目のセットは、ファクト間の関係を形成するものです。これが関係線です。動詞句（上記で詳述）は、実装されている述語（命題）を識別します（クエリを介してテストできます）。それ以上に明確にすることはできません。
- したがって、標準データモデルに堪能な人にとって、関連するすべての述語がモデルに文書化されます。述語の個別のリストは必要ありません（ただし、データモデルからすべてを「読み取る」ことができないユーザーは必要です）。
これは、私が述語をリストしたデータモデルです。Existentialなどの述語と、Relationshipの述語が表示されるため、この例を選択しました。リストされていない述語は記述子のみです。ここでは、シーカーの学習レベルのため、私は彼をユーザーとして扱います。
したがって、2つの親テーブル間の複数の子テーブルのイベントは問題になりません。それらのコンテンツに存在ファクトとしての名前を付け、名前を正規化するだけです。
ここでは、連想テーブルの関係名に対して動詞句に対して指定したルールが機能します。ここでは、述語とテーブルのディスカッションで、言及されたすべてのポイントを要約して説明します。
述語の適切な使用とその使用方法（ここでのコメントへの応答とはかなり異なるコンテキスト）についての適切な短い説明については、この回答にアクセスし、[ 述語]セクションまでスクロールしてください。
チャールズ・バーンズ：
シーケンスで言うと、Oracleスタイルのオブジェクトは、ある規則（たとえば、「add 1」）に従って数値とその次を格納するために純粋に使用されていました。Oracleには自動IDテーブルがないため、私の典型的な用途はテーブルPKの一意のIDを生成することです。INSERT INTO foo（id、somedata）VALUES（foo_s.nextval、 "data" ...）
OK、それをKeyテーブルまたはNextKeyテーブルと呼びます。そのように名前を付けます。SubjectAreasがある場合は、COM_NextKeyを使用して、データベース全体で共通であることを示します。
ところで、それはキーを生成する非常に貧弱な方法です。まったくスケーラブルではありませんが、Oracleのパフォーマンスでは、「大丈夫」でしょう。さらに、それはあなたのデータベースがサロゲートでいっぱいであり、それらの領域でのリレーショナルではないことを示しています。これは、パフォーマンスが非常に低く、整合性が不足していることを意味します。
primarily opinion-based明らかに誤りです。