Relāciju datu bāzē **vāja entītija** ir tāda entītija, kas nav unikāli identificējama ar tai atbilstošajiem atribūtiem (nav patstāvīga primārā atslēga), tā vietā šai entītijai ir ārējā atslēga kopā ar atribūtiem, lai veidotu primāro atslēgu. Ārējā atslēga parasti ir kādas citas entītijas, ar ko saistīta entītija, primārā atslēga.
Entītiju relāciju diagrammās vāja entītija ir apzīmēta kā taisnstūris ar dubultu vai trekninātu kontūrlīniju, kas ar trekninātu bultiņu ir saistīts ar rombu, kas ir ar tādu pašu trekninātu vai dubultu kontūrlīniju. Šāda tipa attiecības sauc par identificējošām attiecībām. IDEF1X notācijā šīs attiecības attēlo ar ovālu entītiju, nevis taisnstūrveida entītiju.
Parasti vāja entītija nesatur atsevišķus ierakstus primārajā atslēga, ja vien tie nav pārmantota primārā atslēga un kārtas numurs. Ir divi vājo entītiju veidi :

* asociatīvā entītija
* apakštipa (sub-type) entītija

Apakštipa entītijai ir izšķiroša nozīme standartizēšanas procesā, kur apakštipa entītija manto no savas virstipa (super-type) entītijas atribūtus atkarībā no diskriminatora vērtības.
IDEF1X notācijā ir iespējamās šādas **apakštipa attiecības**:

* pilnīgas apakštipa attiecība , kad visas kategorijas ir zināmas
* nepilnīgas apakštipa attiecības, kad kādas kategorijas var nebūt zināmas

Klasisks piemērs vājai entītija bez apakštipa attiecībām būtu galvenes/detaļas ieraksti dažādās reālās pasaules situācijās tādās kā prasības, pasūtījumi un izsaukumi, kur galvene satur vispārīgu informāciju par visām formām, bet detaļas satur specifisku informāciju par atsevišķiem punktiem.

Bet standarta piemērs pilnīgām apakštipa attiecībām ir partijas entītija. Dotajam diskriminatoram PARTIJAS TIPS ir divas apakštipa entītijas PERSONA , kas katra satur specifisku informāciju, kā, piemēram, pirmā un pēdējā reize, dzimšanas datums, un ORGANIZĀCIJA, kas satur tādus atribūtus kā oficiālo nosaukumu un organizācijas hierarhiju (piem. maksājumu centri)
Attēlojot apakštipa attiecības datu bāzē, augštipa (super-type) tabula ir kā bāzes tabula priekš tabulas, ar ko tā saistīta.

Piemēri
-------

Ir datu bāze ar pircēju pasūtījumiem, kur pasūtījums sastāv no vienas vai vairākām lietām, ko uzņēmums tirgo. Šajā datu bāzē ir tabula, kas idetificē pirējus pēc to pircēju numura (tā ir pircēju primārā atslēga). Un ir cita tabula, kas identificē produktus, kas tiek pārdoti, pēc to produkta numura (primārā atslēga). Kopumā vajadzīgas pāris tabulas, lai aprakstītu pasūtījumu.

Viena no tabulām varētu būt **Pasūtījums** un tā saturētu *pasūtījuma numuru* (primārā atslēga), kas identificētu katru individuālo pasūtījumu un kas saturētu *pircēja numuru* (ārējā atslēga), lai identificētu, kam produkts tiek pārdots, plus vēl informāciju, piemēram, *datumu un laiku*, kad pasūtījums izdarīts, *kā pāsūtījums tiks apmaksāts* utt.

Cita tabula varētu būt **PasūtītāLieta**. Tā būtu identificējama pēc saliktās atslēgas, kas sastāv no *pasūtījuma numura* (ārējā atslēga) un lietas *rindas numura*, un *produkta numura* (ārējā atslēga), *kas ticis pasūtīts*, *daudzuma*, *cenas*, *atlaides*, *speciālām iespējām* utt. Var nebūt, kā arī var būt viens vai vairāki **PasūtītāLieta** ieraksti atkarībā no **Pasūtījums** ierakstiem, bet nevar būt tā, ka eksistē **PasūtītāLieta** ieraksts, ja tai nav atbilstošs **Pasūtījums** ieraksts.

**PasūtītāLieta** tabula glabā vājās entītijas rūpīgi, jo **PasūtītāLieta** ir bez nozīmes, ja nav **Pasūtījums**. Varētu iebilst, ka **PasūtītāLieta** ir sava nozīme, ja kādā laikā, par ko nav izdarīts ieraksts, kāds neidentificēts pircējs ir pasūtījis noteiktu daudzumu kāda noteikta produkta. Šī informācija var tikt izmantota, bet tai ir ierobežota izmantojamība, jo līdzko mēs vēlamies atrast sezonālas vai ģeogrāfiskas tendences par kādu lietu, ir nepieciešama informācija no **Pasūtījums** ieraksta.

Apskati arī
-----------

* Asocitīvā entītija
* ER diagrammas