データベース、テーブル、列の命名規則は?[閉まっている]

https://stackoverflow.com/questions/7662

08-06-2019
|

質問

データベースを設計するときはいつも、データベース内の項目に名前を付ける最適な方法はないだろうかと考えます。非常に頻繁に、私は次のような質問を自分自身に問いかけます。

テーブル名は複数であるべきですか?
列名は単数形にする必要がありますか?
テーブルまたは列にプレフィックスを付ける必要がありますか?
項目に名前を付ける際には大文字と小文字を区別する必要がありますか?

データベース内の項目に名前を付ける際に推奨されるガイドラインはありますか?

解決

Microsoft の SQL Server サンプルデータベースをチェックすることをお勧めします。https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

AdventureWorks サンプルでは、データベースオブジェクトの編成にスキーマ名を使用する、非常に明確で一貫した命名規則が使用されています。

テーブルの単数名
列の単数名
テーブルのスキーマ名プレフィックス (例:スキーム名.テーブル名)
パスカルケーシング (別名:上部のキャメルケース）

他のヒント

ここでの遅い答えですが、簡単に言うと：

私の好み複数です
はい
テーブル:*通常* プレフィックスを付けないのが最善です。 コラム:いいえ。
テーブルと列の両方:パスカルケース。

詳細:

(1) やらなければいけないこと。 あなたが望むものはほとんどありません しなければならない 毎回特定の方法を実行しますが、いくつかあります。

あなたの名前を付けてください 主キー 「[singularOfTableName]ID」形式を使用します。つまり、テーブル名が お客様 または お客様, 、主キーは次のようにする必要があります 顧客ID.
さらに遠く、 外部キー しなければならない 一貫して名前を付ける 別のテーブルで。これをしない人を殴ることは合法であるべきです。定義された外部キー制約が頻繁重要で一貫性のある外部キーの命名は、 いつも 重要
データベースに必要なものは、 社内規約. 。後のセクションで私が非常に柔軟であることがわかりますが、内でデータベースの命名には一貫性がなければなりません。顧客用のテーブルが呼ばれるかどうか お客様 または お客様 同じデータベース全体で同じ方法で実行することほど重要ではありません。コインを投げてアンダースコアの使い方を決めることもできますが、その後、 同じように使い続けなければなりません. 。そうしないと、あなたは自尊心の低い悪い人になります。

(2) おそらくやるべきこと。

異なるテーブル上の同じ種類のデータを表すフィールド すべき 同じ名前にします。あるテーブルに Zip を設定し、別のテーブルに ZipCode を設定しないでください。
テーブル名または列名の単語を区切るには、PascalCasing を使用します。キャメルケースを使用すること自体に問題はありませんが、それは慣例ではないため、見た目がおかしくなります。アンダースコアについては後ほど説明します。(昔のようにALLCAPSを使用することはできません。OBNOXIOUSTABLE.ANNOYING_COLUMN は 20 年前の DB2 では問題ありませんでしたが、現在は問題ありません。)
単語を人為的に短くしたり省略したりしないでください。名前は短くて分かりにくいよりも、長くて明確な方が良いです。超短い名前は、より暗く、より野蛮な時代の名残です。Cus_AddRef.それはいったい何なのでしょうか？保管受取人参照?顧客への追加返金?カスタムアドレスの紹介?

(3) 考慮すべきこと。

テーブルには複数の名前を付ける必要があると私は本当に思います。特異だと考える人もいます。他の場所で議論を読んでください。ただし、列名は単数形にする必要があります。複数のテーブル名を使用する場合でも、他のテーブルの組み合わせを表すテーブルは単数形になる場合があります。たとえば、 プロモーション と アイテム テーブルでは、プロモーションの一部であるアイテムを表すテーブルは Promotions_Items である可能性がありますが、正当に Promotion_Items である可能性もあると思います (1 対多の関係を反映)。
アンダースコアは、特定の目的のために一貫して使用してください。PascalCasing を使用すると、一般的なテーブル名だけでも十分に明確になります。単語を区切るのにアンダースコアは必要ありません。アンダースコアは、(a) 連想テーブルを示すために保存するか、(b) 接頭辞として保存します。これについては次の箇条書きで説明します。
プレフィックスは良いも悪いもありません。それ いつもの 最高ではありません。最初の 1 つまたは 2 つのデータベースでは、テーブルの一般的なテーマのグループ化に接頭辞を使用することはお勧めしません。表はカテゴリに簡単には適合しませんが、実際には適合する可能性があります もっと強く テーブルを見つけるために。経験を積めば、害よりも有益なプレフィックス付けスキームを計画して適用することができます。私はかつて、データテーブルがで始まるデータベースで作業しました テーブル, 、構成テーブル ctbl, 、ビュー ビュー, 、プロシージャ sp, 、およびudfのふん, 、その他いくつか。細心の注意を払って一貫して適用されたので、うまくいきました。プレフィックスが必要になるのは、実際には別のソリューションが何らかの理由で同じデータベース内に存在する場合だけです。これらに接頭辞を付けると、テーブルをグループ化するのに非常に役立ちます。目立たせたい一時テーブルなどの特別な状況では、接頭辞を付けることもできます。
列をプレフィックスすることはめったにありません。

さて、私たちは意見を考慮しているので、

テーブル名は複数であるべきだと思います。テーブルはエンティティのコレクション (テーブル) です。各行は 1 つのエンティティを表し、テーブルはコレクションを表します。したがって、私は、人物エンティティのテーブルを人物 (または人物、お好みで) と呼びます。

クエリ内で単数形の「エンティティ名」を確認したい場合は、テーブルエイリアスを使用します。

SELECT person.Name
FROM People person

LINQ の「from person in people select person.Name」に似ています。

2、3、4に関しては、@Larsに同意します。

私は 3 人の DBA がいるデータベースサポートチームで働いており、検討したオプションは次のとおりです。

いかなる命名標準であっても、標準がないよりは優れています。
「唯一の真の」基準はなく、誰もが好みを持っています
すでに標準が定められている場合は、それを使用します。別の標準を作成したり、既存の標準をごまかしたりしないでください。

テーブルには単数形の名前を使用します。テーブルには、システム名 (またはその頭字語) が接頭辞として付けられる傾向があります。これは、プレフィックスを変更してテーブルを論理的にグループ化できるため、システムが複雑な場合に便利です。reg_customer、reg_booking、regadmin_limits)。

