• Articles
• admin

introduktion

Data gemmes i tabeller i en database. Den kan gemmes i en enkelt tabel (kaldet en flad database – som vist i figur 2.1) eller i flere tilsluttede tabeller (kaldet en relationsdatabase – som vist i figur 2.2).

hver tabel består af felter og poster. Felter er de kategorier, du vil optage data for. For eksempel indeholder musiktabellen vist ovenfor felter som titel, kunstner, varighed og Album. Poster henviser til de faktiske data, der fanges, hvor hver post indeholder dataene for et enkelt element. For eksempel repræsenterer hver post i Sangtabellen en enkelt sang med alle de oplysninger (som kunstner og varighed), der er relateret til den sang.

hver tabel kan have et obligatorisk felt, kaldet en primær nøgle, som indeholder en unik identifikator for hver post i databasen. Dette giver dig mulighed for at henvise til en bestemt post på en tabel på en sådan måde, at den kun kunne henvise til en post. Selvom det er muligt at gøre et eksisterende felt i en tabel til et nøglefelt, opretter databaseskabere normalt et nyt felt specifikt til dette formål. Dette giver dem mulighed for at sikre, at der ikke er dubletter.

nogle gange er der anomalier med databaser, du vil lære at slippe af med disse anomalier.

i dette kapitel vil du designe og oprette en relationsdatabase. Nogle gange er der uregelmæssigheder med databaser, du vil lære at slippe af med disse og nå normalisering.

databaser i en nøddeskal

Data, i princippet, gemmes i 1s og 0s. Computeren skal stadig vide, hvordan disse 1 ‘er og 0’ er er organiseret, og hvordan de skal fortolkes. For at gøre dette bruger computere datastrukturer, der beskriver en bestemt sekvens for data, der skal organiseres. Dette gør det muligt for computeren at forstå, hvordan de forskellige databit er relateret, og at fortolke dataene korrekt.

vi ved, at hvert bogstav i alfabetet repræsenterer et tegn. Når du tilføjer nok tegn sammen, danner de et ord (som ‘orange’ eller ‘kærlighed’), der repræsenterer et koncept. Derfor tillader kommunikation af nyttige oplysninger mellem to eller flere personer – selv på tværs af afstande.

for at kommunikere data og instruktioner konverteres data som tal, bogstaver, tegn, specielt symbol, lyde/fonetik og billeder til computerlæsbar form (binær). Når behandlingen af disse data er afsluttet, konverteres den til menneskeligt læsbart format, de behandlede data bliver meningsfuld information. Oplysningerne bliver viden og kan forstås og bruges af mennesker til forskellige formål.

UNIT2.1 Egenskaber ved en god database

alle gode databaser skal begynde med værdifulde metadata og data. I kapitel 1 kiggede vi på egenskaberne ved værdifulde data, og hvordan man administrerer disse data. Disse er illustreret i figur 2.3 nedenfor:

lad os nu se på egenskaberne ved en god database:

• databasen skal være stærk nok til at gemme alle relevante data og krav.
• skal kunne relatere tabellerne i databasen ved hjælp af en relation, for eksempel arbejder en medarbejder for en afdeling, så medarbejderen er relateret til en bestemt afdeling. Vi bør være i stand til at definere et sådant forhold mellem to enheder i databasen.
• flere brugere skal kunne få adgang til den samme database uden at påvirke den anden bruger. For eksempel kan flere lærere arbejde på en database for at opdatere elevernes karakterer på samme tid. Lærere bør også have lov til at opdatere karaktererne for deres fag uden at ændre andre fagmærker.
• en enkelt database giver forskellige visninger til forskellige brugere, den understøtter flere visninger til brugeren afhængigt af hans rolle. I en skoledatabase, for eksempel, lærere kan se opdelingen af elevernes karakterer; forældre er dog kun i stand til kun at se deres barns rapport – således ville forældrenes adgang kun læses. Samtidig vil lærerne have adgang til alle elevernes oplysninger og vurderingsoplysninger med ændringsrettigheder. Alt dette kan ske i samme database.
• dataintegritet refererer til, hvor nøjagtige og konsistente dataene i en database er. Databaser med masser afmanglende oplysninger og forkerte oplysninger siges at have lav dataintegritet.
• datauafhængighed refererer til adskillelsen mellem data og den applikation (eller applikationer), hvoriden bruges. Dette giver dig mulighed for at opdatere dataene i din applikation (såsom at rette en stavefejl)uden at skulle kompilere hele applikationen igen.
• dataredundans refererer til at have nøjagtigt de samme data forskellige steder i databasen. Dataredundans øger databasens størrelse, skaber integritetsproblemer, reducerer effektiviteten og fører til anomalier. Data skal gemmes, så de ikke gentages i flere tabeller.
• datasikkerhed refererer til, hvor godt dataene i databasen er beskyttet mod nedbrud, hacks ogtilfældig sletning.
• Datavedligeholdelse refererer til månedlige, daglige eller timelige opgaver, der køres for at rette fejl i en databaseog forhindre uregelmæssigheder i at forekomme. Databasevedligeholdelse løser ikke kun fejl, men det registrerer også potentielle fejl og forhindrer fremtidige fejl i at opstå.

