Potentiële probleemgebieden in multitable SQL-databases - dummies

Gegevensintegriteit is onderhevig aan aanvallen van verschillende kwarten. Sommige van deze problemen doen zich alleen voor in multitable SQL-databases; andere kunnen zelfs voorkomen in databases die slechts één tabel bevatten. U wilt al deze potentiële dreigingen herkennen en minimaliseren.

Slechte invoergegevens

De brondocumenten of gegevensbestanden die u gebruikt om uw database te vullen, kunnen slechte gegevens bevatten. Deze gegevens kunnen een corrupte versie van de juiste gegevens zijn of het zijn mogelijk niet de gegevens die u zoekt. Een bereikcontrole vertelt u of de gegevens domeinintegriteit hebben.

Dit type controle vangt enkele - maar niet alle - problemen op. Onjuiste veldwaarden die binnen het acceptabele bereik liggen, maar nog steeds niet correct zijn, worden bijvoorbeeld niet als problemen geïdentificeerd.

Operatorfout

Uw brongegevens kunnen correct zijn, maar de gegevensinvoeroperator kan de gegevens onjuist transcriberen. Dit type fout kan tot hetzelfde soort problemen leiden als slechte invoergegevens. Sommige oplossingen zijn ook hetzelfde. Bereikcontroles helpen, maar ze zijn niet waterdicht. Een andere oplossing is om een ​​tweede operator onafhankelijk alle gegevens te laten valideren.

Deze aanpak kost veel geld, omdat onafhankelijke validatie twee keer zoveel mensen kost, en tweemaal zo vaak. Maar in sommige gevallen waar gegevensintegriteit van cruciaal belang is, kunnen de extra inspanningen en kosten de moeite waard blijken.

Mechanische storing

Als u een mechanische storing ondervindt, zoals een schijfcrash, kunnen de gegevens in de tabel worden vernietigd. Goede back-ups zijn uw belangrijkste verdediging tegen dit probleem.

Malice

Overweeg de mogelijkheid dat iemand wil om uw gegevens te corrumperen. Uw eerste verdedigingslinie is om databasetoegang te weigeren aan iedereen die mogelijk een kwaadwillige bedoeling heeft en om geautoriseerde gebruikers te beperken zodat ze alleen toegang hebben tot de gegevens die ze nodig hebben. Uw tweede verdediging is om gegevensback-ups op een veilige plek te bewaren. Evalueer regelmatig de beveiligingsfuncties van uw installatie opnieuw. Een beetje paranoïde zijn doet geen pijn.

Gegevensredundantie

Gegevensredundantie - dezelfde gegevensitems die op meerdere plaatsen voorkomen - is een groot probleem met het hiërarchische databasemodel, maar het probleem kan ook relationele databases teisteren. Niet alleen verspilt zo'n redundantie opslagruimte en vertraagt ​​het verwerken, maar het kan ook leiden tot ernstige datacorruptie.

Als u hetzelfde gegevensitem in twee verschillende tabellen in een database opslaat, kan het item in een van die tabellen veranderen terwijl het overeenkomstige item in de andere tabel hetzelfde blijft.Deze situatie genereert een discrepantie en het is mogelijk dat u niet kunt bepalen welke versie correct is. Dat is een goede reden om gegevensredundantie tot een minimum te beperken.

Hoewel een bepaalde hoeveelheid redundantie nodig is om de primaire sleutel van de ene tabel als een buitenlandse sleutel in de andere te gebruiken, moet u proberen de herhaling van gegevensitems daarbuiten te voorkomen.

Nadat u de meeste redundantie uit een databaseontwerp hebt verwijderd, is het mogelijk dat de prestaties nu onaanvaardbaar zijn. Operators gebruiken vaak doelbewust een beetje redundantie om de verwerking te versnellen.

Een veel voorkomende praktijk is om in eerste instantie een database te ontwerpen met weinig redundantie en met een hoge mate van normalisatie, en vervolgens, na te hebben vastgesteld dat belangrijke applicaties langzaam worden uitgevoerd, om selectief redundantie toe te voegen en te denormaliseren. Het sleutelwoord is hier selectief.

De redundantie die u weer toevoegt, moet een specifiek doel hebben en omdat u zich zowel bewust bent van de redundantie als van het gevaar dat deze vertegenwoordigt, neemt u gepaste maatregelen om ervoor te zorgen dat de overtolligheid niet meer problemen veroorzaakt dan oplost.

Wanneer u de capaciteit van uw DBMS overschrijdt

A werkt een databasesysteem mogelijk jaren goed en begint dan intermitterende fouten te ervaren die steeds ernstiger worden. Dit kan een teken zijn dat u een van de capaciteitslimieten van het systeem nadert. Er zijn immers limieten voor het aantal rijen dat een tabel kan hebben. Er zijn ook limieten op kolommen, beperkingen en verschillende andere databasefuncties.

Controleer de huidige grootte en inhoud van uw database aan de hand van de specificaties in de documentatie van uw DBMS. Als u in een bepaald gebied in de buurt van de limiet bent, kunt u overwegen een upgrade uit te voeren naar een systeem met een hogere capaciteit. Of u wilt oudere gegevens die niet langer actief zijn, archiveren en vervolgens uit uw database verwijderen.