フィールドの場合、フィールド名にはテーブルの接頭辞/アクリオンが含まれることが期待されます (つまり、cust_address1) を使用し、標準のサフィックスセット (PK の場合は _id、「コード」の場合は _cd、「名前」の場合は _nm、「番号」の場合は _nb、「日付」の場合は _dt) を使用することも推奨します。

外部キーフィールドの名前は、主キーフィールドと同じである必要があります。

つまり

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

新しいプロジェクトを開発するときは、優先されるエンティティ名、接頭辞、頭字語をすべて書き出して、このドキュメントを開発者に渡すことをお勧めします。その後、新しいテーブルを作成することにした場合、テーブルとフィールドの名前を「推測」するのではなく、ドキュメントを参照することができます。

いいえ。テーブルには、それが表すエンティティにちなんで名前を付ける必要があります。レコードの 1 つが表す人物を指す場合は、人物ではなく人物を使用します。
またまた同じこと。FirstName 列を実際には FirstNames と呼ぶべきではありません。それはすべて、列で何を表現したいかによって異なります。
いいえ。
はい。わかりやすくするためにケースに入れて説明します。「FirstName」のような列が必要な場合は、大文字と小文字を区別すると読みやすくなります。

わかりました。それが私の0.02ドルです

また、私は ISO/IEC 11179 スタイルの命名規則にも賛成であり、これは規範的なものではなくガイドラインであることに注意します。

見るウィキペディアのデータ要素名:

「テーブルはエンティティのコレクションであり、コレクションの命名ガイドラインに従います。理想的には、集合名が使用されます。例: 人事。複数形も正しいです:従業員。間違った名前には次のようなものがあります。従業員、tblEmployee、および従業員テーブル。」

いつものように、ルールには例外があります。常に 1 行だけを持つテーブルの場合は、単数形の名前を使用した方がよい場合があります。構成テーブル。そして一貫性が最も重要です。自分の買い物に規約があるかどうかを確認し、規約がある場合はそれに従ってください。それが気に入らない場合は、ローンレンジャーになるのではなく、ビジネスケースを起こして変更してもらいます。

