| rdfs:comment
| - في قواعد البيانات العلائقية، نطلق مصطلح ' كيان ضعيف ' على الكيان الذي لا يمكن أن يوجد بشكل فريد من خلال خصائصه وحده دون الاعتماد على وجود كيان آخر؛ وبالتالي، فإنه يجب استخدام مفتاح خارجي مفتاح أجنبي بالتزامن مع خصائصه لإنشاء مفتاح أساسي خاص بهذا الكيان الضعيف المفتاح الخارجي هو عادة مفتاح أساسي من الكيان القوي الذي يرتبط مهع الكيان الضعيف. في والذي هو المعيار الحكومي الأميريكي لتحديد متطلبات قواعد البيانات تكون العلاقات من النوع المشتق: (ar)
- 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 die zugehörige starke Entität existieren. (de)
- 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 are:
* Complete subtype relationship, when all categories are known.
* Incomplete subtype relationship, when all categories may not be known. (en)
- В реляційних базах даних слабка сутність — це сутність, яка не може бути однозначно визначена самими її атрибутами; а тому, вона повинна використовувати зовнішній ключ у поєднанні зі своїми атрибутами для утворення первинного ключа. Зовнішній ключ, як правило, є первинним ключем сутності, до якої він відноситься. В , урядовому стандарті для захоплення вимог, можливими підтиповими відношеннями є:
* Повні підтипові відношення, коли всі категорії відомі.
* Неповні підтипові відношення, коли не всі категорії можуть бути відомі. (uk)
|
| has 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 die zugehörige starke Entität existieren. Es gibt verschiedene Darstellungsformen für Entity-Relationship-Diagramme. In der Chen-Notation 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)
- في قواعد البيانات العلائقية، نطلق مصطلح ' كيان ضعيف ' على الكيان الذي لا يمكن أن يوجد بشكل فريد من خلال خصائصه وحده دون الاعتماد على وجود كيان آخر؛ وبالتالي، فإنه يجب استخدام مفتاح خارجي مفتاح أجنبي بالتزامن مع خصائصه لإنشاء مفتاح أساسي خاص بهذا الكيان الضعيف المفتاح الخارجي هو عادة مفتاح أساسي من الكيان القوي الذي يرتبط مهع الكيان الضعيف. في مخططات الكيانات العلائقية (ERDs) يرسم الكيان الضعيف ضمن مستطيل مضاعف الحواف (مستطيلين كبير خارجي وصغير داخلي) ويتصل مع الكيانات الأخرى بخطين متوازيين وليس بخط واحد كما هو حال الكيان القوي كما أن العلاقة الرابطة بين الكيان القوي والكيان الضعيف تأخذ شكل معين مضاعف الحواف كما هو حال المستطيل المحدد للكيان.يسمى هذا النوع من العلاقات علاقات التحديد وفي تمثيل هذه العلاقة بشكل بيضوي بدلاً من الشكل المستطيل الذي يستخدم للكيانات القوية.علاقة التحديد المذكورة سابقاً هي العلاقة التي يكون فيها المفتاح الرئيسي من الكيان القوي معطى للكيان الضعيف (الكيان الأبن في هذه الحالة) كمفتاح رئيسي أيضاً. بشكل عام (ولكن ليس بالضرورة) الكيان الضعيف لا يحتوي على بنود في أو خصائص في مفتاحه الرئيسي عدا المفتاح الرئيسي الموروث من الكيان القوي ورقم التسلسل الخاص بالكيان، هناك نوعان من الكيانات الضعيفة: أي الكيانات الناتجة عن كسر علاقة كثير-كثير (many-to-many) في المخططات العلاقاتية . يمثل هذا الأخير نوع شكلاً من النوع القوي في محاكاة الواقع في تمثيل قواعد البيانات وهو ناتج عن التوجه الغرضي في مجال التقنيات الحاسوبية الحديثة (Object-orinted), حيث أن الكيانات المشتق (super-type) تورث صفاتها للكيانات المشتقة (sub-type) وذلك اعتماداً على درجة التخصيص فيما بينها. في والذي هو المعيار الحكومي الأميريكي لتحديد متطلبات قواعد البيانات تكون العلاقات من النوع المشتق:
* علاقات أنواع مشتقة بشكل كامل ، عندما يعرف جميع فئات التوصيف الذي نسعى لمحاكاته.
* علاقات أنواع مشتقة بشكل غير كامل ، عندما لا نعرف جميع فئات التوصيف الذي نسعى لمحاكاته. والمثال الكلاسيكي عن كيان ضعيف دون علاقة فرعية مشتقة هو السجلات التي تتألف من شقين «ترويسة\تفاصيل» في كثير من الحالات في العالم الحقيقي مثل المطالبات والأوامر والفواتير، حيث تعبر الترويسة في السجل عن المعلومات المستركة بين حميع الأنواع المدروسة والتفصيل يمثل معلومات محددة عن الأصناف الفردية. المثال المعياري ل ' علاقة أنواع مشتقة بشكل كامل ' هو كيان عضو. نظرا ل نوع العضوية المميز (والذي يمكن أن يكون فردياً، مشتركاً، في مؤسسة، في جمعية، في رابطة، في اتحاد حكومي، وكالة شبه حكومية) الكيانان المشتقان هما كيان يشتق من كيان «شخص»، الذي يحتوي على معلومات فردية محددة مثل الاسم الأول والأخير وتاريخ الميلاد، وكيان تنظيم، والتي سوف تحتوي على مثل هذه الصفات كالاسم القانوني، والهرمية التنظيمية مثل مراكز التكيلف. عندما يتم تمثيل هذه العلاقات بشكل علاقات مشتفة في قاعدة بيانات، يصبح من نوع «أب» ما يشار إليه باعتبارها الجدول الأساسي. تعتبر الانواع المشتقة أنواعاً موروثة منها، والتي تصنف تحت كيانات ضعيفة. يطبق عبر التحديثات المتتالية والحذف. (ar)
- 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 . The latter represents a crucial type of normalization, where the inherits its attributes to based on the value of the discriminator. In IDEF1X, a government standard for capturing requirements, possible 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. (en)
- В реляційних базах даних слабка сутність — це сутність, яка не може бути однозначно визначена самими її атрибутами; а тому, вона повинна використовувати зовнішній ключ у поєднанні зі своїми атрибутами для утворення первинного ключа. Зовнішній ключ, як правило, є первинним ключем сутності, до якої він відноситься. В діаграмах «сутність — зв'язок» (ER-діаграмах) набір слабких сутностей позначається жирним (або подвійним) прямокутником (сутністю), сполученим жирною (чи подвійною) стрілкою з жирним (або подвійним) ромбом (відношенням). Цей тип відношень називається ідентифікувальним відношенням і в нотації подається овальною сутністю, а не квадратною, як для базових таблиць. Ідентифікувальне відношення є таким, де первинний ключ передається дочірній слабкій сутності як первинний ключ тієї сутності. Загалом (хоча не обов'язково) слабка сутність не має жодних елементів у своєму первинному ключі, крім успадкованих первинних ключів і порядкового номера. Існують два типи слабких сутностей: та підтипові сутності. Останні є важливим типом нормалізації, де супертипова сутність успадковує свої атрибути підтиповим сутностям, заснованим на значенні . В , урядовому стандарті для захоплення вимог, можливими підтиповими відношеннями є:
* Повні підтипові відношення, коли всі категорії відомі.
* Неповні підтипові відношення, коли не всі категорії можуть бути відомі. Класичним прикладом слабкої сутності без підтипового відношення будуть записи «заголовок / деталізація» в багатьох реальних ситуаціях на кшталт заявок, замовлень і рахунків-фактур, де заголовок фіксує загальну інформацію по всім формам, а деталізація фіксує інформацію, специфічну для окремих елементів. Стандартним прикладом повного підтипового відношення є сутність Компанія. Даний дискримінатор ТИП КОМПАНІЇ (який може бути особою, партнерством, корпорацією К, підрозділом асоціації П, асоціацією, урядовим блоком, квазі-урядовим агентством) дві підтипові сутності — ОСОБА, що містить особову інформацію на кшталт імені, прізвища та дати народження, й ОРГАНІЗАЦІЯ, яка міститиме такі атрибути, як юридична назва, й організаційні ієрархії на кшталт центрів витрат. Коли підтипові відношення відображаються в базі даних, супертипові стають тим, що називається базовою таблицею. Підтипи вважаються похідними таблицями, які відповідають слабким сутностям. Посилальна цілісність забезпечується через каскадні оновлення та вилучення. (uk)
|
![[RDF Data]](/fct/images/sw-rdf-blue.png)
![[cxml]](/fct/images/cxml_doc.png)
![[csv]](/fct/images/csv_doc.png)
![[text]](/fct/images/ntriples_doc.png)
![[turtle]](/fct/images/n3turtle_doc.png)
![[ld+json]](/fct/images/jsonld_doc.png)
![[rdf+json]](/fct/images/json_doc.png)
![[rdf+xml]](/fct/images/xml_doc.png)
![[atom+xml]](/fct/images/atom_doc.png)
![[html]](/fct/images/html_doc.png)
