In einer relationalen Datenbank handelt es sich bei schwachen Entitäten um Entitäten, welche nicht alleine durch deren Attribute identifiziert werden können. Deshalb müssen Fremdschlüssel verwendet werden, um gemeinsam mit den restlichen Attributen einen Primärschlüssel zu bilden. Bei dem Fremdschlüssel handelt es sich hierbei üblicherweise um den Primärschlüssel der starken Entität, welche der schwachen Entität übergeordnet ist, beziehungsweise von welcher die schwache Entität abhängig ist. Die schwache Entität kann demzufolge nicht ohne der zugehörigen starken Entität existieren.

Property Value
dbo:abstract
  • In einer relationalen Datenbank handelt es sich bei schwachen Entitäten um Entitäten, welche nicht alleine durch deren Attribute identifiziert werden können. Deshalb müssen Fremdschlüssel verwendet werden, um gemeinsam mit den restlichen Attributen einen Primärschlüssel zu bilden. Bei dem Fremdschlüssel handelt es sich hierbei üblicherweise um den Primärschlüssel der starken Entität, welche der schwachen Entität übergeordnet ist, beziehungsweise von welcher die schwache Entität abhängig ist. Die schwache Entität kann demzufolge nicht ohne der zugehörigen starken Entität existieren. In Entity-Relationship-Diagrammen werden schwache Entitäten durch fett gedruckte oder umrandete Rechtecke dargestellt. Eine fett gedruckte oder umrandete Linie führt von der schwachen Entität zu einem Diamanten, welcher die Beziehung beschreibt und mit der übergeordneten starken Entität verbunden ist. Diese Art der Beziehung wird als identifizierende Beziehung bezeichnet und wird in IDEF1X-Notation durch eine ovale Entität anstatt einer rechteckigen Entität angezeigt. Bei identifizierenden Beziehungen wird der Primärschlüssel der übergeordneten starken Entität an die schwache Entität weitergegeben und dort für den zusammengesetzten Primärschlüssel verwendet. Üblicherweise, jedoch nicht zwingend, enthalten Primärschlüssel von schwachen Entitäten keine anderen Attribute außer dem geerbten Primärschlüssel und einer fortlaufenden Nummer. Es gibt zwei Arten von schwachen Entitäten: Assoziative Entitäten und Subtype (Untertyp) Entitäten. Assoziative Entitäten werden verwendet um N:M-Beziehungen in relationalen Datenbanken aufzulösen und enthalten ausschließlich die Fremdschlüssel der zugehörigen Entitäten. Untertyp Entitäten verwenden geerbte Attribute von übergeordneten starken Entitäten und sind ein wichtiger Teil der Normalisierung von Datenbanken. In IDEF1X sind zwei Arten der Untertyp-Beziehung möglich: * vollständige Untertyp-Beziehung (Complete subtype relationship), falls alle Kategorien bekannt sind. * unvollständige Untertyp-Beziehung (Incomplete subtype relationship), falls möglicherweise nicht alle Kategorien bekannt sind. Ein Beispiel für eine schwache Entität ohne Untertyp-Beziehung wären "Header/Detail"-Anzeigen in verschiedenen realen Situationen, wie beispielsweise Bestellungen und Rechnungen, bei welchen der Header die gemeinsamen Informationen enthält, während die Details spezifische Informationen zu den einzelnen Artikeln beinhalten. Das Standardbeispiel für vollständige Untertyp-Beziehungen ist eine Entität für Parteien. Durch den Diskriminator PARTY TYPE, welcher unter anderem Individuen, Partnerschaften, Unternehmen und behördliche Elemente beinhalten kann, sind zwei Untertyp-Entities notwendig: PERSON und ORGANIZATION. Wobei PERSON Informationen zu Individuen enthält, wie beispielsweise Vorname, Nachname und Geburtstag, während ORGANIZATION Attribute wie den vollständigen legalen Namen und organisatorische Hierarchien beinhaltet. In Datenbanken werden Untertyp-Beziehungen dargestellt indem die übergeordnete starke Entität zu einer sogenannten Basis Tabelle wird. Die untergeordneten Entitäten werden davon abgeleitet und entsprechen demnach schwachen Entitäten. Referentielle Integrität wird durch kaskadierende Updates und kaskadierendes Löschen garantiert. (de)
  • In einer relationalen Datenbank handelt es sich bei schwachen Entitäten um Entitäten, welche nicht alleine durch deren Attribute identifiziert werden können. Deshalb müssen Fremdschlüssel verwendet werden, um gemeinsam mit den restlichen Attributen einen Primärschlüssel zu bilden. Bei dem Fremdschlüssel handelt es sich hierbei üblicherweise um den Primärschlüssel der starken Entität, welche der schwachen Entität übergeordnet ist, beziehungsweise von welcher die schwache Entität abhängig ist. Die schwache Entität kann demzufolge nicht ohne der zugehörigen starken Entität existieren. In Entity-Relationship-Diagrammen werden schwache Entitäten durch fett gedruckte oder umrandete Rechtecke dargestellt. Eine fett gedruckte oder umrandete Linie führt von der schwachen Entität zu einem Diamanten, welcher die Beziehung beschreibt und mit der übergeordneten starken Entität verbunden ist. Diese Art der Beziehung wird als identifizierende Beziehung bezeichnet und wird in IDEF1X-Notation durch eine ovale Entität anstatt einer rechteckigen Entität angezeigt. Bei identifizierenden Beziehungen wird der Primärschlüssel der übergeordneten starken Entität an die schwache Entität weitergegeben und dort für den zusammengesetzten Primärschlüssel verwendet. Üblicherweise, jedoch nicht zwingend, enthalten Primärschlüssel von schwachen Entitäten keine anderen Attribute außer dem geerbten Primärschlüssel und einer fortlaufenden Nummer. Es gibt zwei Arten von schwachen Entitäten: Assoziative Entitäten und Subtype (Untertyp) Entitäten. Assoziative Entitäten werden verwendet um N:M-Beziehungen in relationalen Datenbanken aufzulösen und enthalten ausschließlich die Fremdschlüssel der zugehörigen Entitäten. Untertyp Entitäten verwenden geerbte Attribute von übergeordneten starken Entitäten und sind ein wichtiger Teil der Normalisierung von Datenbanken. In IDEF1X sind zwei Arten der Untertyp-Beziehung möglich: * vollständige Untertyp-Beziehung (Complete subtype relationship), falls alle Kategorien bekannt sind. * unvollständige Untertyp-Beziehung (Incomplete subtype relationship), falls möglicherweise nicht alle Kategorien bekannt sind. Ein Beispiel für eine schwache Entität ohne Untertyp-Beziehung wären "Header/Detail"-Anzeigen in verschiedenen realen Situationen, wie beispielsweise Bestellungen und Rechnungen, bei welchen der Header die gemeinsamen Informationen enthält, während die Details spezifische Informationen zu den einzelnen Artikeln beinhalten. Das Standardbeispiel für vollständige Untertyp-Beziehungen ist eine Entität für Parteien. Durch den Diskriminator PARTY TYPE, welcher unter anderem Individuen, Partnerschaften, Unternehmen und behördliche Elemente beinhalten kann, sind zwei Untertyp-Entities notwendig: PERSON und ORGANIZATION. Wobei PERSON Informationen zu Individuen enthält, wie beispielsweise Vorname, Nachname und Geburtstag, während ORGANIZATION Attribute wie den vollständigen legalen Namen und organisatorische Hierarchien beinhaltet. In Datenbanken werden Untertyp-Beziehungen dargestellt indem die übergeordnete starke Entität zu einer sogenannten Basis Tabelle wird. Die untergeordneten Entitäten werden davon abgeleitet und entsprechen demnach schwachen Entitäten. Referentielle Integrität wird durch kaskadierende Updates und kaskadierendes Löschen garantiert. (de)
