Er du klar til å begynne å lage databaser og tabeller med Strukturert spørrespråk? I denne artikkelen undersøker vi prosessen med å lage tabeller manuelt med kommandoene CREATE DATABASE og CREATE TABLE. Hvis du ikke har brukt SQL før, kan det være lurt å gjennomgå noen Grunnleggende om SQL først.
Forretningskrav
Før vi setter oss ned ved tastaturet, må vi sørge for at vi har en solid forståelse av kundens krav. Hva er den beste måten å få denne innsikten på? Å snakke med kunden, selvfølgelig! Etter å ha satt oss ned med XYZs personaldirektør, har vi lært at de er et widget-salgsselskap og primært er interessert i å spore informasjon om deres salgspersonell.
XYZ Corporation deler sin salgsstyrke i østlige og vestlige regioner, som hver er delt inn i mange territorier dekket av individuelle salgsrepresentanter. HR-avdelingen vil spore territoriet som dekkes av hver ansatt, samt hver ansattes lønnsinformasjon og tilsynsstruktur. For å oppfylle disse kravene har vi designet en database som består av tre tabeller, vist i Enhets-forhold diagram på denne siden.
Velge en databaseplattform
Vi har bestemt oss for å bruke en databasestyringssystem (eller DBMS) som er bygget på Structured Query Language (SQL). Derfor bør alle kommandoene for database- og tabelloppretting skrives med tanke på standard ANSI SQL.
Som en ekstra fordel, vil bruk av ANSI-kompatibel SQL sikre at disse kommandoene fungerer på alle DBMS som støtter SQL-standarden, inkludert Oracle og Microsoft SQL Server. Hvis du ikke har valgt en plattform for databasen din ennå, veileder Database Software Options deg gjennom valgprosessen.
Opprette databasen
Vårt første skritt er å lage selve databasen. Mange databasestyringssystemer tilbyr en rekke alternativer for å tilpasse databaseparametere på dette trinnet, men databasen vår tillater bare enkel oppretting av en database. Som med alle våre kommandoer, kan det være lurt å lese dokumentasjonen for DBMS for å finne ut om noen avanserte parametere som støttes av ditt spesifikke system, oppfyller dine behov. La oss bruke CREATE DATABASE-kommandoen til å sette opp databasen vår:
OPPRETT DATABASE-personell
Legg spesielt merke til bruk av store bokstaver i eksemplet ovenfor. Det er vanlig praksis blant SQL-programmerere å bruke alle store bokstaver for SQL-nøkkelord som "CREATE" og "DATABASE" mens du bruker alle små bokstaver for brukerdefinerte navn som "personell" -databasen Navn. Disse konvensjonene gir enkel lesbarhet.
Nå som vi har designet og opprettet databasen vår, er vi klare til å begynne å lage de tre tabellene som brukes til å lagre personaldata for XYZ Corporation.
Lage vårt første bord
Vår første tabell består av personopplysninger for hver ansatt i selskapet vårt. Vi må inkludere hver ansattes navn, lønn, ID og leder. Det er god designpraksis å skille etter- og fornavn i separate felt for å forenkle datasøk og sortering i fremtiden. Vi vil også holde oversikt over hver ansattes leder ved å sette inn en referanse til lederens ansatt-ID i hver ansattjournal. La oss først se på ønsket ansattstabell.
ReportsTo-attributtet lagrer leder-ID for hver ansatt. Fra eksemplene som vises, kan vi fastslå at Sue Scampi er manager for både Tom Kendall og John Smith. Imidlertid er det ingen informasjon i databasen om Sue's manager, som angitt av NULL-oppføringen i hennes rekke.
Nå kan vi bruke SQL til å lage tabellen i personaldatabasen vår. Før vi gjør det, la oss forsikre oss om at vi er i riktig database ved å utstede en USE-kommando:
BRUK personell;
Alternativt kan "DATABASE-personellet;" kommandoen vil utføre den samme funksjonen. Nå kan vi ta en titt på SQL-kommandoen som ble brukt til å lage våre ansattes tabell:
OPPRETT TABELL medarbeidere
(ansattid INTEGER IKKE NULL,
etternavn VARCHAR (25) IKKE NULL,
fornavn VARCHAR (25) IKKE NULL,
rapporter til INTEGER NULL);
Som med eksemplet ovenfor, vær oppmerksom på at programmeringskonvensjonen tilsier at vi bruker alle store bokstaver for SQL-nøkkelord og små bokstaver for brukernavn kolonner og tabeller. Kommandoen ovenfor kan virke forvirrende i begynnelsen, men det er faktisk en enkel struktur bak den. Her er en generell visning som kan rydde opp litt:
OPPRETT TABELL tabellnavn
(attributtnavn datatypealternativer,
...,
attype_name datatype-alternativer);
Attributter og datatyper
I forrige eksempel er tabellnavnet ansatte og vi inkluderer fire attributter: ansatt-ID, etternavn, fornavn og rapport til. Datatypen angir hvilken type informasjon vi ønsker å lagre i hvert felt. Medarbeider-ID er et enkelt heltall, så vi bruker INTEGER-datatypen for både medarbeider-feltet og rapport til-feltet. Navnene på de ansatte vil være tegnstrenger med variabel lengde, og vi forventer ikke at noen ansatte har et for- eller etternavn som er lengre enn 25 tegn. Derfor bruker vi VARCHAR (25) -typen for disse feltene.
NULL Verdier
Vi kan også spesifisere enten NULL eller IKKE NULL i alternativfeltet i CREATE-setningen. Dette forteller ganske enkelt databasen om NULL (eller tomme) verdier er tillatt for det attributtet når du legger til rader i databasen. I vårt eksempel krever HR-avdelingen at en ansattes ID og fullstendig navn lagres for hver ansatt. Imidlertid har ikke alle ansatte en leder (administrerende direktør rapporterer til ingen!), Så vi tillater NULL-oppføringer i det feltet. Vær oppmerksom på at NULL er standardverdien, og å utelate dette alternativet vil implisitt tillate NULL-verdier for et attributt.
Bygg de gjenværende bordene
La oss nå ta en titt på territorietabellen. Fra en rask titt på disse dataene ser det ut til at vi trenger å lagre et heltall og to strenger med variabel lengde. Som med vårt forrige eksempel, forventer vi ikke at region-IDen bruker mer enn 25 tegn. Noen av områdene våre har imidlertid lengre navn, så vi utvider den tillatte lengden på dette attributtet til 40 tegn.
La oss se på den tilsvarende SQL:
OPPRETT TABELL territorier
(territorium INTEGER IKKE NULL,
territorium Beskrivelse VARCHAR (40) IKKE NULL,
regionid VARCHAR (25) NOT NULL);
Til slutt bruker vi tabellen EmployeeTerritories til å lagre forholdet mellom ansatte og territorier. Detaljert informasjon om hver ansatt og territorium er lagret i de to foregående tabellene. Derfor trenger vi bare å lagre de to heltallidentifikasjonsnumrene i denne tabellen. Hvis vi trenger å utvide denne informasjonen, kan vi bruke en JOIN i våre datautvalgskommandoer for å få informasjon fra flere tabeller.
Denne metoden for lagring av data reduserer redundansen i databasen vår og sikrer optimal bruk av plass på lagringsstasjonene våre. Vi vil dekke JOIN-kommandoen grundig i en fremtidig opplæring. Her er SQL-koden for å implementere finaletabellen vår:
OPPRETT TABELL ansattlokaler
(ansattid INTEGER IKKE NULL,
territoriumid INTEGER IKKE NULL);
Mekanismen SQL gir for å endre strukturen til en database etter opprettelsen
Hvis du er spesielt kløktig i dag, har du kanskje lagt merke til at vi "ved et uhell" utelatt et av designkravene når vi implementerte databasetabellene våre. XYZ Corporations HR-direktør ba om at databasen spore lønnsinformasjon for de ansatte, og vi forsømte å sørge for dette i databasetabellene vi opprettet.
Imidlertid er ikke alt tapt. Vi kan bruke ALTER TABLE-kommandoen for å legge til dette attributtet i vår eksisterende database. Vi ønsker å lagre lønnen som et heltall. Syntaksen er ganske lik kommandoen CREATE TABLE, her er den:
ALTER TABLE ansatte
LEGG TIL LØNN INTEGER NULL;
Legg merke til at vi spesifiserte at NULL-verdier er tillatt for dette attributtet. I de fleste tilfeller er det ikke noe alternativ når du legger til en kolonne i en eksisterende tabell. Dette skyldes at tabellen allerede inneholder rader uten oppføring for dette attributtet. Derfor setter DBMS automatisk inn en NULL-verdi for å fylle tomrommet.