About: Weak entity   Goto Sponge  NotDistinct  Permalink

An Entity of Type : dbo:Organisation, within Data Space : dbpedia.org associated with source document(s)
QRcode icon
http://dbpedia.org/describe/?url=http%3A%2F%2Fdbpedia.org%2Fresource%2FWeak_entity

In a relational database, a weak entity is an entity that cannot be uniquely identified by its attributes alone; therefore, it must use a foreign key in conjunction with its attributes to create a primary key. The foreign key is typically a primary key of an entity it is related to. In IDEF1X, a government standard for capturing requirements, possible sub-type relationships are: * Complete subtype relationship, when all categories are known. * Incomplete subtype relationship, when all categories may not be known.

AttributesValues
rdf:type
rdfs:label
  • Weak entity
  • كيان ضعيف
  • Schwache Entität
rdfs:comment
  • In a relational database, a weak entity is an entity that cannot be uniquely identified by its attributes alone; therefore, it must use a foreign key in conjunction with its attributes to create a primary key. The foreign key is typically a primary key of an entity it is related to. In IDEF1X, a government standard for capturing requirements, possible sub-type relationships are: * Complete subtype relationship, when all categories are known. * Incomplete subtype relationship, when all categories may not be known.
  • 25بك المحتوى هنا ينقصه الاستشهاد بمصادر. يرجى إيراد مصادر موثوق بها. أي معلومات غير موثقة يمكن التشكيك بها وإزالتها. (مارس 2016) في قواعد البيانات العلائقية،نطلق مصطلح ' كيان ضعيف ' على الكيان الذي لا يمكن أن يوجد بشكل فريد من خلال خصائصه وحده دون الاعتماد على وجود كيان آخر ؛ وبالتالي، فإنه يجب استخدام مفتاح خارجي foreign key بالتزامن مع خصائصه لإنشاء مفتاح أساسي خاص بهذا الكيان الضعيف المفتاح الخارجي هو عادة مفتاح أساسي من الكيان القوي الذي يرتبط مهع الكيان الضعيف . في IDEF1X و الذي هو المعيار الحكومي الأميريكي لتحديد متطلبات قواعد البيانات تكون العلاقات من النوع المشتق:
  • 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.
sameAs
dct:subject
Wikipage page ID
Wikipage revision ID
Link from a Wikipage to another Wikipage
foaf:depiction
  • External Image
