Sind es Dinge wie Tische? Oder würde es auch Dinge wie Einschränkungen, gespeicherte Prozeduren, Pakete usw. beinhalten?Was ist eine "Datenbankeinheit" und welche Arten von DBMS-Elementen werden als Entitäten betrachtet?
Ich habe mich im Internet umgesehen, aber elementare Antworten auf elementare Fragen zu finden, ist manchmal etwas schwierig.
In der Entity-Beziehung Welt eine Entität ist, dass unabhängig existieren kann und so gibt es oft eine Eins-zu-Eins-Beziehung zwischen Entitäten und Datenbanktabellen. Diese Zuordnung ist jedoch eine Implementierungsentscheidung: Beispielsweise kann ein ER-Diagramm drei Entitäten enthalten: Dreieck, Quadrat und Kreis, und diese könnten möglicherweise als eine einzige Tabelle modelliert werden: Form.
Beachten Sie auch, dass einige Datenbanktabellen Beziehungen zwischen Entitäten darstellen können.
hängt davon ab, wie Sie darüber denken und wie Sie Ihre Problemdomäne modellieren. Die meiste Zeit, wenn Sie von Entitäten hören, sind dies Datenbanktabellen (eine oder mehrere), die Objektklassen zugeordnet sind. Es ist also nicht wirklich eine Entität, bis sie abgefragt und in eine Klasseninstanz umgewandelt wurde.
aber auch hier hängt es von Ihrer Modellierungsmethode, und es gibt mehr :-)
Das ist eine ganz allgemeine Frage!
Grundsätzlich werden alle Typen, die das Datenbanksystem selbst anbietet, wie NUMERIC, VARCHAR usw., oder die Programmiersprache der Wahl (int, string usw.) als "atomare" Daten- (Basistypen) betrachtet.
Alles, was Sie - basierend auf Ihren Programm- oder Geschäftsanforderungen - daraus erstellen, Geschäftsobjekte usw., sind Entitäten.
Tabellen, Constraints usw. sind datenbankinterne Objekte, die zum Speichern und Abrufen von Daten benötigt werden. Diese werden jedoch allgemein nicht als Entitäten betrachtet. Die in Ihren Tabellen gespeicherten Daten werden beim Abrufen und Konvertieren in ein Objekt dann als Entität angezeigt.
Marc
Update:
diesen Artikel in meinem Blog sehen, in denen ich versuche, das Thema näher zu decken:
Eine Entität ist ein Begriff aus der entity-relationship model. Eine relational model (Ihr Datenbankschema) ist eine der Möglichkeiten, das ER-Modell zu implementieren.
Relationale Tabellen repräsentieren Relationen zwischen einfachen Typen wie Ganzzahlen und Strings, die wiederum alles darstellen können: Entitäten, Attribute, Beziehungen.
Sie können nicht sagen, was es nur von der relationalen Struktur ist, müssen Sie das ER-Modell sehen.
Für Tisch persons,
id name surname
1 John Smith
id, name und surname sind Einheiten in der realen Welt und kann oder auch nicht Entitäten in dem zugrundeliegenden ER-Modell darstellen.
Die Tatsache eines Datensatzes in der Tabelle existiert, bedeutet, daß diese Einheiten in der folgenden Beziehung stehen: „person 1hat Namen John und hat Nachnamen Smith“.
In dem obigen Beispiel wird die Entität durch id (aus der Sicht des Modells) definiert.
Wenn eine Person ihren Namen von John zu Jack ändert, bleibt die Person die gleiche (wieder, aus der Sicht des Modells), aber bezieht sich auf eine andere name.
In Beispiel oben name und surname als attribute behandelt werden (im Gegensatz zu entity Gegensatz), aber auch hier müssen Sie das ER-Modell sehen, die dieses Schema zu sagen implementiert, was es ist.
In einigen ER-zu-relationalen Modellzuordnungen sollte eine Entität in einer Tabelle definiert werden, die mit einer FOREIGN KEY als entity in Bezug gesetzt werden kann (die ihre Domäne einschränken sollte).
Diese Einschränkung kann jedoch existieren, aber nicht in einer Datenbank dargestellt werden (aufgrund von technologischen Einschränkungen oder etwas anderem).
Wie können wir nicht eine Liste aller möglichen Namen führen, aber der Name @#$^# ist höchstwahrscheinlich ein Nicht-Name, daher gehört es nicht zur Domain von Namen.
Daher ist attribute ein entity, der an einer Beziehung teilnehmen kann, aber nicht in einer domänendefinierenden Tabelle enthalten sein kann.
Zum Beispiel die Tabelle prices:
good_id price
definiert Beziehungen zwischen der Menge der Waren (die durch die Tabelle definiert ist goods) und die Menge der reellen Zahlen (die in einer Tabelle enthalten ist, kann nicht sein, da es nicht einmal zählbar).
Noch ist jeder Preis (wie $2.00) eine reale Entität ebenso.
sind nicht ID, Name und Nachname ATTRIBUTES eher als ENTITIES? –
In meinem Verständnis, würde diese Zeile, die einen "Smith, John" als Ganzes darstellt, eine Entität sein –
'@ marc_s': Geduld! – Quassnoi
Wir müssten etwas Kontext kennen. Eine Sache, die Menschen manchmal tun, wenn sie Daten in Vorbereitung zum Entwerfen einer Datenbank analysieren, ist ein Entity Realtionship-Diagramm zu erstellen, in dem Sie überlegen, welche Datenelemente Sie verwalten und welche Beziehungen sie haben.
Ich frage mich, ob das der Kontext ist, den du meinst?
Wenn ja, vielleicht ein Lesen dieser article würde Sie beginnen?
Dieser Thread entmystriert einen Grund, warum es schwierig ist, "elementare Antworten auf elementare Fragen" zu finden. Bestimmte Wörter wurden von verschiedenen Programmierparadigmen verwendet, um verschiedene Dinge zu meinen (versuchen Sie es mit einer Reihe von OO-Programmierern, was ist der Unterschied zwischen einer Klasse und einem Objekt irgendwann).
Hier ist meine Sicht darauf.
Ich stieß zuerst auf Entity als Modellierungsbegriff in SSADM (fragen Sie Ihren Vater). In diesem Kontext wird eine Entität verwendet, um während der Anforderungserfassung/Analysephase eine logische Gruppe von Daten zu modellieren. Die Beziehungen zwischen Entitäten wurden mithilfe der Entitätsbeziehungsdiagramme modelliert, und das Profil einer Entity wurde mithilfe von Entity Life Histories modelliert. ELH-Diagramme waren sehr nützlich in COBOL-Systemen, aber schrecklich in relationalen Datenbanken. ERDs auf der anderen Seite sind bis heute nützlich.
Während der Entwurfs- und Implementierungsphase werden die Entitäten in Datenbanktabellen, Objekte oder Datensätze in einer COBOL-Eingabedatei aufgelöst. Im Verlauf dieses Prozesses kann eine logische Entität über mehrere Tabellen verteilt werden, oder mehrere Entitäten können in eine einzelne Tabelle ausgelagert werden, oder es kann eine Eins-zu-Eins-Zuordnung geben. Manchmal wird eine Entität vollständig aufgelöst oder verweilt als Ansicht oder gespeicherte Prozedur.
Dies scheint hilfreich: http://en.wikipedia.org/wiki/Entity-relationship_model
In einer Datenbank ein Unternehmen eine Tabelle ist. Die Tabelle repräsentiert das reale Weltkonzept, das Sie zu modellieren versuchen (Person, Transaktion, Ereignis).
Contraints kann Beziehungen zwischen Entitäten darstellen. Dies wären Fremdschlüssel. Sie erzwingen auch Regeln wie Vorname kann nicht leer sein (null). Eine Transaktion muss mindestens 1 Artikel enthalten. Ein Ereignis muss eine Datumszeit haben.
Gespeicherte Prozeduren/Pakete/Trigger können komplexere Beziehungen verarbeiten und/oder Geschäftsregeln verarbeiten, hängt nur davon ab, was sie tun.
tolle und einfache Erklärung! - "In einer Datenbank ist eine Entität eine Tabelle. Die Tabelle repräsentiert jedes reale Weltkonzept, das Sie zu modellieren versuchen (Person, Transaktion, Ereignis)." –
Entitäten sind "Dinge von Bedeutung" für die Benutzer/Unternehmen/Unternehmen/Problemdomäne.
Meine Antwort ist offensichtlich ein wenig spät, aber hier ist es wie in einer Datenbank Zertifizierung Textbuch definiert:
Entity: Ein eindeutig identifizierbares Element, um die Daten in einer Datenbank gespeichert ist.
und Unternehmen und Tisch Verwirrung zu klären,
Entity ist kein Tisch. Tabellen können als "Tabellen" oder "Relationen" bezeichnet werden, die Wörter synonym sind.
Zuerst klären Sie Ihre Antwort – user1972007
Ich würde Ihnen zustimmen. Eine "Entität" ist normalerweise die Darstellung eines realen Weltobjekts. Eine PERSON-Tabelle ist die Entität, die eine reale Person darstellt. Dinge wie Vorname, Nachname usw. sind Attribute der Entität. –