Indholdsfortegnelse:
Video: Lefa - Potentiel (Clip officiel) ft. Orelsan 2025
Dataintegritet er genstand for overfald fra en række kvartaler. Nogle af disse problemer opstår kun i multitabile SQL-databaser; andre kan ske selv i databaser, der kun indeholder et enkelt bord. Du vil genkende og minimere alle disse potentielle trusler.
Dårlige indtastningsdata
Kildedokumenterne eller datafilerne, du bruger til at udfylde din database, kan indeholde dårlige data. Disse data kan være en beskadiget version af de korrekte data, eller det kan ikke være de data, du ønsker. En interval kontrol fortæller dig, om dataene har domæneintegritet.
Denne type af kontrol fanger nogle - men ikke alle - problemer. For eksempel er forkerte feltværdier, der er inden for acceptabelt område - men stadig ikke korrekte - ikke identificeret som problemer.
Operatørfejl
Dine kildedata kan være korrekte, men dataindtastningsoperatøren kan muligvis udskrive dataene forkert. Denne type fejl kan føre til de samme slags problemer som dårlige inputdata. Nogle af løsningerne er de samme. Range checks hjælper, men de er ikke idiotsikker. En anden løsning er at få en anden operatør til at validere alle dataene uafhængigt.
Denne tilgang er dyr, fordi uafhængig validering tager dobbelt så mange personer og dobbelt så meget. Men i nogle tilfælde, hvor dataintegriteten er kritisk, kan den ekstra indsats og omkostning vise sig at være umagen værd.
Mekanisk svigt
Hvis du oplever et mekanisk svigt, f.eks. Et diskstyrt, kan dataene i tabellen blive ødelagt. Gode backups er dit vigtigste forsvar mod dette problem.
Malice
Overvej muligheden for, at nogen kan vil ødelægge dine data. Din første forsvarslinje er at nægte databasetilgang til alle, der måtte have en ondsindet hensigt og at begrænse autoriserede brugere, så de kun har adgang til de data, de har brug for. Dit andet forsvar er at opretholde data backup på et sikkert sted. Periodisk revurderer sikkerhedsfunktionerne i din installation. At være lidt paranoid gør ikke ondt.
Data redundans
Data redundans - de samme dataposter, der beskæres på flere steder - er et stort problem med den hierarkiske databasemodel, men problemet kan også plage relationelle databaser. Ikke alene gør sådan redundans affald lagerplads og sænke forarbejdning, men det kan også føre til alvorlig data korruption.
Hvis du gemmer det samme datapunkt i to forskellige tabeller i en database, kan elementet i en af disse tabeller ændres, mens det tilsvarende element i den anden tabel forbliver det samme.Denne situation genererer en uoverensstemmelse, og du kan muligvis ikke bestemme hvilken version der er korrekt. Det er en god grund til at holde data redundans til et minimum.
Selvom en vis mængde af redundans er nødvendig for at den primære nøgle i en tabel skal fungere som fremmednøgle i en anden, bør du forsøge at undgå gentagelse af dataelementer ud over det.
Når du fjerner de fleste redundans fra et databasedesign, kan du opleve, at ydeevnen nu er uacceptabel. Operatører bruger ofte målrettet en lille redundans for at fremskynde behandlingen.
En fælles praksis er at indledningsvis designe en database med ringe redundans og med høj grad af normalisering, og efter at have fundet ud af, at vigtige applikationer kører langsomt, selektivt tilføjer redundans og denormaliseres. Nøgleordet her er selektivt.
Redundansen, som du tilføjer igen, skal have et bestemt formål, og fordi du er meget opmærksom på både redundansen og den risiko, den repræsenterer, træffer du passende foranstaltninger for at sikre, at redundansen ikke forårsager flere problemer end den løser.
Når du overskrider din DBMS
kapacitet, kan et databasesystem fungere ordentligt i årevis og derefter begynde at opleve intermitterende fejl, der bliver gradvist mere alvorlige. Dette kan være et tegn på, at du nærmer dig et af systemets kapacitetsgrænser. Der er jo grænser for antallet af rækker, som et bord måtte have. Der er også grænser for kolonner, begrænsninger og forskellige andre databasefunktioner.
Kontroller den aktuelle størrelse og indholdet af din database i forhold til specifikationerne i dokumentationen til dit DBMS. Hvis du er tæt på grænsen i et hvilket som helst område, overveje at opgradere til et system med en højere kapacitet. Du kan også arkivere ældre data, der ikke længere er aktive, og derefter slette den fra din database.