der er også mange mennesker involveret i at organisere en veldrevet database. Disse er:

• udviklerne, der designer og udvikler databasen, så den passer til en virksomheds behov
• administratoren, der:
• kontrollerer databasen for dens anvendelser
• hvem kontrollerer den
• giver adgang til andre anvendelser
• giver ethvert andet vedligeholdelsesarbejde, der kræves for at holde databasen oppe til dato
• slutbrugeren, der bruger databasen, for eksempel lærere eller forældre.

UNIT2.2 problemer med databaser

hvis en fladfildatabase er dårligt planlagt, denormaliseret og inkonsekvent, vil det skabe problemer, når du prøver at indsætte, slette eller ændre posterne (tabeller) i databasen. Dette medfører uregelmæssigheder, hvilket gør håndteringen af dataene stadig vanskeligere, når databasen vokser. Det gør også dataintegriteten sværere at vedligeholde. At forsøge at gøre dataene konsistente, når en anomali opstår, kan blive ret vanskelig.

der er tre typer problemer, der kan opstå i databaser:

• indsættelse anomali: Databasen er oprettet på en sådan måde, at krævede data ikke kan tilføjes, medmindre der også tilføjes et andet stykke utilgængelige data. For eksempel en hospitalsdatabase, der ikke kan gemme detaljerne om et nyt medlem, før det pågældende medlem er blevet set af en læge.
• Sletningsanomali: den legitime sletning af en registrering af data kan forårsage sletning af nogle krævede data. For eksempel kan sletning af nogle af patientens detaljer fjerne alle detaljer om patienten fra hospitalsdatabasen.
• ændring anomali: Forkerte data skal muligvis ændres, hvilket kan medføre, at mange poster skal ændres, hvilket fører til muligheden for, at nogle ændringer foretages forkert.

eksempel 2.1 problemer, der opstår i en database

UNIT2.3 Sådan slipper du af anomalier

for at forhindre anomalier skal du normalisere databasen ved effektivt at organisere dataene i en database.
ifølge Edgar f Codd, opfinderen af relationsdatabaser, inkluderer målene for normalisering:

• fjernelse af alle overflødige (eller gentagne) data fra databasen
• fjernelse af uønskede indsættelser, opdateringer og sletningsafhængigheder
• reduktion af behovet for at omstrukturere hele databasen, hver gang der tilføjes nye felter
• gør forholdet mellem tabeller mere nyttigt og forståeligt.

normalisering er en systematisk tilgang til nedbrydning af tabeller for at eliminere data redundans og indsættelse, ændring og sletning anomalier. Databasedesigneren strukturerer dataene på en måde, der eliminerer unødvendige duplikeringer og giver en hurtig søgevej til alle nødvendige oplysninger. Det er en flertrinsproces, der sætter data i tabelform, fjerner duplikerede data fra relationstabellerne. Denne proces med at specificere og definere tabeller, nøgler, kolonner og relationer for at skabe en effektiv database kaldes normalisering.

normalisering reducerer mængden af plads, som en database bruger, og sikrer, at data gemmes effektivt. Uden normalisering kan databasesystemer være unøjagtige, langsomme og ineffektive. De producerer muligvis ikke de data, du forventer.

i praksis betyder det at ændre din database, så følgende krav er opfyldt:

• hver tabel skal have en primær nøgle
• hver post skal have enkeltværdige attributter/kolonner (atomic)
• der bør ikke være gentagne grupper af oplysninger.

nøgler bruges til at etablere og identificere relationer mellem tabeller og også til entydigt at identificere enhver post eller række af data i en tabel. En nøgle kan være en enkelt attribut eller en gruppe af attributter (compositeprimary key), hvor kombinationen kan fungere som en nøgle. Nøgler hjælper os med at identificere enhver række data.

når du designer en database, er de fire typer nøglefelter:

• primær nøgle: det felt, der er valgt af databaseskaberen til entydigt at identificere hver post på en tabel. For eksempel kan hver sang i din musikdatabase have et primært nøglefelt kaldet “song_id”.
• alternativ nøgle: et felt, der indeholder entydige værdier, der kan bruges som den primære nøgle, men som i øjeblikket ikke er angivet som den primære nøgle, f.eks. artist_id.
• fremmed nøgle: et felt, der indeholder værdier fra en anden tabels primære nøglefelt. Udenlandske nøgler bruges til at vise forholdet mellem forskellige tabeller. For eksempel kan hver sang i din musikdatabase have et fremmed nøglefelt kaldet “artist_id”, der forbinder sangen med en bestemt kunstner på en “Kunstnere” – tabel.
• sammensat nøgle: en kombination af mere end et felt, der entydigt identificerer hver post på en tabel, for eksempel song_id og artist_id.

lad os bruge dette eksempel til at forstå de fire hovedtyper af nøgler:

Normaliseringsregler er opdelt i følgende normale former:

første normale FORM (1NF)

for at en tabel skal være i den første normale Form, skal den følge følgende fire regler:

• hver kolonne skal have et separat felt / attribut. Hver kolonne i tabellen bør ikke indeholde flere værdier. Databasen for Facebook-statusopdateringer, specifikt tabellen relateret til likes. For at posterne skal være udelelige, skal hver lignende opbevares i en separat post. På denne måde ville hver post enten have fundet sted eller ikke fundet sted. Der er ingen måde at sige, at kun en lille del af lignende skete, mens en anden del ikke gjorde det. Men hvis alle likes til en statusopdatering er gemt i en enkelt post, ville posten være delelig, da det ville være muligt for nogle af likes at have fundet sted, mens andre ikke forekom.
• værdier, der er gemt i en kolonne, skal være af samme art eller type (domæne). I hver kolonne skal de lagrede værdier være af samme art eller type.
• alle kolonnerne i en tabel skal have entydige navne. Hver kolonne i en tabel skal have et unikt navn for at undgå forvirring på tidspunktet for hentning af data eller udførelse af enhver anden handling på de lagrede data. Angiv for eksempel barnets navn og forældres navn, Brug ikke ‘Navn’.
• den rækkefølge, som data gemmes i, betyder ikke noget. For eksempel

• tabellen overholder tre regler ud af de fire regler: kolonnenavnene er unikke, de lagrede data er i den rigtige rækkefølge, og der er ingen blandede forskellige typer data i kolonnerne. Eleverne i tabellen har dog valgt mere end et emne. Disse data er blevet gemt i emnenavnene i en enkelt kolonne. I henhold til 1NF skal hver kolonne indeholde en enkelt værdi.

anden NORMAL FORM (2NF)

for en tabel at være i den anden normale Form:

• det skal være i den første normale Form.
• og det bør ikke have delvis afhængighed.

det er her, en attribut i en tabel kun afhænger af en del af den primære nøgle og ikke af hele nøglen. For eksempel registrerer en tabel de primære nøgler som student_id og subject_id for hver elev. Kun lærerens navn afhænger af emnet. Så, subject_id, og har intet at gøre med student_id.

tredje normale FORM (3NF)

en tabel siges at være i den tredje normale Form, når:

• det er i den anden normale Form.
• det har ikke Transitiv afhængighed. Transitiv afhængighed opstår, når en attribut/et felt afhænger af andre attributter/felter i stedet for at afhænge af den primære nøgle.

dette er et indirekte forhold mellem værdier i samme tabel.