Som ni vet är Weak Entity en tabell som inte har en primärnyckel men primärnyckeln för en svag entitetsuppsättning bildas av primärnyckeln för den starka entitetsuppsättningen som den svaga entitetsuppsättningen är existensberoende på, plus den svaga enhetsuppsättningens diskriminator.
Förhållandet mellan svag enhet och stark enhet kallas Identifierande relation. I exemplet som nämns i bilden ovan är lånebetalning det identifierande förhållandet för betalningsenheten. En svag enhetsuppsättning representeras av en dubbel konturerad ruta och motsvarande identifierande relation av en dubbelkonturerad diamant som visas i figuren. Här indikerar dubbla linjer totalt deltagande av svag enhet i stark enhetsuppsättning, det betyder att varje betalning måste relateras via lånebetalning till något konto. Pilen från betalning av lån till lån anger att varje betalning gäller ett enskilt lån. Diskriminatorn för en svag enhetsuppsättning är understruken med streckade linjer snarare än heldragna linjer.
Låt oss överväga ett annat scenario, där vi vill lagra information om anställda och deras anhöriga. Varje anställd kan ha noll till n antal anhöriga. Varje anhörig har ett ID-nummer och ett namn.
Låt oss nu överväga följande databas:
Det finns tre anställda som har E# som 1, 2 respektive 3.
Nu, i fallet med beroende kan inte enhets-id fungera som primärnyckel eftersom det inte är unikt.
Således är Dependent en svag enhetsuppsättning som har id som diskriminator. Det har en total delaktighet med relationen "har" eftersom ingen beroende kan existera utan de anställda (företaget är angelägen om anställda).
Det finns två tabeller som måste skapas ovanför e-r-diagrammet. Dessa är anställda som har E# som en kolumn som fungerar som primärnyckel. Den andra tabellen kommer att vara beroende med kolumner E#, id och namn där primärnyckeln är kombinationen av (E# och id).