私たちの好み:

テーブル名は複数であるべきですか?
一度もない。コレクションであるという議論は理にかなっていますが、テーブルに何が含まれるか (0、1 または多数の項目) わかりません。ルールが複数あると、ネーミングが不必要に複雑になります。1 つの家、2 つの家、ネズミ vs ネズミ、人 vs 人、そして他の言語には目を向けていません。

Update person set property = 'value' テーブル内の各人に作用します。
Select * from person where person.name = 'Greg' 人の行のコレクション/行セットを返します。
列名は単数形にする必要がありますか?
正規化ルールに違反している場合を除いて、通常はそうです。
テーブルまたは列にプレフィックスを付ける必要がありますか?
主にプラットフォームの好みです。列の前にテーブル名を付けることを好みます。テーブルにはプレフィックスを付けませんが、ビュー (v_) とstored_procedures (sp_ または f_ (関数)) にはプレフィックスを付けます。これは、実際にはビュー内の計算フィールドである v_person.age (とにかく UPDATE できない) を更新しようとする人に役立ちます。

これは、キーワードの衝突を回避する優れた方法でもあります (delivery.from は壊れますが、delivery_from は壊れません)。

コードはより冗長になりますが、多くの場合、読みやすくなります。

bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
...非常に読みやすく明確です。ただし、これは手に負えなくなる可能性があります。

customer.customer_customer_type_id

customer と customer_type テーブルの関係を示し、customer_type テーブルの主キー (customer_type_id) を示します。クエリのデバッグ中に「customer_customer_type_id」を見た場合は、それがどこから来たのか (customer テーブル) がすぐにわかります。

または、customer_type と customer_category の間に M-M 関係がある場合 (特定のカテゴリでは特定のタイプのみが使用可能)

customer_category_customer_type_id

...少し（！）長めです。
項目に名前を付ける際には大文字と小文字を区別する必要がありますか?はい - 小文字 :)、アンダースコア付き。これらは非常に読みやすく、クロスプラットフォームです。上記の3つと合わせて、これも意味があります。

ただし、これらのほとんどは好みによるものです。- 一貫性があれば、誰が読んでも予測できるはずです。

テーブルが複数化されるかどうかはすべて個人の好みの問題であり、ベストプラクティスはないという議論をよく耳にします。特に DBA ではなくプログラマーとして、それが真実だとは思いません。私の知る限り、テーブル名を複数形にする正当な理由は、「オブジェクトのコレクションだから意味がある」という以外にありませんが、テーブル名を単数形にすることでコード上で正当なメリットが得られます。例えば：

複数の曖昧さによって引き起こされるバグや間違いを回避します。プログラマーはスペルの専門知識について正確には知られていないため、一部の単語を複数形にすることは混乱を招きます。たとえば、複数形の単語は「es」で終わりますか、それとも単に「s」で終わりますか?それは人ですか、それとも人々ですか？大規模なチームでプロジェクトに取り組む場合、これが問題になる可能性があります。たとえば、チームメンバーが間違った方法を使用して、作成したテーブルを複数形にした場合などです。このテーブルを操作する頃には、アクセス権のないコード内で使用されているか、修正するのに時間がかかります。その結果、テーブルを使用するたびに、テーブルのスペルを間違えることを覚えておく必要があります。これとよく似たことが私にも起こりました。チームのすべてのメンバーが、エラーや常にテーブル名を検索する必要なく、正確で正しいテーブル名を一貫して簡単に使用できるようにすることができれば、それだけ良いことになります。単数形のバージョンは、チーム環境での扱いがはるかに簡単です。
テーブル名の単数形を使用し、主キーの先頭にテーブル名を付けると、コードだけで主キーからテーブル名を、またはその逆を簡単に決定できるという利点があります。テーブル名を含む変数を指定し、「Id」を最後に連結すると、追加のクエリを実行することなく、コードを介してテーブルの主キーを取得できます。または、主キーの末尾から「Id」を切り取って、コード経由でテーブル名を決定することもできます。主キーにテーブル名を指定せずに「id」を使用した場合、コードを介して主キーからテーブル名を決定することはできません。さらに、テーブル名を複数形にして PK 列の先頭にテーブル名を付ける人のほとんどは、PK 内でテーブル名の単数形 (status や statusId など) を使用するため、これを行うことはまったく不可能になります。
テーブル名を単数形にすると、それらが表すクラス名と一致させることができます。繰り返しますが、これによりコードが簡素化され、テーブル名だけを指定してクラスをインスタンス化するなど、非常に巧妙な作業が可能になります。また、コードの一貫性が高まるだけでなく、次のような結果が得られます。
テーブル名を単数形にすると、命名スキームが一貫して整理され、どの場所でも保守しやすくなります。コード内のすべてのインスタンスで、列名、クラス名、テーブル名のいずれであっても、まったく同じ名前であることがわかります。これにより、グローバル検索を実行して、データが使用されている場所を確認できるようになります。テーブル名を複数形にする場合、そのテーブル名の単数形 (主キー内のクラス) を使用する場合があります。データが複数形で参照されるインスタンスと単数形で参照されるインスタンスが存在しないのは当然のことです。

