Svag enhet
I en relationsdatabas är en svag enhet en enhet som inte kan identifieras unikt av enbart dess attribut; därför måste den använda en främmande nyckel tillsammans med dess attribut för att skapa en primärnyckel . Den främmande nyckeln är vanligtvis en primärnyckel för en enhet som den är relaterad till.
Den främmande nyckeln är ett attribut för den identifierande (eller ägare , överordnade eller dominerande ) entitetsuppsättningen . Varje element i den svaga entitetsuppsättningen måste ha en relation med exakt ett element i ägarentitetsuppsättningen, och därför kan relationen inte vara en många-till-många-relation.
I entitetsrelationsdiagram (ER-diagram) indikeras en svag entitetsuppsättning med en fet (eller dubbelraderad) rektangel (entiteten) kopplad med en fet (eller dubbelraderad) typpil till en fetstil (eller dubbelradad) diamant (relationen). Denna typ av relation kallas en identifierande relation och i IDEF1X- notation representeras den av en oval enhet snarare än en kvadratisk enhet för bastabeller. En identifierande relation är en där primärnyckeln fylls i den underordnade svaga enheten som en primärnyckel i den entiteten.
I allmänhet (men inte nödvändigtvis) har en svag enhet inga objekt i sin primärnyckel förutom dess ärvda primärnyckel och ett sekvensnummer. Det finns två typer av svaga enheter: associativa enheter och subtypenheter. Den senare representerar en avgörande typ av normalisering , där supertyp-entiteten ärver sina attribut till subtyp-entiteter baserat på värdet av diskriminatorn .
I IDEF1X , en statlig standard för att fånga krav, är möjliga undertypsrelationer:
- Komplett undertypsförhållande , när alla kategorier är kända.
- Ofullständig undertypsrelation , när alla kategorier kanske inte är kända.
Ett klassiskt exempel på en svag enhet utan en undertypsrelation skulle vara "rubrik/detalj"-posterna i många verkliga situationer som krav, order och fakturor, där rubriken fångar information som är gemensam för alla former och detaljen fångar informationsspecifik till enskilda föremål.
Standardexemplet på en fullständig undertypsrelation är partentiteten . Med tanke på diskriminatorn PARTY TYPE (som kan vara individ, partnerskap, C Corporation, Sub Chapter S Association, Association, Governmental Unit, Quasi-governmental byrå) är de två undertyperna PERSON, som innehåller individspecifik information som för- och efternamn och födelsedatum, och ORGANISATION, som skulle innehålla sådana attribut som det juridiska namnet, och organisatoriska hierarkier som kostnadsställen.
När undertypsrelationer renderas i en databas, blir supertypen vad som kallas en bastabell. Undertyperna betraktas som härledda tabeller, som motsvarar svaga enheter. Referensintegritet upprätthålls via kaskaduppdateringar och borttagningar.
Exempel
Tänk på en databas som registrerar kundorder, där en beställning gäller en eller flera av de artiklar som företaget säljer. Databasen skulle innehålla en tabell som identifierar kunder med ett kundnummer ( primärnyckel) ; en annan som identifierar de produkter som kan säljas genom ett produktnummer ( primärnyckel ); och det skulle innehålla ett par tabeller som beskriver beställningar.
En av tabellerna skulle kunna kallas Orders och den skulle ha ett ordernummer ( primärnyckel ) för att identifiera denna order unikt, och skulle innehålla ett kundnummer ( främmande nyckel ) för att identifiera vem produkterna säljs till, plus annan information som t.ex. datum och tid då beställningen gjordes, hur den kommer att betalas, var den ska skickas till osv.
Den andra tabellen skulle kunna kallas OrderItem; den skulle identifieras av en sammansatt nyckel bestående av både ordernumret ( främmande nyckel ) och ett artikelradnummer; med andra icke-primära nyckelattribut som produktnumret ( främmande nyckel ) som beställdes, kvantiteten, priset, eventuell rabatt, eventuella specialalternativ och så vidare. Det kan finnas noll, en eller många OrderItem-poster som motsvarar en Order-post, men ingen OrderItem-post kan existera om inte motsvarande orderpost finns. (Noll OrderItem-fallet gäller normalt endast tillfälligt, när ordern först läggs in och innan den första beställda artikeln har registrerats.)
OrderItem-tabellen lagrar svaga enheter just för att en OrderItem inte har någon betydelse oberoende av Ordern. Vissa kanske hävdar att en OrderItem har någon betydelse i sig själv; den registrerar att någon som inte identifierats av posten någon gång som inte identifierats av posten beställde en viss mängd av en viss produkt. Denna information kan vara till viss nytta i sig, men den är av begränsad användning. Till exempel, så snart du vill hitta säsongsbetonade eller geografiska trender i försäljningen av varan behöver du information från den relaterade orderposten.
En beställning skulle inte existera utan en produkt och en person för att skapa beställningen, så det skulle kunna hävdas att en beställning skulle beskrivas som en svag enhet och att beställda produkter skulle vara ett flervärdesattribut för beställningen.