foaf:isPrimaryTopicOf
thumbnail
prov:wasDerivedFrom
has abstract
  • In a relational database, a weak entity is an entity that cannot be uniquely identified by its attributes alone; therefore, it must use a foreign key in conjunction with its attributes to create a primary key. The foreign key is typically a primary key of an entity it is related to. In entity relationship diagrams, ER diagrams a weak entity set is indicated by a bold (or double-lined) rectangle (the entity) connected by a bold (or double-lined) type arrow to a bold (or double-lined) diamond (the relationship). This type of relationship is called an identifying relationship and in IDEF1X notation it is represented by an oval entity rather than a square entity for base tables. An identifying relationship is one where the primary key is populated to the child weak entity as a primary key in that entity. In general (though not necessarily) a weak entity does not have any items in its primary key other than its inherited primary key and a sequence number. There are two types of weak entities: associative entities and subtype entities. The latter represents a crucial type of normalization, where the super-type entity inherits its attributes to subtype entities based on the value of the discriminator. In IDEF1X, a government standard for capturing requirements, possible sub-type relationships are: * Complete subtype relationship, when all categories are known. * Incomplete subtype relationship, when all categories may not be known. A classic example of a weak entity without a sub-type relationship would be the "header/detail' records in many real world situations such as claims, orders and invoices, where the header captures information common across all forms and the detail captures information specific to individual items. The standard example of a complete subtype relationship is the party entity. Given the discriminator PARTY TYPE (which could be individual, partnership, C Corporation, Sub Chapter S Association, Association, Governmental Unit, Quasi-governmental agency) the two subtype entities are PERSON, which contains individual-specific information such as first and last name and date of birth, and ORGANIZATION, which would contain such attributes as the legal name, and organizational hierarchies such as cost centers. When sub-type relationships are rendered in a database, the super-type becomes what is referred to as a base table. The sub-types are considered derived tables, which correspond to weak entities. Referential integrity is enforced via cascading updates and deletes.
  • 25بك المحتوى هنا ينقصه الاستشهاد بمصادر. يرجى إيراد مصادر موثوق بها. أي معلومات غير موثقة يمكن التشكيك بها وإزالتها. (مارس 2016) في قواعد البيانات العلائقية،نطلق مصطلح ' كيان ضعيف ' على الكيان الذي لا يمكن أن يوجد بشكل فريد من خلال خصائصه وحده دون الاعتماد على وجود كيان آخر ؛ وبالتالي، فإنه يجب استخدام مفتاح خارجي foreign key بالتزامن مع خصائصه لإنشاء مفتاح أساسي خاص بهذا الكيان الضعيف المفتاح الخارجي هو عادة مفتاح أساسي من الكيان القوي الذي يرتبط مهع الكيان الضعيف . في مخططات الكيانات العلائقية (ERDs) يرسم الكيان الضعيف ضمن مستطيل مضاعف الحواف (مستطيلين كبير خارجي و صغير داخلي) و يتصل مع الكيانات الأخرى بخطين متوازيين و ليس بخط واحد كما هو حال الكيان القوي كما أن العلاقة الرابطة بين الكيان القوي و الكيان الضعيف تأخذ شكل معين مضاعف الحواف كما هو حال المستطيل المحدد للكيان .يسمى هذا النوع من العلاقات علاقات التحديد وفي IDEF1Xيتم تمثيل هذه العلاقة بشكل بيضوي بدلاً من الشكل المستطيل الذي يستخدم للكيانات القوية .علاقة التحديد المذكورة سابقاً هي العلاقة التي يكون فيها المفتاح الرئيسي من الكيان القوي معطى للكيان الضعيف (الكيان الأبن في هذه الحالة) كمفتاح رئيسي أيضاً . بشكل عام (ولكن ليس بالضرورة ) الكيان الضعيف لا يحتوي على بنود في أو خصائص في مفتاحه الرئيسي عدا المفتاح الرئيسي الموروث من الكيان القوي و رقم التسلسل الخاص بالكيان , هناك نوعان من الكيانات الضعيفة :الكيانات الترابطية اي الكيانات الناتجة عن كسر علاقة كثير-كثير (many-to-many) في المخططات العلاقاتية و كيانات مشتقة . يمثل هذا الأخير نوع شكلاً من النوع القوي في محاكاة الواقع في تمثيل قواعد البيانات و هو ناتج عن التوجه الغرضي في مجال التقنيات الحاسوبية الحديثة (Object-orinted) , حيث أن الكيانات المشتق (super-type) تورث صفاتها للكيانات المشتقة (sub-type) وذلك اعتماداً على درجة التخصيص فيما بينها . في IDEF1X و الذي هو المعيار الحكومي الأميريكي لتحديد متطلبات قواعد البيانات تكون العلاقات من النوع المشتق: * علاقات أنواع مشتقة بشكل كامل ، عندما يعرف جميع فئات التوصيف الذي نسعى لمحاكاته. * علاقات أنواع مشتقة بشكل غير كامل ، عندما لا نعرف جميع فئات التوصيف الذي نسعى لمحاكاته. والمثال الكلاسيكي عن كيان ضعيف دون علاقة فرعية مشتقة هو السجلات التي تتألف من شقين "ترويسة\تفاصيل" في كثير من الحالات في العالم الحقيقي مثل المطالبات والأوامر و الفواتير ، حيث تعبر الترويسة في السجل عن المعلومات المستركة بين حميع الأنواع المدروسة و التفصيل يمثل معلومات محددة عن الأصناف الفردية. المثال المعياري ل ' علاقة أنواع مشتقة بشكل كامل ' هو كيان عضو . نظرا ل نوع العضوية المميز (والذي يمكن أن يكون فردياً ، مشتركاً، في مؤسسة ،في جمعية , في رابطة ، في اتحاد حكومي ، وكالة شبه حكومية ) الكيانان المشتقان هما كيان يشتق من كيان "شخص" ، الذي يحتوي على معلومات فردية محددة مثل الاسم الأول والأخير وتاريخ الميلاد ، و كيان تنظيم ، والتي سوف تحتوي على مثل هذه الصفات كالاسم القانوني ، و الهرمية التنظيمية مثل مراكز التكيلف . عندما يتم تمثيل هذه العلاقات بشكل علاقات مشتفة في قاعدة بيانات ، يصبح من نوع "أب" ما يشار إليه باعتبارها الجدول الأساسي. تعتبر الانواع المشتقة أنواعاً موروثة منها، والتي تصنف تحت كيانات ضعيفة. التكامل المرجعي يطبق عبر التحديثات المتتالية والحذف .
  • 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.
http://purl.org/voc/vrank#hasRank
http://purl.org/li...ics/gold/hypernym
is Link from a Wikipage to another Wikipage of
is Wikipage redirect of
is foaf:primaryTopic of
Faceted Search & Find service v1.17_git21 as of Mar 09 2019


Alternative Linked Data Documents: iSPARQL | ODE     Content Formats:       RDF       ODATA       Microdata      About   
This material is Open Knowledge   W3C Semantic Web Technology [RDF Data] Valid XHTML + RDFa
OpenLink Virtuoso version 07.20.3230 as of Apr 1 2019, on Linux (x86_64-generic-linux-glibc25), Single-Server Edition (61 GB total memory)
Data on this page belongs to its respective rights holders.
Virtuoso Faceted Browser Copyright © 2009-2019 OpenLink Software