要約すると、テーブル名を複数形にすると、コードをよりスマートで扱いやすくするというあらゆる種類の利点が失われます。場合によっては、テーブル名を回避できたはずのオブジェクトまたはローカルコード名に変換するために、ルックアップテーブル/配列が必要になる場合もあります。単数のテーブル名は、最初は少し奇妙に感じるかもしれませんが、複数形の名前よりも大きな利点があり、ベストプラクティスであると私は信じています。

ISO 11179-5 を見てください。命名と識別の原則あなたはそれをここで入手することができます： http://metadata-standards.org/11179/#11179-5

少し前にここでブログに書きました: ISO-11179 の命名規則

遅いことは承知しており、質問にはすでに十分に答えられていますが、#3 の列名の接頭辞について私の意見を述べたいと思います。

すべての列には、定義されているテーブルに固有のプレフィックスを付けて名前を付ける必要があります。

例えば。テーブル「customer」と「address」がある場合、それぞれ「cust」と「addr」のプレフィックスを使用してみましょう。「customer」には「cust_id」、「cust_name」などが含まれます。初期化。「address」には「addr_id」、「addr_cust_id」（顧客へのFK）、「addr_street」などが含まれます。初期化。

最初にこの基準を提示されたとき、私は絶対に反対しました。私はその考えが嫌いでした。私は、余分な入力と冗長性の考えに耐えられませんでした。今では十分な経験を積んだので、もう戻ることはありません。

これを実行した結果、データベーススキーマ内のすべての列が一意になります。これには、これに対するあらゆる議論を打ち破る大きな利点が 1 つあります (もちろん、私の意見では)。

コードベース全体を検索し、特定の列に触れるコードのすべての行を確実に見つけることができます。

#1 から得られるメリットは信じられないほど大きいです。列を非推奨にし、列をスキーマから安全に削除する前にどのファイルを更新する必要があるかを正確に知ることができます。列の意味を変更でき、どのコードをリファクタリングする必要があるかを正確に知ることができます。あるいは、列のデータがシステムの特定の部分で使用されているかどうかを単純に知ることもできます。これにより、潜在的に巨大なプロジェクトが単純なプロジェクトに変わった回数は数え切れません。また、開発作業でどれだけの時間が節約できたかも数え切れません。

もう 1 つの比較的マイナーな利点は、自己結合を行う場合にのみテーブルエイリアスを使用すればよいことです。

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

これらについての私の意見は次のとおりです。

1) いいえ、テーブル名は単数形にする必要があります。

単純な選択には意味があるように見えますが (select * from Orders) OO に相当するものについてはあまり意味がありません (Orders x = new Orders).

DB 内のテーブルは実際にはそのエンティティのセットであり、set-logic を使用するとより意味が分かります。

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

最後の行である結合の実際のロジックは、複数のテーブル名があり混乱しているように見えます。

（マットが示唆しているように）常にエイリアスを使用することでそれが解消されるかどうかはわかりません。

2) プロパティを 1 つだけ保持するため、単数形にする必要があります。

