「データベースエンティティ」とは何ですか。また、エンティティと見なされるDBMSアイテムの種類は何ですか。
テーブルみたいなもの？または、制約、ストアドプロシージャ、パッケージなども含まれますか？
私はインターネットを見回しましたが、基本的な質問に対する基本的な答えを見つけることは、時々少し難しいです。
エンティティ関係の世界では、エンティティは独立して存在する可能性がありますであり、エンティティとデータベーステーブルの間には1対1の関係があることがよくあります。ただし、このマッピングは実装の決定です。たとえば、ERダイアグラムには、三角形、正方形、円の3つのエンティティが含まれている可能性があり、これらは単一のテーブル（形状）としてモデル化される可能性があります。
また、一部のデータベーステーブルはエンティティ間の関係を表す場合があることに注意してください。
それはかなり一般的な質問です！
基本的に、NUMERIC、VARCHARなどのデータベースシステム自体が提供するすべてのタイプ、または選択したプログラミング言語（int、stringなど）が提供するすべてのタイプは、「アトミック」データ（ベース）タイプと見なされます。
プログラムやビジネスの要件に基づいて、そこから構築したもの、ビジネスオブジェクトなどはすべてエンティティです。
テーブルや制約などは、データの保存と取得に必要なデータベース内部のオブジェクトですが、これらは一般に「エンティティ」とは見なされません。テーブルに格納されているデータを取得してオブジェクトに変換すると、それがエンティティになります。
マーク
これは役に立ちそうです： http://en.wikipedia.org/wiki/Entity-relationship_model
データベースでは、エンティティはテーブルです。この表は、モデル化しようとしている実際の概念（人、トランザクション、イベント）を表します。
制約はエンティティ間の関係を表すことができます。これらは外部キーになります。また、first_nameを空白（null）にすることはできません。トランザクションには1つ以上のアイテムが必要です。イベントには日時が必要です。
ストアドプロシージャ/パッケージ/トリガーは、より複雑な関係を処理したり、ビジネスルールを処理したりできます。
私の回答は明らかに少し遅れていますが、ここではデータベース認定のテキストブックで定義されているとおりです。
エンティティ：データがデータベースに格納されている一意に識別可能な要素。
エンティティとテーブルの混乱を解消するために、
エンティティはテーブルではありません。テーブルは「テーブル」または「リレーション」と呼ぶことができ、単語は同義語です。
このスレッドは、「基本的な質問に対する基本的な答え」を見つけることが難しい理由の1つを示しています。特定の単語は、さまざまなプログラミングパラダイムでさまざまな意味で使用されています（OOプログラマーにクラスとオブジェクトの違いはいつか尋ねてみてください）。
これが私の見解です。
私は最初にエンティティをSSADMのモデリング用語として見つけました（お父さんに聞いてください）。そのコンテキストでは、エンティティは、要件の収集/分析フェーズ中にデータの論理的な束をモデル化するために使用されます。エンティティ間の関係は、エンティティ関係図を使用してモデル化され、エンティティのプロファイルは、エンティティのライフヒストリーを使用してモデル化されました。 ELH図はCOBOLシステムでは非常に役立ちましたが、リレーショナルデータベースでは非常に恐ろしいものでした。一方、ERDは現在も引き続き有用です。
設計と実装の段階で、エンティティはCOBOL入力ファイルのデータベーステーブル、オブジェクト、またはレコードに解決されます。そのプロセスの過程で、論理エンティティが複数のテーブルに分割されたり、複数のエンティティが1つのテーブルに挿入されたり、1対1のマッピングが発生したりすることがあります。エンティティが完全に解決されるか、ビューまたはストアドプロシージャとして残る場合があります。
それは、あなたがそれについてどう考え、問題ドメインをどのようにモデル化するかに依存します。ほとんどの場合、エンティティについて聞くと、それらはオブジェクトクラスにマップされたデータベーステーブル（1つまたは複数）です。したがって、クエリされてクラスインスタンスに変換されるまでは、実際にはエンティティではありません。
しかし、これもモデリング方法論に依存し、複数あります:-)
更新：
私のブログでこの記事を参照してください。この記事では、この主題についてさらに詳しく説明しています。
エンティティは、entity-relationship modelの用語です。
relational model（データベーススキーマ）は、ERモデルを実装する方法の1つです。
リレーショナルテーブルは、整数や文字列などの単純な型間の関係を表し、エンティティ、属性、関係など、すべてを表すことができます。
それが何であるかを関係構造からのみ知ることはできません。ERモデルを見る必要があります。
テーブルpersonsの場合、
id name surname
1 John Smith
id、nameおよびsurnameは実世界のエンティティであり、基礎となるERモデルのエンティティを表す場合とそうでない場合があります。
レコードがテーブルに存在するということは、これらのエンティティが次の関係にあることを意味します： "person 1hasname John andhas姓Smith "。
上記の例では、エンティティはidによって定義されています（モデルの観点から）。
人が自分の名前をJohnからJackに変更した場合、その人は（モデルの観点からは）同じままですが、別のnameに関連付けられます。
上記の例では、nameとsurnameはattributeとして扱うことができます（entityとは対照的です）。スキーマはそれが何であるかを伝えるために実装します。
一部のERからリレーショナルモデルへのマッピングでは、FOREIGN KEYで参照可能なテーブルでエンティティを定義して、entityと見なす必要があります（ドメインを制約する必要があります）。
ただし、この制約は存在する可能性がありますが、（技術的な制限などにより）データベースに表すことはできません。
同様に、すべての可能な名前のリストを保持することはできませんが、@#$^#の名前はおそらく非名前であるため、名前のドメインに属していません。
したがって、attributeはentityであり、関係に参加できますが、ドメイン定義テーブルに含めることはできません。
たとえば、テーブルprices：
good_id price
商品のセット（テーブルgoodsで定義）と実数のセット（カウントできないため、テーブルに含めることはできません）の間の関係を定義します。
それでも、それぞれの価格（$2.00など）は実際のエンティティでもあります。
エンティティは、users/business/enterprise/problemドメインに対して"things of重要"です。
いくつかのコンテキストを知る必要があります。データベースを設計する前の段階でデータを分析するときに人がすることの1つは、管理しているデータ項目とその関係を検討するエンティティリアリティシップ図を作成することです。
それがあなたの言う意味なのかしら？
もしそうなら、おそらくこれを読んだら 記事 あなたは始められますか？