SQLはドメイン名の整合性と呼ばれる概念を採用しています。これは、オブジェクトの名前がそのコンテナによって指定されるスコープを持つことを意味します。
列名は一意である必要がありますが、列を含むテーブルのコンテキスト内のみです。テーブル名は一意である必要がありますが、テーブルを含むスキーマのコンテキスト内のみである必要があります。
列にクエリを実行するときは、1つ以上の推測ができない限り、関心のあるスキーマ、テーブル、および列を参照する必要があります。クエリを作成するときは、クエリ内のテーブルを名前で直接参照するか、エイリアスを使用して参照する必要があります。クエリが1つのテーブルのみを参照するほど単純でない限り、Customer.IDまたはCustomer CのC.IDなど。
昔のISAMデータベースおよびCOBOLのような言語に1960年代および70年代に適用された）すべての列名の一意性に関する技術的な要件があった時代がありました。 1980年代にdBaseに参入し、リレーショナルおよびオブジェクトDBMSの時代に慣例として定着しました。この古い慣例に抵抗してください。
フラットファイルおよびネットワークデータベースからリレーショナルデータベースへの移行が1970年代と80年代に起こったとき、テーブルを結合するという考えは新しいものでした。したがって、一部の人々は、ある列が別の列への参照（つまり、外部キー）である場合に一意の名前を繰り返すことができるという規則を選択しました。この概念は「自然な結合」と呼ばれ、多くの人々はこれを行うことを今でも支持しています。
私は自然結合のファンではありません。最終的にはドメイン名の整合性の概念を捨て、列参照全体を列名に強制する必要があるためです。
自然結合の問題は、偽善的であるか、列名を長くして判読不能にする必要があることです。例を挙げましょう。Customerテーブルの主キーはCustomerIDであるとよいでしょう。次に、Invoiceテーブルでは、Customerへの外部キーもCustomerIDと呼ばれます。これは自然な結合であり、今のところすべて良好に聞こえます。ここに問題があります。規則がLastUpdatedDateと呼ばれるすべてのテーブルに列を持つことになっている場合はどうなりますか？それで、LastUpdatedDateによってすべてのテーブルを他のすべてのテーブルに結合するつもりですか？もちろん違います。これは、自然な結合の不条理です。この不合理を回避するには、テーブル名を列名にプレフィックスとして詰め込む必要があります。ただし、データベースに複数のスキーマがある場合は、そこで停止することはできません。また、スキーマを列名に追加する必要があります。
自然結合が壊れる別の場所は、同じ2つのテーブル間に複数の関係がある場合です。 InvoiceテーブルでEmployeeへの2つの参照（Sold ByとApproved Byなど）が必要な場合、それらを両方のEmployeeIDと呼ぶことはできません。
簡単な例え。
同じ住所（テーブル名）と名前（フィールド名）を持つ同じ郵便地区（データベーススキーマ）にいる2人の異なる人を考えてください。かわいそうな郵便配達は何をするつもりですか？
システムカタログをチェックする必要があります（RDBMSを指定しませんでした）。しかし、主要なRDBMSのいずれかで許可されているとしたら、私は非常に驚きます！通常、同じテーブル内のフィールド名にはUNIQUE制約があります。
キーワードをフィールド名として使用し、引用識別子（小文字/大文字の混合用）を使用すると、一部のRDBMSは両方を実行しますが、このアイデアが許可された場合、バグのあるコードの可能性が上限を超えてしまいます。返される値を明確に識別するために、クエリ内のフィールドの順序に関するSQLクエリに制約を課す必要があります-" coding horror *"。
フィールドf1、f2、f3、f1でMyTableを指定し、SELECT f2, f1 FROM MyTableを実行するとどうなりますか？それはf1ですか？
データベース（管理システム）は、フィールド名の順序を気にする必要はありません。 さらに悪いことはこれが Coddのルールの明らかな違反であるということです
- ルール2：保証されたアクセスルール：
リレーショナルデータベースのすべてのデータ（原子値）は、テーブル名、主キー値、および列名の組み合わせに頼ることにより、論理的にアクセスできることが保証されています。
[この場合の「列名」はフィールド名でもあります]
多分それはあなたが「教科書」の意味で探しているものです-コッドのルールはRDBMSに関するほとんどの紹介本で見つけることができます。
ところで、サイトへようこそ:-)ここでは、人々が自分で少し作業をすることをお勧めします-@Marcoが提案したように、自分で試してみることができます。サイトツアーに参加して、「Help me to help you」ブログ（ページの左下）とヘルプセンター（右上）もご覧ください。
これらのサイトは優れたリソースであり、ガイドラインに従うことで、サイトを最大限に活用できます。
（*）これらの多くを公開するための素晴らしいサイト。