3) 決して、列名があいまいな場合 (上記のように、両方に [Key] という列がある場合)、テーブルの名前 (またはそのエイリアス) でそれらを十分に区別できます。クエリをすばやく入力してシンプルにする必要がある場合、プレフィックスによって不必要な複雑さが追加されます。

4) 何でもいいので、CapitalCase をお勧めします

これらについては、絶対的なガイドラインというものは存在しないと思います。

選択したものがアプリケーションまたは DB 全体で一貫している限り、それは実際には重要ではないと思います。

私の意見では：

テーブル名は複数である必要があります。
列名は単数形である必要があります。
いいえ。
テーブル名と列名の両方に CamelCase (私の好み) または underscore_ Separated のいずれかを使用します。

ただし、すでに述べたように、いかなる規則であっても、規則がないよりは優れています。どのような方法を選択する場合でも、将来の変更が同じ規則に従うように文書化してください。

テーブル名は必ず単数形にし、人ではなく人を使用してください
1. こっちも一緒
2. いいえ。扱っているのがテーブル (tbl_) またはユーザーストアプロシージャ (usp_) であるとまで述べている、ひどいプレフィックスをいくつか見たことがあります。これにデータベース名が続きます...やめてください！
3. はい。私はすべてのテーブル名を PascalCase にする傾向があります

これらの質問のそれぞれに対する最善の答えは、あなたとあなたのチームによって与えられると思います。命名規則がどの程度正確であるかよりも、命名規則があることの方がはるかに重要です。

これに対する正しい答えはないので、時間をかけて (ただし、あまり時間をかけすぎないように) 独自の規則を選択する必要があります。 ここにあります 重要な部分は、それに固執することです。

もちろん、それに関する標準に関する情報を求めるのは良いことであり、それがあなたが求めていることですが、さまざまな答えが得られる可能性があることを心配したり心配したりする必要はありません。自分にとってより良いと思われるものを選択してください。

念のため、私の答えは次のとおりです。

はい。テーブルは次のグループです。記録, 教師または俳優, 、それで...複数。
はい。
私はそれらを使いません。
私がより頻繁に使用するデータベースである Firebird ではすべてが大文字で保持されるため、問題ありません。とにかく、プログラミングするときは、次のように名前を読みやすい方法で書きます。 発売年.

命名規則により、開発チームはプロジェクトの中心で発見しやすさと保守しやすさを設計できます。

適切な命名規則を進化させるには時間がかかりますが、いったん導入されると、チームは共通の言語を使用して前進することができます。適切な命名規則は、プロジェクトとともに自然に成長していきます。適切な命名規則を使用すると、ソフトウェアライフサイクルの最も長く最も重要なフェーズである運用環境でのサービス管理における変更に簡単に対処できます。

私の答えは次のとおりです。

はい、一連のテーブルを参照する場合、テーブル名は複数である必要があります。取引, 有価証券, 、または 取引相手 例えば。
はい。
はい。SQL テーブルには tb_ というプレフィックスが付けられ、ビューには vw_ というプレフィックスが付けられ、ストアドプロシージャには usp_ というプレフィックスが付けられ、トリガーには tg_ というプレフィックスが付けられ、その後にデータベース名が続きます。
列名は小文字でアンダースコアで区切る必要があります。

名前を付けるのは難しいですが、どの組織にも名前を付けることができる人がいますし、どのソフトウェアチームにも名前の標準に責任を負い、次のような名前の問題が確実に解決されるようにする人がいる必要があります。 sec_id, 秒の値 そして security_id プロジェクトに組み込まれる前に、早期に解決されます。

では、優れた命名規則と標準の基本原則は何でしょうか。-

クライアントの言語とソリューションドメインを使用する
説明的なものにする
一貫性を保つ
曖昧さを排除し、反映し、リファクタリングする
略語をすべての人に明確にしない限り使用しないでください
列名としてSQL予約キーワードを使用しないでください

いくつかの選択肢を提供するリンクを次に示します。私は、部分的に定義された仕様に依存するのではなく、従うことができるシンプルな仕様を探していました。

http://justinsomnia.org/writings/naming_conventions.html

