Beroenden mellan tabeller i en databas

4.1 Inledning

Genom att konvertera databastabellerna till vanliga tabeller kan du nu analysera relationerna mellan dem. Antalet element som interagerar mellan två relaterade tabeller kallas kardinalitet. Cardinality hjälper dig att kontrollera hur effektivt du partitionerar dina data i tabeller.

Teoretiskt sett kan alla enheter upprätthålla relationer med varandra, men i praktiken finns det tre typer av relationer mellan enheter:

• En till en
• En till många
• många till många

4.2 En-till-en-kommunikation

Om det bara finns en instans av entitet A för varje instans av entitet B, sägs de ha en en-till-en-relation (ofta betecknad som "1:1"). På ER-diagram indikeras ett sådant förhållande med en linje med en liten stapel i varje ände:

En 1:1-relation indikerar i allmänhet att, om du inte har en god anledning att hålla dem åtskilda, de två tabellernas data bäst kombineras till en.

I vissa fall är det dock rimligt att använda tabeller med 1:1-relationer. Om dina tabeller har fält med valfria data, såsom beskrivningar, och de i många fall är tomma, är det vettigt att flytta alla beskrivningar till en separat tabell, vilket gör att du kan bli av med frekventa luckor och öka effektiviteten i din databas .

Sedan, för att korrekt mappa data, måste du inkludera minst en identisk kolumn i varje tabell (det är bäst att välja en primärnyckel för detta).

4.3 En-till-många-relation

Den här typen av relation uppstår när en post i en tabell är associerad med flera enheter i en annan. Till exempel kan samma kund göra flera beställningar, eller så kan en biblioteksbesökare låna flera böcker under ett besök. En-till-många-relationer (eller 1:M för kort) uttrycks i ett diagram med kråkfötter, som visas i exemplet nedan:

För att tillämpa en 1:M-relation när du planerar en databas, lägg helt enkelt till primärnyckeln från tabellen "ett" som ett attribut till tabellen "många". Om primärnyckeln finns i en annan tabell kallas den en "främmande nyckel". Tabellen "ett" anses vara den överordnade tabellen, medan tabellen "många" anses vara den underordnade tabellen.

4.4 Många-till-många-relation

När flera enheter i en tabell kan kopplas till flera enheter i en annan, anses de ha en många-till-många (eller M:M) relation. Till exempel finns ett sådant förhållande mellan elever och klasser, eftersom varje elev kan gå i flera olika klasser, och följaktligen kan många elever komma till varje klass.

På ER-diagrammet visas denna typ av relation enligt följande:

Tyvärr är det omöjligt att direkt implementera en sådan relation i databasen. Därför måste den delas upp i två en-till-många-relationer.

För att göra detta måste du skapa en ny enhet mellan de två tabellerna. Om en M:M-relation etableras mellan försäljning och produkter, kan den nya enheten kallas "produkter sålda" eftersom den kommer att representera innehållet i varje försäljning.

Med "sålda varor" och tabellen "försäljning" och tabellen "varor" kommer att länkas ihop med typ 1:M. I olika modeller kallas sådana mellanliggande enheter på olika sätt - "anslutande tabeller", "associativa enheter" eller "nodtabeller".

Varje länktabellpost kopplar samman två olika enheter av intilliggande tabeller (och kan även innehålla ytterligare information). Till exempel kan en länktabell mellan elever och klasser se ut så här:

4.5 Obligatorisk eller inte?

Ett annat tillvägagångssätt för länkanalys är att fastställa vilken av de anslutna enheterna som är en förutsättning för närvaron av en annan enhet. Den valfria länksidan är markerad med en cirkel på stammen.

Till exempel, för att en stat ska ha en egen representant i FN måste den finnas på världskartan, men påståendet om motsatsen kommer att vara falskt:

Två enheter kan vara beroende av varandra (det vill säga, den ena kan inte existera utan den andra).

Rekursiva länkar

Ibland kan en tabell referera till sig själv. Till exempel kan en anställdstabell ha ett "manager"-attribut som skulle hänvisa oss till en annan anställd i samma tabell. Detta är det rekursiva förhållandet.

Extra anslutningar

Länkar anses överflödiga om de uttrycks mer än en gång. Som regel kan en av dem raderas utan att viktig information går förlorad. Till exempel, om entiteten "studenter" är kopplad till entiteten "lärare" inte bara direkt, utan också indirekt genom "klasser", är det vettigt att ta bort förhållandet mellan enheterna "studenter" och "lärare". Detta beslut motiveras av det faktum att det är möjligt att tilldela elever till lärare endast genom klasser.

4.6 Referensintegritet för data

När du byter primära och främmande nycklar bör man observera en sådan aspekt som referensintegritet för data . Dess huvudidé är att hålla två tabeller i en databas som lagrar samma data konsekvent.

Dataintegritet representerar korrekt byggda relationer mellan tabeller med korrekt länkning mellan dem. I vilka fall kan dataintegriteten kränkas:

• Borttagningsavvikelse . Uppstår när en rad tas bort från huvudtabellen. I det här fallet fortsätter den främmande nyckeln från den beroende tabellen att referera till den raderade raden från huvudtabellen.
• Insättningsavvikelse . Uppstår när en rad infogas i en beroende tabell. I det här fallet matchar den främmande nyckeln från den beroende tabellen inte primärnyckeln för någon av raderna från huvudtabellen.
• Uppdatera anomali. Med en sådan anomali kan flera rader i en tabell innehålla data som hör till samma objekt. Om du ändrar data på en rad kan de komma i konflikt med data från en annan rad.

Borttagningsavvikelse

För att lösa borttagningsavvikelsen bör den främmande nyckeln ställas in på en av två begränsningar:

Om en rad från en beroende tabell nödvändigtvis kräver en rad från huvudtabellen, är den främmande nyckeln inställd på kaskadradering. Det vill säga, när en rad tas bort från huvudtabellen raderas den eller de associerade raderna från den beroende tabellen.

Om en rad från en beroende tabell inte tillåter någon relation till en rad från huvudtabellen (det vill säga en sådan relation är valfri), så sätts den främmande nyckeln till NULL när den relaterade raden tas bort från huvudtabellen. Kolumnen för främmande nyckel måste vara nullbar.

Insättningsavvikelse

För att lösa infogningsavvikelsen vid tillägg till en beroende datatabell måste kolumnen som representerar den främmande nyckeln vara nullbar. Och därför, om objektet som läggs till inte har någon koppling till huvudtabellen, kommer kolumnen för främmande nyckel att ha ett NULL-värde.

Uppdatera avvikelser

För att lösa problemet med uppdateringsavvikelser tillämpas normalisering, vilket diskuterades tidigare.