dbo:author
dbo:originalTitle
  • The entity-relationship model—toward a unified view of data (de)
  • Resolving the “weak status” of weak entity types in entity relationship schemas (de)
  • A comparative analysis of entity-relationship diagrams (de)
  • The entity-relationship model—toward a unified view of data (de)
  • Resolving the “weak status” of weak entity types in entity relationship schemas (de)
  • A comparative analysis of entity-relationship diagrams (de)
dbo:thumbnail
dbo:wikiPageExternalLink
dbo:wikiPageID
  • 9467887 (xsd:integer)
dbo:wikiPageRevisionID
  • 155114398 (xsd:integer)
prop-de:autor
  • Balaban, Mira, und Peretz Shoval
  • Song, Il-Yeol, Mary Evans, und Eun K. Park
prop-de:jahr
  • 1976 (xsd:integer)
  • 1995 (xsd:integer)
  • 1999 (xsd:integer)
prop-de:sammelwerk
  • ACM Transactions on Database Systems
  • Conceptual Modeling—ER’99
  • Journal of Computer and Software Engineering 3.4
dct:subject
bibo:pages
  • 9–36
  • 369-383
  • 427-459
rdf:type
rdfs:comment
  • In einer relationalen Datenbank handelt es sich bei schwachen Entitäten um Entitäten, welche nicht alleine durch deren Attribute identifiziert werden können. Deshalb müssen Fremdschlüssel verwendet werden, um gemeinsam mit den restlichen Attributen einen Primärschlüssel zu bilden. Bei dem Fremdschlüssel handelt es sich hierbei üblicherweise um den Primärschlüssel der starken Entität, welche der schwachen Entität übergeordnet ist, beziehungsweise von welcher die schwache Entität abhängig ist. Die schwache Entität kann demzufolge nicht ohne der zugehörigen starken Entität existieren. (de)
  • In einer relationalen Datenbank handelt es sich bei schwachen Entitäten um Entitäten, welche nicht alleine durch deren Attribute identifiziert werden können. Deshalb müssen Fremdschlüssel verwendet werden, um gemeinsam mit den restlichen Attributen einen Primärschlüssel zu bilden. Bei dem Fremdschlüssel handelt es sich hierbei üblicherweise um den Primärschlüssel der starken Entität, welche der schwachen Entität übergeordnet ist, beziehungsweise von welcher die schwache Entität abhängig ist. Die schwache Entität kann demzufolge nicht ohne der zugehörigen starken Entität existieren. (de)
rdfs:label
  • Schwache Entität (de)
  • Schwache Entität (de)
owl:sameAs
prov:wasDerivedFrom
foaf:depiction
foaf:isPrimaryTopicOf
is foaf:primaryTopic of