テーブル名はオブジェクトのセットを表すため、常に単数形にする必要があります。herd は羊のグループを指しますが、flock は鳥のグループを指します。複数は必要ありません。テーブル名が 2 つの名前で構成されており、命名規則が複数形である場合、複数形の名前を最初の単語にするか 2 番目の単語にするか、あるいは両方にするかを判断するのが難しくなります。これはロジックです。objects.instance ではなく、Object.instance です。または、TableNames.column ではなく、TableName.column。Microsoft SQL では大文字と小文字が区別されません。2 つ以上の名前で構成されるテーブル名または列名を区切るために大文字を使用すると、テーブル名が読みやすくなります。

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

テーブル名: これは、単数であるオブジェクトではなく現実世界のオブジェクトを表す単数エンティティであるため、単数である必要があります。

列名: 単数である必要がある場合にのみ、それが原子値を保持し、正規化理論を裏付けることがわかります。ただし、同じタイプのプロパティが n 個ある場合は、接尾辞として 1、2、...、n などを付ける必要があります。

テーブル/列の接頭辞:これは大きなテーマですので、後で説明します。

ケーシング:キャメルケースにすればいいのに

私の友人、 パトリック・ケルチャー, あなたが書いたように、誰かを不快にするようなことは書かないでください、「また、外部キーは異なるテーブルで一貫した名前を付ける必要があります。」これをしない人を殴るのは合法であるべきだ。」友人のパトリック、私はこのような間違いをしたことがありませんが、一般的に書いています。もし彼らがこの件であなたを倒すつもりだったらどうしますか？:)

パーティーにはかなり遅れましたが、列のプレフィックスについて 2 セント追加したいと思いました

列の table_column (または tableColumn) 命名標準を使用するには、主に 2 つの議論があるようです。どちらも、列名自体がデータベース全体で一意であるという事実に基づいています。

1) クエリで常にテーブル名や列のエイリアスを指定する必要はありません

2) コード全体の列名を簡単に検索できます

どちらの議論も間違っていると思います。プレフィックスを使用せずに両方の問題を解決するのは簡単です。私の提案は次のとおりです。

SQL では常にテーブル名を使用してください。たとえば、column の代わりに、常に table.column を使用します。

table_column の代わりに table.column を検索するだけで済むため、2) は明らかに解決されます。

でも、あなたの叫び声が聞こえます。1) はどうやって解決しますか?まさにこれを回避するためのものでした。はい、その通りでしたが、その解決策にはひどく欠陥がありました。なぜ？さて、プレフィックスの解決策は次のようになります。
曖昧な場合に table.column を指定する必要がないようにするには、すべての列に table_column! という名前を付けます。
ただし、これは今後、列を指定するたびに常に列名を記述する必要があることを意味します。しかし、それでもそうしなければならない場合、常に明示的に table.column を記述することと比べてどのようなメリットがあるのでしょうか?まさに、何のメリットもありません。入力する文字数はまったく同じです。

編集：はい、列にプレフィックスを付けて名前を付けると正しい使用法が適用されることは承知していますが、私のアプローチはプログラマーに依存しています。

重要なデータベースの命名規則 (およびスタイル) (さらに詳しい説明についてはここをクリックしてください)

テーブル名は短い、明確な名前を選択します。1つまたは2つ以下の単語を使用して、テーブルを区別することは、一意のフィールド名の命名を容易に促進します。私はこの規則の理由に今でも同意しますが、ほとんどの人は複数のテーブル名を本当に好むので、私の立場を軟化させました)...上のリンクをクリックしてください

テーブル名は単数形です。誰かとその住所の間の関係をモデル化しているとします。たとえば、データモデルを読んでいる場合は、「各人は0.1または多くの住所に住むことができます」を好むでしょうか。または「それぞれの人々が0.1または多くの住所に住むことができます。」人を人として言い換える必要があるのではなく、それがより簡単に住所を容易にすると思います。さらに、集合名詞は単数形とは異なることがよくあります。


--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

これらは私が教えられた慣例ですが、開発ホースが使用するものにはすべて適応する必要があります。

複数。エンティティのコレクションです。
はい。属性は、エンティティの単一のプロパティを表現したものです。
はい、プレフィックステーブル名を使用すると、すべての制約インデックスとテーブルエイリアスの名前を簡単に追跡できます。
テーブル名と列名にはパスカルケース、インデックスと制約には接頭辞とすべて大文字を使用します。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow