Relasjonsdatabase. Tanken om en relasjonsdatabase

Fremveksten av datateknologi i vår moderne informasjonsteknologi markerte en revolusjon i alle sfærer av menneskelig aktivitet. Men til all informasjon ikke blir unødvendig avfall på internett, ble oppfunnet av databasesystemet, hvor materialene er sortert, systematisert, med det resultat at de er enkle å finne og sende den påfølgende behandling. Det er tre hovedvarianter - bevilge database relasjonelle, hierarkisk, nettverk.

grunnleggende modeller

Retur til fremveksten av databaser, bør det sies at denne prosessen var ganske komplisert, det stammer med utviklingen av en programmerbar informasjon prosessutstyr. Det er ikke overraskende at antall modeller i dag når mer enn 50, men de viktigste er ansett for å være hierarkisk, relasjonell og nettverk, som fortsatt er mye brukt i praksis. Hva representerer de?

Hierarkisk database har en trestruktur og er sammensatt av data fra forskjellige nivåer, mellom hvilke det er kommunikasjon. Network database modellen er en mer komplisert mønster. Dens struktur ligner et hierarki, og ordningen utvides og forbedres. Forskjellen mellom dem er at de arvelige hierarkiske datamodeller kan knyttes sammen med bare en stamfar, mens nettverket kan være flere. Strukturen av en relasjonsdatabase er mye mer kompleks. Derfor bør det være demontert nærmere.

Det grunnleggende konseptet med en relasjonsdatabase

Denne modellen ble utviklet i 1970 av Dr. Edgar F. Codd vitenskap. Det er en logisk oppbygd bord med felt som beskriver dataene, deres relasjoner med hverandre, operasjoner utført på dem, og aller viktigst - de regler som garanterer deres integritet. Hvorfor det kalles relasjonsmodellen? Den er basert på forholdet (fra latin. Relatio) mellom data. Det finnes mange definisjoner av denne type database. Relasjonelle tabeller med informasjon er mye lettere å organisere og gi behandling, snarere enn et nettverk eller hierarkisk modell. Hvordan du gjør det ikke? Det er nok til å vite funksjonene, modellen strukturen og egenskapene til relasjonstabeller.

Prosessen med modellering og grunnleggende elementer

For å lage din egen database, bør du bruke en av modelleringsverktøy for å tenke med hva slags informasjon du trenger for å jobbe, for å utforme et relasjonelt bord og én og flere koblinger mellom data enheter for å fylle cellen og angi primær eller fremmednøkler.

Modellering tabeller og designe relasjonsdatabaser er utført gjennom gratis verktøy som Workbench, PhpMyAdmin, Case Studio, dbForge Studio. Etter detaljert design for å redde den grafiske ferdige relasjonsmodellen og oversette den til en SQL-ready-kode. På dette stadiet, kan du begynne å jobbe med data sortering, bearbeiding og systematisering.

Funksjoner av strukturen og betingelser som er knyttet til relasjonsmodellen

Hver kilde i sin egen måte beskriver dens elementer, så jeg vil gjerne gi et lite hint for mindre forvirring:

• relasjons label = natur;
• Oppsettet = attributtnavn = golf = kolonneoverskrift enhet;
• enhet tilfellet = tuppel = record = plate linje;
• attributt = verdi = celle-enheter felt.

Å gå til en relasjonsdatabase egenskaper bør være klar over noen grunnleggende komponenter det består av, og som de er tiltenkt.

1. Essens. Tabell relasjonsdatabase kan være en, eller kan være et sett med tabeller som karakteriserer beskrevne gjenstander som er lagret i denne gjennom dataene. De har et fast antall felt, og et variabelt antall oppføringer. Tabell relasjonsdatabase modell er sammensatt av strenger, attributter, og layout.
2. Recording - et variabelt antall rader som viser dataene som karakteriserer den beskrevne gjenstand. Nummerering av oppføringer gjort automatisk av systemet.
3. Attributter - data som viser et SAMMENDRAG kolonner.
4. Field. Det er en enhet kolonne. Deres antall - den faste verdi settes under opprettelsen eller modifikasjon av tabellen.

Nå vet de konstituerende elementene i tabellen, kan du gå videre til egenskapene til relasjonsmodellen database:

• Essensen av to-dimensjonale relasjonsdatabase. På grunn av denne eiendommen med dem lett prodelyvat ulike logiske og matematiske operasjoner.
• Rekkefølgen av attributtverdier og poster i en relasjons tabell kan være tilfeldig.
• Kolonner i en relasjons tabellen må ha sin egen unike navn.
• Alle data i kolonnen i det vesentlige har en fast lengde og den samme type.
• En oppføring i hovedsak regnes som en del av data.
• Bestanddeler av radene er unike. Relasjons natur ikke er like rader.

Basert på egenskapene til relasjonsdatabasen, er det underforstått at verdiene av attributter bør være av samme type, lengde. Vurdere en bestemt attributtverdier.

De viktigste karakteristika for feltene i relasjonsdatabaser

Feltnavn må være unike innenfor en enkelt enhet. De typer attributter eller felt av relasjonsdatabaser beskriver en kategori av data som er lagret i enheten feltene. Felt relasjonsdatabase må ha en fast størrelse, som er beregnet på tegn. Parametere og formatere attributtverdier definerer måte for å korrigere sine data. Likevel er det noe slikt som en "maske" eller "input mal". Den er utformet for å bestemme konfigurasjonen av datainngang i attributtverdien. Gjerne på feil registrering type data skal utstedes til en feilrapport i feltet. Også på feltet elementene er noen begrensninger - forhold for å sjekke nøyaktigheten og presisjonen av dataregistrering. Det er en obligatorisk attributtverdi som unikt må fylles med data. Noen attributt linjen kan bli fylt med NULL-verdier. Tillatt å legge inn de tomme datafelt attributter. Som med en feilrapport, det er verdier som er fylt automatisk av systemet - dette er standard data. For å få fortgang i jakten på data ment indeksert felt.

Skjema dimensjonal relasjonsdatabasetabell

For en detaljert forståelse av styringssystemet modellen ved hjelp av SQL best å vurdere ordningen som et eksempel. Vi vet allerede hva er en relasjonsdatabase. En oppføring i hver tabell - en enkelt dataelement. For å forhindre dataredundans, som er nødvendig for å normalisere operasjonen.

De grunnleggende regler for normalisering av relasjons natur

1. Verdien av feltnavn for en relasjons tabellen må være unik, one of a kind (First Normal Form - 1NF).

2. For en tabell som allerede er blitt redusert til 1NF, ikke-identifiserende navnet på en kolonne for å være avhengig av en unik identifikator bord (2NF).

3. For alle tabeller som allerede er lagret i 2NF, ikke identifiserer hvert felt kan være uavhengig av andre uidentifiserte elementverdier (3NF enhet).

Databaser: relasjonelle lenker mellom tabeller

Det er 2 hovedtyper av relasjoner av relasjonelle tabletter:

• "One-mange". Ifølge oppstår når en nøkkel tabellpost №1 flere forekomster av den andre enhet. Key ikonet på en av endene av den tegnede linjen viser at stoffet er på siden av "en", den andre enden av linjen er ofte et symbol på uendelighet mark.

• Kommunikasjon "mange-mange" dannet i tilfelle av flere rader en logisk enhet eksplisitt samspill med en rekke registreringer av en annen tabell.
• Hvis to enheter er det en sammenkjeding av "en til en", betyr det at nøkkelen identifikatoren til et bord er til stede i den annen enhet, så er det nødvendig å fjerne en av tabellene, det er overflødig. Men noen ganger bare for sikkerhets programmerere bevisst skille de to enhetene. Derfor hypotetisk, sammenhengen mellom "en til en" kan eksistere.

Eksistensen av nøklene i en relasjonsdatabase

Primær- og sekundærnøkler identifisere potensielle database relasjoner. Relasjons datakommunikasjon modellen kan ha bare en kandidatnøkkel, vil det være primærnøkkel. Hva er det? Primærnøkkel - en kolonne eller et sett med attributter av essensen, der du kan få tilgang til en bestemt datalinje. Det må være unikt, den eneste, og feltene kan ikke inneholde nullverdier. Hvis hovednøkkelen består av bare ett attributt, så det sies å være enkel, ellers vil være.

Foruten primærnøkkel, eksisterer og eksterne (fremmednøkkel). Mange forstår ikke hva forskjellen mellom dem. La oss undersøke dem nærmere som et eksempel. Så er det to tabeller: "Dean" og "studenter". Essensen av "Dean" inneholder felt: "Group" "ID-studenten", "Name" og Tabell "studenter" har attributtverdier som "Name", "Gruppe" og "gjennomsnittlig". Så som en student-ID ikke kan være det samme for noen elever, er det feltet for å være primærnøkkelen. "Navn" og "Group" fra "studenter" i tabellen kan være det samme for noen mennesker, de refererer til studentens ID-nummer fra essensen av "Dean", slik at de kan brukes som en fremmednøkkel.

Et eksempel på et relasjonsdatabase-modellen

For klarhets skyld, gir vi et enkelt eksempel på et relasjonsdatabase-modell som består av to enheter. Det er en tabell med navnet "Dean".

Det er nødvendig å gjennomføre forbindelse å få en full relasjonsdatabase. Entry "IN-41" samt "IN-72", kan være mer til stede enn en gang i tabellen "Dean" som etternavn, navn og patronymikon av studentene, i sjeldne tilfeller kan være det samme, slik at disse feltene kan ikke være å gjøre primærnøkkelen. essensen av "Studenter" vil vise.

Som vi kan se, hvilke typer relasjonsdatabasefelt varierer helt. Present som digitale opptak og karakter. Derfor bør attributtinnstillingene indikerer verdien av heltall, røye, vachar, dato og andre. I "Dean" unik verdi er den eneste studentbevis. Dette feltet kan tas som en primærnøkkel. Navn, artist, og telefonen fra essensen av "studenter" kan tas som en fremmednøkkel refererer IDen til studenten. Tilkoblingen er opprettet. Dette er et eksempel på en kommunikasjons modell av "en til en". Hypotetisk, en av de ekstra bord, de kan enkelt kombineres i en enkelt enhet. Til ID-nummeret av studentene ikke blir allment kjent, er det fullt mulig at det er to tabeller.