I dag vil vi gå til datamaskinemnet, så denne artikkelen vil først og fremst være av spesiell interesse for programmerere. Vi, kjære leser, vil snakke om språket til strukturerte spørringer, som på engelsk er kryptert som SQL (Structured Query Language). Så la oss komme til poenget. La oss nå snakke om hva SQL er og hva det trengs til.

Structured Query Language er et universelt språk for å lage, endre og administrere informasjon som er en del av relasjonsdatabaser. I utgangspunktet var SQL hovedmåten å jobbe med data på. Ved å bruke den kan brukeren utføre følgende handlinger:

• lage en ny tabell i databasen (DB);
• legge til nye poster til eksisterende tabeller;
• redigering av poster;
• fullstendig sletting av poster;
• velge en post fra forskjellige tabeller i samsvar med spesifiserte forhold;
• endre utseendet og strukturene til en eller flere tabeller.

Etter hvert som det utviklet seg, endret SQL seg kraftig og ble beriket med nye nyttige funksjoner, som et resultat av at det begynte å ligne mer og mer på et ekte programmeringsspråk. I dag er SQL den eneste mekanismen som kan koble sammen applikasjonsprogramvare og en database. Det er det SQL er.

SQL har flere typer spørringer. Det er verdt å merke seg at enhver SQL-spørring innebærer enten en forespørsel om data fra den ønskede databasen, eller en tilgang til databasen med obligatorisk endring av data i den. I denne forbindelse er det vanlig å skille mellom følgende typer forespørsler:

• opprette eller endre nye eller eksisterende objekter i databasen;
• mottar data;
• legge til nye data i tabellen;
• sletting av data;
• tilgang til et databasestyringssystem (DBMS).

Litt om fordeler og ulemper med dette databehandlingssystemet.

Fordeler med SQL

• Uavhengighet fra eksisterende DBMS i det gitte systemet. SQL-tekster er universelle for mange DBMS-er. Denne regelen gjelder imidlertid for enkle oppgaver knyttet til behandling av data i tabeller.
• Tilstedeværelsen av SQL-standarder bidrar til å "stabilisere" språket.
• Deklarativitet. Denne fordelen er at når du arbeider med data, velger programmereren kun informasjonen som må endres eller modifiseres. Hvordan dette skal gjøres avgjøres automatisk på programvarenivået til selve DBMS.

Ulemper med SQL

• SQL følger ikke relasjonsdatamodellen. I denne forbindelse erstatter SQL Tutorial D-språket, som virkelig er relasjonelt.
• Kompleksiteten til SQL bestemmer formålet. Språket er så komplekst at bare en programmerer kan bruke det. Selv om det opprinnelig ble tenkt som et kontrollverktøy som den gjennomsnittlige brukeren ville jobbe med.
• Noe inkonsekvens i standarder. Mange selskaper som utvikler DBMS legger til sine egne funksjoner til SQL-språkdialekten, noe som i betydelig grad påvirker universaliteten til språket.

En siste ting: hva er SQL Server? Dette er et databasestyringssystem som ble utviklet innenfor veggene til det kjente selskapet Microsoft. Dette systemet fungerer med suksess med databaser av både personlige datamaskiner og store databaser med store bedrifter. I dette markedssegmentet er SQL Server mer enn konkurransedyktig.

Vel, la oss huske MySQL i et nøtteskall. Denne applikasjonen brukes vanligvis som en server som mottar forespørsler fra lokale eller eksterne klienter. MySQL kan også inkluderes i frittstående programmer. Det skal bemerkes at denne applikasjonen er en av de mest fleksible databehandlingssystemene, siden den inkluderer mange forskjellige typer tabeller.

Hovedfunksjonaliteten til SQL-språket er gitt nedenfor.

Definisjon av data. Denne SQL-funksjonen er en beskrivelse av strukturen til dataene som støttes og organiseringen av relasjonsrelasjoner (tabeller). Operatører for å lage en database, lage tabeller og få tilgang til data er ment å implementere den.

Database opprettelse. For å opprette en ny database, bruk CREATE DATABASE-setningen. Utsagnsstrukturen spesifiserer navnet på databasen som skal opprettes.

Lage tabeller. Basistabellen opprettes ved å bruke CREATE TABLE-setningen. Denne setningen spesifiserer feltnavn, datatyper for dem og lengde (for noen datatyper). SQL bruker følgende datatyper:

HELTAL – heltall;

CHAR – tegnverdi;

VARCHAR – tegnverdi, bare ikke-blanke tegn lagres;

DESIMAL – desimaltall;

FLOAT – flyttallnummer;

DOBBEL PRESISJON – dobbel presisjon flytepunkt;

DATETIME – dato og klokkeslett;

BOOL – boolsk verdi.

Tabellopprettingssetningen spesifiserer restriksjoner på kolonneverdier og på tabellen. Mulige restriksjoner er vist i tabellen. 4.8

Tabell 4.8 Begrensninger på definerte data

For en relasjonsdatamodell er det viktig å spesifisere en fremmednøkkel (FOREIGNKEY). Når du erklærer fremmednøkler, må du legge passende begrensninger på kolonnen, for eksempel IKKE NULL.

I en SQL-setning angir CHECK semantiske begrensninger som sikrer dataintegritet, for eksempel å begrense settet med gyldige verdier for en bestemt kolonne.

Du kan ikke bruke create table-setningen mer enn én gang på samme tabell. Hvis det etter opprettelsen oppdages unøyaktigheter i definisjonen, kan endringer gjøres ved å bruke ALTER TABLE-setningen. Denne setningen er laget for å endre strukturen til en eksisterende tabell: du kan fjerne eller legge til et felt i en eksisterende tabell.

Datamanipulasjon. SQL lar en bruker eller et applikasjonsprogram endre innholdet i en database ved å sette inn nye data, slette eller endre eksisterende data.

Setter inn nye data er en prosedyre for å legge til rader i en database og utføres ved hjelp av INSERT-setningen.

Datamodifisering involverer endringer i verdier i en eller flere kolonner i en tabell og utføres ved hjelp av en UPDATE-setning. Eksempel:

SET beløp=beløp+1000,00

WHERE beløp>0

Fjerner rader fra en tabell som bruker DELETE-setningen. Operatorsyntaksen er:

FRA bordet

WHERE-klausulen er valgfri, men hvis den ikke er inkludert, vil alle oppføringer i tabellen bli slettet. Det er nyttig å bruke SELECT-setningen med samme syntaks som DELETE-setningen for å forhåndsteste hvilke poster som vil bli slettet.

Sikre dataintegritet. SQL-språket lar deg definere ganske komplekse integritetsbegrensninger, hvis tilfredsstillelse vil bli sjekket for alle databasemodifikasjoner. Overvåking av resultatene av transaksjoner, behandling av feil som oppstår og koordinering av parallelt arbeid med databasen for flere applikasjoner eller brukere er gitt av COMMIT (registrerer vellykket gjennomføring av gjeldende transaksjon og begynnelsen av en ny) og ROLLBACK (behovet for en tilbakeføring - automatisk gjenoppretting av databasetilstanden til begynnelsen av transaksjonen) operatører.

Datasampling er en av de viktigste databasefunksjonene som tilsvarer SELECT-setningen. Et eksempel på bruk av operatøren ble diskutert i forrige avsnitt.

I SQL kan du lage nestede sekvenser av spørringer (underspørringer). Det er visse typer spørringer som best implementeres ved hjelp av underspørringer. Disse spørringene inkluderer såkalte eksistenssjekker. La oss anta at du ønsker å få data om elever som ikke har syvpoengskarakter. Hvis et tomt sett returneres, betyr dette bare én ting - hver elev har minst én slik karakter.

Koble tabeller. SQL-setninger lar deg hente data fra mer enn én tabell. En måte å gjøre dette på er å koble tabeller ved hjelp av ett felles felt.

SELECT-setningen må inneholde en begrensning på å matche verdiene til en bestemt kolonne (felt). Da vil bare de radene der verdiene til den angitte kolonnen samsvarer, hentes fra de relaterte tabellene. Kolonnenavnet er kun angitt sammen med tabellnavnet; ellers vil uttalelsen være tvetydig.

Du kan bruke andre typer tabellkoblinger: INTER JOIN-operatoren (inner join) sikrer at det resulterende settet med poster inneholder samsvarende verdier i relaterte felt. Ytre sammenføyninger (OUTER JOIN) lar deg inkludere alle radene fra en tabell og de tilsvarende radene fra en annen i søkeresultatet

Adgangskontroll. SQL sikrer synkronisering av databasebehandling av ulike applikasjonsprogrammer og beskyttelse av data mot uautorisert tilgang.

Datatilgang i et flerbrukermiljø kontrolleres ved hjelp av GRANT- og REVOKE-setninger. I hver setning er det nødvendig å spesifisere brukeren, objektet (tabell, visning) som tillatelsene er satt til, og selve tillatelsene. For eksempel gir GRANT-setningen bruker X muligheten til å hente data fra PRODUCT-tabellen:

GI UTVALG PÅ PRODUKT TIL X

REVOKE-erklæringen tilbakekaller alle tidligere gitte tillatelser.

Innbygging av SQL i applikasjonsprogrammer. Ekte applikasjoner er vanligvis skrevet på andre språk som genererer SQL-kode og sender den til DBMS som ASCII-tekst.

IBM-standarden for SQL-produkter regulerer bruken av det innebygde SQL-språket. Når du skriver et applikasjonsprogram, er teksten en blanding av kommandoer fra hovedprogrammeringsspråket (for eksempel C, Pascal, Cobol, Fortran, Assembler) og SQL-kommandoer med et spesielt prefiks, for eksempel. ExecSQL. Strukturen til SQL-setninger har blitt utvidet for å imøtekomme vertsspråkvariabler i en SQL-konstruksjon.

SQL-prosessoren endrer typen program i samsvar med kravene til kompilatoren av hovedprogrammeringsspråket. Funksjonen til kompilatoren er å oversette (oversette) et program fra kildeprogrammeringsspråket til et språk nær maskinspråket. Etter kompilering er applikasjonsprogrammet (applikasjonen) en uavhengig modul.

SQL-dialekter

Moderne relasjonelle DBMS-er bruker dialekter av SQL-språket for å beskrive og manipulere data. Et undersett av SQL-språket som lar deg lage og beskrive en database kalles DDL (Data Definition Language).

Opprinnelig ble SQL-språket kalt SEQUEL (Structured English Query Language), deretter SEQUEL/2, og deretter ganske enkelt SQL. I dag er SQL de facto-standarden for relasjonelle DBMS-er.

Den første språkstandarden dukket opp i 1989 - SQL-89 og ble støttet av nesten alle kommersielle relasjons-DBMS-er. Den var generell og gjenstand for bred tolkning. Fordelene med SQL-89 kan betraktes som standardisering av syntaks og semantikk til operatører for sampling og datamanipulering, samt fiksering av midler for å begrense integriteten til databasen. Imidlertid manglet det en så viktig del som databaseskjemamanipulering. Ufullstendigheten til SQL-89-standarden førte til utseendet i 1992. neste versjon av SQL-språket.

SQL2 (eller SQL-92) dekker nesten alle nødvendige problemer: manipulering av databaseskjemaer, transaksjons- og øktadministrasjon, støtte for klient-server-arkitekturer eller applikasjonsutviklingsverktøy.

Neste steg i utviklingen av språket er versjonen av SQL 3. Denne versjonen av språket er supplert med en triggermekanisme, definisjonen av en vilkårlig datatype og en objektutvidelse.

For øyeblikket er det tre nivåer av språket: nybegynner, middels og komplett. Mange produsenter av deres DBMS bruker sine egne SQL-implementeringer, basert i det minste på startnivået til den tilsvarende ANSI-standarden, og inneholder noen utvidelser som er spesifikke for en bestemt DBMS. I tabellen 4.9 gir eksempler på SQL-dialekter.

Tabell 4.9 SQL-dialekter

DBMS	Spørrespråk
System R DBMS	SQL
DB2	SQL
Adgang	SQL
SYBASE SQL hvor som helst	Watcom-SQL
SYBASE SQL Server	Transact_SQL
Min SQL	SQL
Oracle	PL/SQL

Objektorienterte databaser bruker objektspørringsspråket OQL (Object Query Language). OQL-språket var basert på SELECT-kommandoen til SQL2-språket og la til muligheten til å dirigere en spørring til et objekt eller en samling av objekter, samt muligheten til å kalle metoder innenfor en enkelt spørring.

Kompatibiliteten til mange brukte SQL-dialekter bestemmer kompatibiliteten til DBMS. Dermed er SYBASE SQL Anywhere DBMS så kompatibel som mulig for en DBMS av denne klassen med SYBASE SQL Server DBMS. Et av aspektene ved denne kompatibiliteten er støtten i SYBASE SQL Anywhere av en slik dialekt av SQL-språket som Transact-SQL. Denne dialekten brukes i SYBASE SQL Server og kan brukes i SYBASE SQL hvor som helst sammen med den opprinnelige SQL-dialekten - Watcom-SQL.

Kontrollspørsmål

1. Hvordan kan et DBMS klassifiseres?

2. Hvilke databasemodeller finnes?

3. Hva er hovedelementene i informasjonsmodeller?

4. Hvilke typer relasjoner mellom enheter finnes?

5. Hva er ER-diagrammer og hva brukes de til?

6. Hva lar tabellnormaliseringsprosedyren deg gjøre?

7. Hva er språk- og programvareverktøyene til DBMS?

8. Hvilken type MS Access DBMS er det?

9. Hva er hovedobjektene til MS Access DBMS?

10. Hva brukes de viktigste SQL-operatorene til?

Structure Query Language (SQL) ble opprettet som et resultat av utviklingen av relasjonsdatamodellen og er for tiden de facto standardspråket for relasjonelle DBMS-er. SQL-språket i dag støttes av et stort antall DBMS av forskjellige typer.

Navnet på SQL-språket uttales vanligvis "es-qu-el". Noen ganger brukes det mnemoniske navnet "See-Quel".

SQL-språket gir brukeren (med minimal innsats fra hans side) følgende muligheter:

Lag databaser og tabeller med en fullstendig beskrivelse av deres struktur

Utfør grunnleggende datamanipulasjonsoperasjoner: sette inn, endre, slette data

Kjør både enkle og komplekse spørringer.

SQL-språket er relasjonsmessig komplett.

Strukturen og syntaksen til kommandoene er ganske enkle, og språket i seg selv er universelt, dvs. syntaksen og strukturen til kommandoene endres ikke når du flytter fra en DBMS til en annen.

SQL-språket har to hovedkomponenter:

DDL (Data Definition Language) for å definere databasestrukturer og kontrollere tilgang til data

DML (Data Manipulation Language) språk designet for å hente og oppdatere data.

SQL er et ikke-prosedyrespråk, noe som betyr at når du bruker det, må du spesifisere hvilken informasjon som skal innhentes, ikke hvordan den kan innhentes. SQL-kommandoer er vanlige engelske ord (SELECT, INSERT, etc.). La oss først se på SQL DML-setningene:

SELECT - velge data fra databasen

INSERT - setter inn data i en tabell

OPPDATERING - oppdatering av data i en tabell

SLETT - sletting av data fra en tabell

SELECT-setning

SELECT-operatoren utfører handlinger som tilsvarer følgende relasjonsalgebraoperasjoner: seleksjon, projeksjon og sammenføyning.

Den enkleste SQL-spørringen som bruker den, ser slik ut:

VELG kolonnenavn FRA tbl

Velg nøkkelordet etterfølges av en kommadelt liste over kolonner hvis data vil bli returnert av spørringen. Fra nøkkelordet spesifiserer fra hvilken tabell (eller visning) dataene hentes.

Resultatet av en utvalgsspørring er alltid en tabell kalt resultattabellen. Dessuten kan resultatene av en spørring utført ved hjelp av select-setningen brukes til å lage en ny tabell. Hvis resultatene av to spørringer på forskjellige tabeller har samme format, kan du kombinere dem til én tabell. Tabellen oppnådd som et resultat av en spørring kan også være gjenstand for ytterligere spørringer.

For å velge alle kolonner og alle rader i en tabell, utsted en SELECT * FROM tbl;

Tenk på produkttabellen, som inneholder prisinformasjon for ulike typer produkter:

Be om resultat

VELG * FRA Produkt;

vil være hele produkttabellen.

Du kan velge spesifikke tabellkolonner ved hjelp av en spørring

SELECT col1, col2, …, coln FRA tbl;

Så resultatet av forespørselen

VELG Type, Pris FRA Produkt;

det blir et bord

Listen over kolonner i select-setningen brukes også hvis det er nødvendig å endre rekkefølgen på kolonnene i den resulterende tabellen:

For å velge bare de tabellradene som tilfredsstiller visse begrensninger, brukes et spesielt nøkkelord, etterfulgt av en logisk betingelse. Hvis en post tilfredsstiller denne betingelsen, er den inkludert i resultatet. Ellers blir oppføringen forkastet.

For eksempel å velge de produktene fra produkttabellen hvis pris tilfredsstiller prisbetingelsen<3200, можно осуществить, используя запрос

VELG * FRA Produkt hvor Pris<3200;

Resultatet hans:

Betingelsen kan sammensettes og kombineres med de logiske operatorene NOT , AND, OR, XOR, for eksempel: hvor id_ Pris>500 AND Price<3500. Допускается также использование выражений в условии: where Price>(1+1) og strengkonstanter: der navn= "autovekter".

Ved å bruke BETWEEN var1 OG var2-konstruksjonen kan du sjekke om verdiene til et uttrykk faller innenfor området fra var1 til var2 (inkludert disse verdiene):

VELG * FRA Produkt hvor Pris MELLOM 3000 OG 3500;

I likhet med NOT MELLOM-operatoren, er det NOT IN-operatoren.

Kolonnenavn spesifisert i SELECT-leddet kan gis nytt navn. Til dette brukes søkeordet AS, som imidlertid kan utelates, siden det er implisitt. For eksempel forespørsel

VELG Type AS-modell, Type_id AS num FROM Produkt hvor Type_id =3

vil returnere (aliasnavn skal skrives uten anførselstegn):

LIKE-operatoren er designet for å sammenligne en streng med et mønster:

VELG * FRA tbl hvor col_name LIKE "abc"

Denne spørringen returnerer bare de postene som inneholder strengverdien abc i kolonnen col_name.

Eksemplet har lov til å bruke to jokertegn: "_" og "%". Den første av dem erstatter ett vilkårlig tegn i malen, og det andre erstatter en sekvens av vilkårlige tegn. Så, "abc%" samsvarer med en hvilken som helst streng som begynner med abc, "abc_" samsvarer med en 4-tegnsstreng som begynner med abc, "%z" samsvarer med en hvilken som helst streng som slutter med z, og til slutt, "%z%" - sekvenser av tegn som inneholder z.

Du kan finne alle poster i produkttabellen der Type-verdien begynner med bokstaven "a" slik:

VELG * FRA Produkt der Skriv LIKE "a%";

	lastebilvekter

Hvis søkestrengen inneholder et jokertegn, må du spesifisere escape-tegnet i ESCAPE-leddet. Dette kontrolltegnet må brukes i mønsteret før jokertegnet, noe som indikerer at jokertegnet skal behandles som et vanlig tegn. For eksempel, hvis du skulle søke etter alle verdier i et felt som inneholdt tegnet "_", vil mønsteret "%_%" resultere i at alle poster fra tabellen blir returnert. I dette tilfellet skal malen skrives som følger:

"%|_%" ESCAPE "|"

For å sjekke verdien for samsvar med strengen "20%" kan du bruke følgende operatør:

LIKE "20#%" ESCAPE "#"

Operatoren IS NULL lar deg sjekke fraværet (tilstedeværelsen) av en NULL-verdi i feltene i en tabell. Bruk av vanlige sammenligningsoperatorer i disse tilfellene kan gi ukorrekte resultater fordi sammenligning med NULL-resultater i UKJENT. Derfor bør valgbetingelsen se slik ut:

hvor col_name ER NULL, i stedet for hvor col_name=NULL.

Standardvalgresultatet returnerer poster i samme rekkefølge som de er lagret i databasen. Hvis du vil sortere poster etter en av kolonnene, må du bruke ORDER BY-leddet, etterfulgt av navnet på den kolonnen:

VELG * FRA tbl BESTILL ETTER col_name;

Denne spørringen vil returnere poster i stigende rekkefølge etter attributtverdien col_name.

Du kan også sortere poster etter flere kolonner. For å gjøre dette må navnene deres spesifiseres etter ORDER BY atskilt med komma:

VELG * FRA tbl BESTILL ETTER col_name1, col_name2.

Postene vil bli sortert etter feltet col_name1; hvis det er flere poster med en samsvarende verdi i kolonnen col_name1, vil de bli sortert etter feltet col_name2.

Hvis du vil sortere postene i omvendt rekkefølge (for eksempel synkende etter dato), må du angi ORDER BY col_name DESC.

For direkte sortering er det ASC-nøkkelordet, som er akseptert som standardverdi.

Hvis prøveresultatet inneholder hundrevis eller tusenvis av poster, tar produksjonen og behandlingen av dem betydelig tid.

Derfor blir informasjon ofte delt inn i sider og presentert for brukeren i porsjoner. Paginering brukes ved å bruke grenseordet etterfulgt av antall oppføringer som skal vises. Følgende spørring henter de første 10 postene samtidig som den sorteres bakover i feltet col_name1:

VELG * FRA tbl BESTILL ETTER col_name1 DESC LIMIT 10

For å hente de neste 10 postene, bruk grenseordet med to verdier: den første angir posisjonen som resultatet skal skrives ut fra, og den andre angir antall poster som skal hentes:

VELG * FRA tbl BESTILL ETTER col_name1 DESC LIMIT 10,10

For å hente de neste 10 postene må du bruke LIMIT 20, 10-konstruksjonen.

Leran2002 9. april 2015 kl. 12.31

En lærebok i SQL-språket (DDL, DML) med MS SQL Server-dialekten som eksempel. Del en

• SQL
• Microsoft SQL Server

• Opplæringen

Hva handler denne opplæringen om?

Denne opplæringen er noe sånt som et "minnestempel" i SQL-språket (DDL, DML), dvs. Dette er informasjon som har akkumulert i løpet av mine profesjonelle aktiviteter, og som stadig er lagret i hodet mitt. Dette er et tilstrekkelig minimum for meg, som brukes oftest når jeg jobber med databaser. Hvis det er behov for å bruke mer komplette SQL-konstruksjoner, henvender jeg meg vanligvis til MSDN-biblioteket på Internett for å få hjelp. Etter min mening er det veldig vanskelig å holde alt i hodet, og det er ikke noe særlig behov for dette. Men å kjenne de grunnleggende strukturene er veldig nyttig, fordi... de kan brukes i nesten samme form i mange relasjonsdatabaser, som Oracle, MySQL, Firebird. Forskjellene ligger hovedsakelig i datatypene, som kan variere i detalj. Det er ikke mange grunnleggende SQL-konstruksjoner, og med konstant øvelse blir de raskt lagret. For å lage objekter (tabeller, begrensninger, indekser osv.), er det for eksempel nok å ha et tekstredigeringsmiljø (IDE) for hånden for å jobbe med databasen, og det er ikke nødvendig å studere visuelle verktøy skreddersydd for å jobbe med en bestemt type database (MS SQL, Oracle, MySQL, Firebird, ...). Dette er også praktisk fordi all teksten er foran øynene dine, og du trenger ikke å gå gjennom mange faner for å lage for eksempel en indeks eller begrensning. Når du konstant jobber med en database, er det mange ganger raskere å lage, endre og spesielt gjenskape et objekt ved hjelp av skript enn hvis du gjør det i visuell modus. Også i skriptmodus (og følgelig med tilbørlig forsiktighet) er det lettere å sette og kontrollere reglene for navngivning av objekter (min subjektive mening). I tillegg er skript praktiske å bruke når endringer gjort i en database (for eksempel test) må overføres i samme form til en annen database (produktiv).

SQL-språket er delt inn i flere deler, her skal jeg se på de 2 viktigste delene:

• DML – Data Manipulation Language, som inneholder følgende konstruksjoner:
  • SELECT – datavalg
  • INSERT – setter inn nye data
  • OPPDATERING – dataoppdatering
  • SLETT – sletter data
  • MERGE – datasammenslåing

Fordi Jeg er en praktiker, det vil være lite teori som sådan i denne læreboken, og alle konstruksjoner vil bli forklart med praktiske eksempler. I tillegg tror jeg at et programmeringsspråk, og spesielt SQL, kun kan mestres gjennom praksis, ved å oppleve det selv og forstå hva som skjer når man utfører den eller den konstruksjonen.

Denne læreboken ble laget etter Step by Step-prinsippet, dvs. du må lese den sekvensielt og helst umiddelbart følge eksemplene. Men hvis du underveis trenger å lære om en bestemt kommando mer detaljert, så bruk et spesifikt søk på Internett, for eksempel i MSDN-biblioteket.

Når jeg skrev denne opplæringen, brukte jeg MS SQL Server versjon 2014-databasen, og jeg brukte MS SQL Server Management Studio (SSMS) for å utføre skriptene.

Kort om MS SQL Server Management Studio (SSMS)

SQL Server Management Studio (SSMS) er et verktøy for Microsoft SQL Server for å konfigurere, administrere og administrere databasekomponenter. Dette verktøyet inneholder en script editor (som vi hovedsakelig vil bruke) og et grafisk program som fungerer med serverobjekter og innstillinger. Hovedverktøyet til SQL Server Management Studio er Object Explorer, som lar brukeren se, hente og administrere serverobjekter. Denne teksten er delvis lånt fra Wikipedia.

For å opprette et nytt skriptredigeringsprogram, bruk "Ny spørring"-knappen:

For å endre gjeldende database kan du bruke nedtrekkslisten:

For å utføre en spesifikk kommando (eller gruppe av kommandoer), velg den og trykk på "Utfør"-knappen eller "F5"-tasten. Hvis det bare er én kommando i redigeringsprogrammet, eller du trenger å utføre alle kommandoene, trenger du ikke velge noe.

Etter å ha kjørt skript, spesielt de som oppretter objekter (tabeller, kolonner, indekser), for å se endringene, bruk oppdatering fra kontekstmenyen ved å utheve den aktuelle gruppen (for eksempel Tabeller), selve tabellen eller kolonnegruppen i den.

Faktisk er det alt vi trenger å vite for å fullføre eksemplene gitt her. Resten av SSMS-verktøyet er enkelt å lære på egen hånd.

Litt teori

En relasjonsdatabase (RDB, eller heretter i sammenhengen ganske enkelt DB) er en samling av tabeller som er sammenkoblet. Grovt sett er en database en fil der data lagres i en strukturert form.

DBMS – Database Management System, dvs. dette er et sett med verktøy for å jobbe med en bestemt type database (MS SQL, Oracle, MySQL, Firebird, ...).

Merk
Fordi i livet, i dagligtale, sier vi stort sett: "Oracle DB", eller til og med bare "Oracle", som faktisk betyr "Oracle DBMS", så i sammenheng med denne læreboken vil begrepet DB noen ganger bli brukt. Ut fra konteksten tror jeg det vil være klart hva vi snakker om.

En tabell er en samling av kolonner. Kolonner kan også kalles felt eller kolonner; alle disse ordene vil bli brukt som synonymer som uttrykker det samme.

Tabellen er hovedobjektet til RDB; alle RDB-data lagres rad for rad i kolonnene i tabellen. Linjer og poster er også synonymer.

For hver tabell, så vel som dens kolonner, spesifiseres navn som de senere åpnes for.
Objektnavnet (tabellnavn, kolonnenavn, indeksnavn osv.) i MS SQL kan ha en maksimal lengde på 128 tegn.

For referanse– i ORACLE-databasen kan objektnavn ha en maksimal lengde på 30 tegn. Derfor, for en spesifikk database, må du utvikle dine egne regler for navngivning av objekter for å møte grensen for antall tegn.

SQL er et språk som lar deg spørre en database ved hjelp av en DBMS. I en spesifikk DBMS kan SQL-språket ha en spesifikk implementering (sin egen dialekt).

DDL og DML er en undergruppe av SQL-språket:

• DDL-språket brukes til å lage og endre databasestrukturen, dvs. å opprette/endre/slette tabeller og relasjoner.
• DML-språket lar deg manipulere tabelldata, dvs. med replikkene hennes. Den lar deg velge data fra tabeller, legge til nye data i tabeller, samt oppdatere og slette eksisterende data.

I SQL kan du bruke 2 typer kommentarer (enkeltlinje og flerlinje):

En linje kommentar
Og

/* flerlinjekommentar */

Egentlig vil dette være nok for teorien.

DDL – Data Definition Language

Tenk for eksempel på en tabell med data om ansatte, i en form som er kjent for en person som ikke er programmerer:

I dette tilfellet har kolonnene i tabellen følgende navn: Personalnummer, Fullt navn, Fødselsdato, E-post, Stilling, Avdeling.

Hver av disse kolonnene kan karakteriseres av typen data den inneholder:

• Personalnummer – heltall
• Fullt navn – streng
• Fødselsdato – dato
• E-post – streng
• Posisjon - streng
• Avdeling - linje

Kolonnetype er en egenskap som indikerer hvilken type data en gitt kolonne kan lagre.

Til å begynne med vil det være nok å huske bare følgende grunnleggende datatyper som brukes i MS SQL:

Betydning	Notasjon i MS SQL	Beskrivelse
Snor med variabel lengde	varchar(N) Og nvarchar(N)	Ved å bruke tallet N kan vi spesifisere maksimal mulig strenglengde for den tilsvarende kolonnen. For eksempel, hvis vi vil si at verdien av kolonnen "Navn" kan inneholde maksimalt 30 tegn, må vi sette typen til nvarchar(30). Forskjellen mellom varchar og nvarchar er at varchar lar deg lagre strenger i ASCII-format, hvor ett tegn opptar 1 byte, og nvarchar lagrer strenger i Unicode-format, hvor hvert tegn opptar 2 byte. Varchar-typen skal bare brukes hvis du er 100 % sikker på at feltet ikke trenger å lagre Unicode-tegn. For eksempel kan varchar brukes til å lagre e-postadresser fordi... de inneholder vanligvis bare ASCII-tegn.
Fast lengde streng	røye(N) Og nchar(N)	Denne typen skiller seg fra en streng med variabel lengde ved at hvis lengden på strengen er mindre enn N tegn, så er den alltid polstret til høyre til en lengde på N med mellomrom og lagret i databasen i denne formen, dvs. i databasen tar det opp nøyaktig N tegn (der ett tegn tar opp 1 byte for char og 2 byte for nchar). I min praksis brukes denne typen svært sjelden, og hvis den brukes, brukes den hovedsakelig i char(1)-formatet, dvs. når et felt er definert av et enkelt tegn.
Heltall	int	Denne typen lar oss bruke bare heltall i kolonnen, både positive og negative. For referanse (nå er dette ikke så relevant for oss), er tallområdet som int-typen tillater fra -2 147 483 648 til 2 147 483 647. Vanligvis er dette hovedtypen som brukes til å spesifisere identifikatorer.
Reelt eller reelt tall	flyte	Enkelt sagt er dette tall som kan inneholde et desimaltegn (komma).
Dato	Dato	Hvis kolonnen bare trenger å lagre datoen, som består av tre komponenter: dag, måned og år. For eksempel 15.02.2014 (15. februar 2014). Denne typen kan brukes for kolonnen «Dato for innleggelse», «Fødselsdato» osv., dvs. i tilfeller der det er viktig for oss å registrere kun datoen, eller når tidskomponenten ikke er viktig for oss og kan forkastes eller hvis den ikke er kjent.
Tid	tid	Denne typen kan brukes dersom kolonnen kun trenger å lagre tidsdata, dvs. Timer, minutter, sekunder og millisekunder. For eksempel 17:38:31.3231603 For eksempel daglig "Flyavgangstid".
dato og tid	dato tid	Denne typen lar deg lagre både dato og klokkeslett samtidig. For eksempel 15.02.2014 17:38:31.323 Dette kan for eksempel være dato og klokkeslett for en hendelse.
Flagg	bit	Denne typen er praktisk å bruke for å lagre verdier av formen "Ja"/"Nei", der "Ja" vil bli lagret som 1, og "Nei" vil bli lagret som 0.

Feltverdien, hvis den ikke er forbudt, kan heller ikke spesifiseres; nøkkelordet NULL brukes til dette formålet.

For å kjøre eksemplene, la oss lage en testdatabase kalt Test.

En enkel database (uten å spesifisere flere parametere) kan opprettes ved å kjøre følgende kommando:

LAG DATABASE Test
Du kan slette databasen med kommandoen (du bør være veldig forsiktig med denne kommandoen):

DROP DATABASE Test
For å bytte til databasen vår kan du kjøre kommandoen:

BRUK Test
Alternativt kan du velge Testdatabasen fra rullegardinlisten i SSMS-menyområdet. Når jeg jobber bruker jeg ofte denne metoden for å bytte mellom databaser.

Nå i databasen vår kan vi lage en tabell ved å bruke beskrivelsene slik de er, med mellomrom og kyrilliske tegn:

LAG TABELL [Ansatte]([Personalnummer] int, [Navn] nvarchar(30), [Fødselsdato] dato, nvarchar(30), [Posisjon] nvarchar(30), [Avdeling] nvarchar(30))
I dette tilfellet må vi sette navn i hakeparenteser […].

Men i databasen, for større bekvemmelighet, er det bedre å spesifisere alle objektnavn på latin og ikke bruke mellomrom i navn. I MS SQL begynner vanligvis hvert ord i dette tilfellet med en stor bokstav, for eksempel for "Personnelnummer"-feltet kan vi angi navnet PersonnelNumber. Du kan også bruke numre i navnet, for eksempel PhoneNumber1.

På en lapp
I noen DBMS-er kan følgende navneformat "PHONE_NUMBER" være mer å foretrekke; for eksempel brukes dette formatet ofte i ORACLE-databasen. Når du spesifiserer et feltnavn, er det naturligvis ønskelig at det ikke sammenfaller med nøkkelordene som brukes i DBMS.

Av denne grunn kan du glemme syntaksen for hakeparenteser og slette tabellen [Ansatte]:

DROP TABELL [Ansatte]
For eksempel kan en tabell med ansatte hete "Ansatte", og feltene kan gis følgende navn:

• ID – Personalnummer (medarbeider-ID)
• Navn - fullt navn
• Fødselsdag - fødselsdato
• E-post – E-post
• Posisjon - Posisjon
• Avdeling - Avdeling

Svært ofte brukes ordet ID for å navngi et identifikasjonsfelt.

La oss nå lage tabellen vår:

LAG TABELL Ansatte(ID int, Navn nvarchar(30), Fødselsdato, E-post nvarchar(30), Stilling nvarchar(30), Avdeling nvarchar(30))
For å spesifisere nødvendige kolonner, kan du bruke IKKE NULL-alternativet.

For en eksisterende tabell kan felt omdefineres ved hjelp av følgende kommandoer:

Oppdater ID-felt ENDRING TABELL Ansatte ENDRE KOLONNE ID int NOT NULL -- oppdatering Navnefelt ENDRING TABELL Ansatte ENDRE KOLONNE Navn nvarchar(30) NOT NULL

På en lapp
Det generelle konseptet for SQL-språket forblir det samme for de fleste DBMS-er (i det minste er dette hva jeg kan bedømme ut fra DBMS-ene jeg har jobbet med). Forskjellene mellom DDL i forskjellige DBMS-er ligger hovedsakelig i datatypene (ikke bare navnene deres kan avvike her, men også detaljene for implementeringen deres), og selve spesifikasjonene for implementeringen av SQL-språket kan også variere litt (dvs. essensen av kommandoene er den samme, men det kan være små forskjeller i dialekt, dessverre, men det er ingen standard). Etter å ha mestret det grunnleggende i SQL, kan du enkelt bytte fra ett DBMS til et annet, fordi... I dette tilfellet trenger du bare å forstå detaljene i implementeringen av kommandoer i det nye DBMS, dvs. i de fleste tilfeller vil det være tilstrekkelig å tegne en analogi.

Opprette en tabell CREATE TABLE Employees(ID int, -- i ORACLE er int-typen ekvivalenten (wrapper) for nummer(38) Navn nvarchar2(30), -- nvarchar2 i ORACLE tilsvarer nvarchar i MS SQL Bursdagsdato, e-post nvarchar2(30) , Posisjon nvarchar2(30), Avdeling nvarchar2(30)); -- oppdatering av ID- og Navn-feltene (her MODIFY(...) brukes i stedet for ALTER COLUMN) ALTER TABLE Ansatte MODIFY(ID int NOT NULL,Name nvarchar2(30) NOT NULL); -- legge til PK (i dette tilfellet ser konstruksjonen ut som i MS SQL, den vil bli vist nedenfor) ALTER TABLE Ansatte ADD CONSTRAINT PK_Employees PRIMARY KEY(ID);
For ORACLE er det forskjeller når det gjelder implementering av varchar2-typen; kodingen avhenger av databaseinnstillingene og teksten kan lagres, for eksempel i UTF-8-koding. I tillegg kan feltlengden i ORACLE spesifiseres både i byte og i tegn; for dette brukes tilleggsalternativer BYTE og CHAR, som spesifiseres etter feltlengden, for eksempel:

NAVN varchar2(30 BYTE) -- feltkapasiteten vil være 30 byte NAVN varchar2(30 CHAR) -- feltkapasiteten vil være på 30 tegn
Hvilket alternativ som vil bli brukt som standard BYTE eller CHAR, i tilfelle av å spesifisere varchar2(30)-typen i ORACLE, avhenger av databaseinnstillingene, og det kan noen ganger settes i IDE-innstillingene. Generelt, noen ganger kan du lett bli forvirret, så i tilfellet med ORACLE, hvis varchar2-typen brukes (og dette er noen ganger begrunnet her, for eksempel når du bruker UTF-8-koding), foretrekker jeg å eksplisitt skrive CHAR (siden det er vanligvis mer praktisk å beregne lengden på strengen i tegn ).

Men i dette tilfellet, hvis det allerede er noen data i tabellen, er det nødvendig for vellykket utførelse av kommandoer at ID- og Navn-feltene fylles ut i alle rader i tabellen. La oss demonstrere dette med et eksempel: sett inn data i tabellen i ID, Posisjon og Avdeling-feltene; dette kan gjøres med følgende skript:

INSERT Ansatte(ID,Posisjon,Avdeling) VERDIER (1000,N"Direktor",N"Administrasjon"), (1001,N"Programmer",N"IT"), (1002,N"Regnskapsfører",N"Regnskap" ), (1003,N"Senior Programmer",N"IT")
I dette tilfellet vil INSERT-kommandoen også generere en feil, fordi Da vi satte inn, spesifiserte vi ikke verdien til det nødvendige Navn-feltet.
Hvis vi allerede hadde disse dataene i den opprinnelige tabellen, ville kommandoen "ALTER TABLE Employees ALTER COLUMN ID int NOT NULL" bli utført, og kommandoen "ALTER TABLE Employees ALTER COLUMN Name int NOT NULL" ville gi en feilmelding, at feltet Navn inneholder NULL (uspesifiserte) verdier.

La oss legge til verdier for Navn-feltet og fylle ut dataene på nytt:

NOT NULL-alternativet kan også brukes direkte når du oppretter en ny tabell, dvs. i sammenheng med CREATE TABLE-kommandoen.

Først sletter du tabellen ved å bruke kommandoen:

DROP TABLE Ansatte
La oss nå lage en tabell med de nødvendige ID- og Navn-kolonnene:

OPPRETT TABELL Ansatte(ID int NOT NULL, Navn nvarchar(30) NOT NULL, Bursdagsdato, E-post nvarchar(30), Stilling nvarchar(30), Department nvarchar(30))
Du kan også skrive NULL etter kolonnenavnet, noe som betyr at NULL-verdier (ikke spesifisert) vil være tillatt i den, men dette er ikke nødvendig, siden denne egenskapen er underforstått som standard.

Hvis du tvert imot vil gjøre en eksisterende kolonne valgfri, bruk følgende kommandosyntaks:

ENDRINGSTABELL Ansatte ENDRE KOLONNE Navn nvarchar(30) NULL
Eller ganske enkelt:

ENDRINGSTABELL Ansatte ENDRE KOLONNE Navn nvarchar(30)
Med denne kommandoen kan vi også endre felttypen til en annen kompatibel type, eller endre lengden. La oss for eksempel utvide feltet Navn til 50 tegn:

ENDRINGSTABELL Ansatte ENDRE KOLONNE Navn nvarchar(50)

Primærnøkkel

Når du oppretter en tabell, er det ønskelig at den har en unik kolonne eller et sett med kolonner som er unikt for hver av dens rader - en post kan identifiseres unikt med denne unike verdien. Denne verdien kalles tabellens primærnøkkel. For vår Ansatte-tabell kan en slik unik verdi være ID-kolonnen (som inneholder "Ansattes personellnummer" - selv om denne verdien i vårt tilfelle er unik for hver ansatt og ikke kan gjentas).

Du kan opprette en primærnøkkel til en eksisterende tabell ved å bruke kommandoen:

ALTER TABLE Ansatte ADD CONSTRAINT PK_Employees PRIMARY KEY(ID)
Der "PK_Employees" er navnet på begrensningen som er ansvarlig for primærnøkkelen. Vanligvis navngis primærnøkkelen ved å bruke prefikset "PK_" etterfulgt av tabellnavnet.

Hvis primærnøkkelen består av flere felt, må disse feltene være oppført i parentes, atskilt med komma:

ALTER TABLE tabellnavn LEGG TIL BEGRENSNING begrensningsnavn PRIMÆR NØKKEL(felt1,felt2,...)
Det er verdt å merke seg at i MS SQL må alle felt som er inkludert i primærnøkkelen ha NOT NULL-karakteristikken.

Primærnøkkelen kan også bestemmes direkte ved opprettelse av en tabell, dvs. i sammenheng med CREATE TABLE-kommandoen. La oss slette tabellen:

DROP TABLE Ansatte
Og så lager vi den ved å bruke følgende syntaks:

OPPRETT TABELL Ansatte(ID int NOT NULL, Navn nvarchar(30) NOT NULL, Bursdagsdato, E-post nvarchar(30), Stilling nvarchar(30), Avdeling nvarchar(30), BEGRENSNING PK_Employees PRIMARY KEY(ID) -- beskriv PK etter alle felt som en begrensning)
Etter opprettelsen fyller du tabellen med data:

INSERT Employees(ID,Position,Department,Name) VALUES (1000,N"Director",N"Administration",N"Ivanov I.I."), (1001,N"Programmer",N"IT",N" Petrov P.P." ), (1002,N"Accountant",N"Accounting",N"Sidorov S.S."), (1003,N"Senior Programmer",N"IT",N"Andreev A.A.")
Hvis primærnøkkelen i en tabell bare består av verdiene til én kolonne, kan du bruke følgende syntaks:

CREATE TABLE Employees(ID int NOT NULL CONSTRAINT PK_Employees PRIMARY KEY, -- spesifiser som en egenskap for feltet Navn nvarchar(30) NOT NULL, Bursdagsdato, E-post nvarchar(30), Stilling nvarchar(30), Avdeling nvarchar(30) )
Faktisk trenger du ikke å spesifisere navnet på begrensningen, i så fall vil den bli tildelt et systemnavn (som "PK__Employee__3214EC278DA42077"):

OPPRETT TABELL Ansatte(ID int NOT NULL, Navn nvarchar(30) NOT NULL, Bursdagsdato, E-post nvarchar(30), Stilling nvarchar(30), Avdeling nvarchar(30), PRIMÆRKØKKEL(ID))
Eller:

LAG TABELL Ansatte(ID int NOT NULL PRIMARY KEY, Navn nvarchar(30) NOT NULL, Bursdagsdato, E-post nvarchar(30), Stilling nvarchar(30), Department nvarchar(30))
Men jeg vil anbefale at du alltid eksplisitt angir navnet på begrensningen for permanente tabeller, fordi Med et eksplisitt spesifisert og forståelig navn vil det være lettere å manipulere det senere; for eksempel kan du slette det:

ENDRINGSTABELL Ansatte SLIPPER BEGRENSNING PK_Ansatte
Men en så kort syntaks, uten å spesifisere navnene på restriksjonene, er praktisk å bruke når du oppretter midlertidige databasetabeller (navnet på den midlertidige tabellen begynner med # eller ##), som vil bli slettet etter bruk.

La oss oppsummere

Så langt har vi sett på følgende kommandoer:

• LAG BORD table_name (liste over felt og deres typer, begrensninger) – brukes til å lage en ny tabell i gjeldende database;
• DROPPE BORD tabellnavn – brukes til å slette en tabell fra gjeldende database;
• ENDRE TABELL tabellnavn ENDRE KOLONNE kolonnenavn... – brukes til å oppdatere kolonnetypen eller endre dens innstillinger (for eksempel for å angi NULL eller NOT NULL-karakteristikken);
• ENDRE TABELL tabellnavn LEGG TIL BEGRENSNING constraint_name PRIMÆRNØKKEL(felt1, felt2,...) – legge til en primærnøkkel til en eksisterende tabell;
• ENDRE TABELL tabellnavn DROPPSBEGRENSNING constraint_name – fjerner en begrensning fra tabellen.

Litt om midlertidige bord

Utdrag fra MSDN. Det er to typer midlertidige tabeller i MS SQL Server: lokal (#) og global (##). Lokale midlertidige tabeller er kun synlige for skaperne til tilkoblingsøkten til SQL Server-forekomsten avsluttes når de først opprettes. Lokale midlertidige tabeller slettes automatisk etter at en bruker kobler fra forekomsten av SQL Server. Globale midlertidige tabeller er synlige for alle brukere under alle tilkoblingsøkter etter at disse tabellene er opprettet, og slettes når alle brukere som refererer til disse tabellene kobler fra forekomsten av SQL Server.

Midlertidige tabeller opprettes i tempdb-systemdatabasen, dvs. Ved å lage dem tetter vi ikke hoveddatabasen; ellers er midlertidige tabeller helt identiske med vanlige tabeller; de kan også slettes ved å bruke kommandoen DROP TABLE. Lokale (#) midlertidige tabeller er mer vanlig å bruke.

For å lage en midlertidig tabell, kan du bruke CREATE TABLE-kommandoen:

LAG TABELL #Temp(ID int, Navn nvarchar(30))
Siden en midlertidig tabell i MS SQL ligner på en vanlig tabell, kan den også slettes ved å bruke kommandoen DROP TABLE:

SLIPP TABELL #Temp

Du kan også opprette en midlertidig tabell (som en vanlig tabell) og umiddelbart fylle den med dataene som returneres av spørringen ved å bruke SELECT ... INTO-syntaksen:

VELG ID, Navn INTO #Temp FRA ansatte

På en lapp
Implementeringen av midlertidige tabeller kan variere i forskjellige DBMS-er. For eksempel, i ORACLE og Firebird DBMS, må strukturen til midlertidige tabeller bestemmes på forhånd av CREATE GLOBAL TEMPORARY TABLE-kommandoen, som indikerer spesifikasjonene for lagring av data i den, deretter ser brukeren den blant hovedtabellene og arbeider med den som med et vanlig bord.

Databasenormalisering – oppdeling i undertabeller (kataloger) og identifisere forbindelser

Vår nåværende tabell med ansatte har den ulempen at brukeren i posisjons- og avdelingsfeltene kan skrive inn hvilken som helst tekst, som først og fremst er beheftet med feil, siden han for en ansatt ganske enkelt kan angi "IT" som avdelingen, og for en annen ansatt, for for eksempel, skriv inn "IT-avdeling", den tredje har "IT". Som følge av dette vil det være uklart hva brukeren mente, d.v.s. Er disse ansatte ansatte ved samme avdeling, eller beskrev brukeren seg selv og dette er 3 forskjellige avdelinger? Dessuten vil vi i dette tilfellet ikke være i stand til å gruppere dataene riktig for en rapport, der det kan være nødvendig å vise antall ansatte ved hver avdeling.

Den andre ulempen er volumet av lagring av denne informasjonen og dens duplisering, dvs. For hver ansatt angis fullt navn på avdelingen, noe som krever plass i databasen for å lagre hvert tegn fra avdelingsnavnet.

Den tredje ulempen er vanskeligheten med å oppdatere disse feltene hvis navnet på en stilling endres, for eksempel hvis du trenger å gi nytt navn til stillingen "Programmer" til "Junior Programmer". I dette tilfellet må vi gjøre endringer i hver rad i tabellen hvis posisjon er lik "Programmer".

For å unngå disse manglene brukes såkalt databasenormalisering - splitter den opp i undertabeller og referansetabeller. Det er ikke nødvendig å gå inn i teorijungelen og studere hva normale former er; det er nok å forstå essensen av normalisering.

La oss lage 2 katalogtabeller "Posisjoner" og "Avdelinger", la oss kalle de første stillingene, og den andre, henholdsvis avdelinger:

CREATE TABLE Positions(ID int IDENTITY(1,1) NOT NULL CONSTRAINT PK_Positions PRIMARY KEY, Name nvarchar(30) NOT NULL) CREATE TABLE Departments(ID int IDENTITY(1,1) NOT NULL CONSTRAINT PK_Departments PRIMARYn KEY,(30Navn NULL) ) IKKE NULL)
Merk at vi her brukte det nye IDENTITY-alternativet, som sier at dataene i ID-kolonnen vil nummereres automatisk, fra 1, i trinn på 1, dvs. Når du legger til nye poster, blir de sekvensielt tildelt verdiene 1, 2, 3 osv. Slike felt kalles vanligvis auto-inkrementering. En tabell kan bare ha ett felt definert med IDENTITY-egenskapen, og vanligvis, men ikke nødvendigvis, er det feltet primærnøkkelen for den tabellen.

På en lapp
I forskjellige DBMS-er kan implementeringen av felt med en teller gjøres annerledes. I MySQL, for eksempel, er et slikt felt definert ved å bruke AUTO_INCREMENT-alternativet. I ORACLE og Firebird kunne denne funksjonaliteten tidligere emuleres ved hjelp av SEQUENCE. Men så vidt jeg vet har ORACLE nå lagt til alternativet GENERERT SOM IDENTITET.

La oss fylle disse tabellene automatisk, basert på gjeldende data som er registrert i Stillings- og Avdelingsfeltene i tabellen Ansatte:

Vi fyller Navn-feltet i Stillingstabellen med unike verdier fra Stilling-feltet i Ansatte-tabellen INSERT Positions(Name) SELECT DISTINCT Position FROM Ansatte WHERE Position IS NOT NULL -- kast poster som stillingen ikke er spesifisert for
La oss gjøre det samme for avdelingstabellen:

INSERT Avdelinger(Navn) VELG DISTINKT Avdeling FRA Ansatte HVOR Avdeling IKKE ER NULL
Hvis vi nå åpner tabellene Stillinger og Avdelinger, vil vi se et nummerert sett med verdier for ID-feltet:

VELG * FRA posisjoner

VELG * FRA avdelinger

Disse tabellene vil nå spille rollen som oppslagsverk for å spesifisere stillinger og avdelinger. Vi vil nå referere til jobb- og avdelings-ID. Først av alt, la oss opprette nye felt i tabellen Ansatte for å lagre identifikasjonsdata:

Legg til et felt for stillings-ID ALTER TABLE Ansatte ADD PositionID int -- legg til et felt for avdelings-ID ALTER TABLE Ansatte ADD DepartmentID int
Type referansefelt må være den samme som i kataloger, i dette tilfellet er det int.

Du kan også legge til flere felt i tabellen samtidig med én kommando, og liste opp feltene atskilt med kommaer:

ENDRINGSTABELL Ansatte ADD PositionID int, DepartmentID int
La oss nå skrive lenker (referanserestriksjoner - FOREIGN KEY) for disse feltene slik at brukeren ikke har mulighet til å skrive inn i disse feltene verdier som ikke er blant ID-verdiene som finnes i katalogene.

ALTER TABLE Ansatte ADD CONSTRAINT FK_Employees_PositionID UTENLANDSKE KEY(PositionID) REFERANSER Posisjoner(ID)
Og vi vil gjøre det samme for det andre feltet:

ALTER TABLE Ansatte ADD CONSTRAINT FK_Employees_DepartmentID UTENLANDSKE NØKKEL(DepartmentID) REFERANSER Avdelinger(ID)
Nå vil brukeren kun kunne legge inn ID-verdier fra den tilsvarende katalogen i disse feltene. Følgelig, for å bruke en ny avdeling eller stilling, må han først legge til en ny oppføring i den tilsvarende katalogen. Fordi Posisjoner og avdelinger er nå lagret i kataloger i én enkelt kopi, så for å endre navnet er det nok å endre det bare i katalogen.

Navnet på en referansebegrensning er vanligvis et sammensatt navn, bestående av prefikset "FK_", etterfulgt av tabellnavnet, og etterfulgt av et understrek, etterfulgt av navnet på feltet som refererer til referansetabellidentifikatoren.

En identifikator (ID) er vanligvis en intern verdi som kun brukes for relasjoner og hvilken verdi som er lagret der er i de fleste tilfeller helt likegyldig, så det er ikke nødvendig å prøve å kvitte seg med hull i tallrekkefølgen som oppstår mens du arbeider med tabellen, for eksempel etter sletting av poster fra katalogen.

ALTER TABLE-tabell ADD CONSTRAINT constraint_name UTENLANDSKE NØKKEL(felt1,felt2,...) REFERANSER referansetabell(felt1,felt2,...)
I dette tilfellet, i tabellen "referansetabell", er primærnøkkelen representert av en kombinasjon av flere felt (felt1, felt2,...).

La oss faktisk oppdatere PositionID og DepartmentID-feltene med ID-verdier fra katalogene. La oss bruke DML UPDATE-kommandoen til dette formålet:

OPPDATERING e SET PositionID=(VELG ID FRA Stillinger WHERE Name=e.Position), DepartmentID=(VELG ID FRA Avdelinger WHERE Name=e.Departement) FRA Ansatte e
La oss se hva som skjer ved å kjøre forespørselen:

VELG * FRA Ansatte

Det er det, StillingsID- og Avdelings-ID-feltene er fylt med identifikatorene som tilsvarer stillinger og avdelinger; Stillings- og Avdelingsfeltene er ikke lenger nødvendige i tabellen Ansatte, du kan slette disse feltene:

ENDRINGSTABELL Ansatte SLIPPER KOLONNE Stilling, avdeling
Nå ser tabellen vår slik ut:

VELG * FRA Ansatte

ID	Navn	Fødselsdag	E-post	Posisjons-ID	Avdelings-ID
1000	Ivanov I.I.	NULL	NULL	2	1
1001	Petrov P.P.	NULL	NULL	3	3
1002	Sidorov S.S.	NULL	NULL	1	2
1003	Andreev A.A.	NULL	NULL	4	3

De. Vi ble til slutt kvitt å lagre overflødig informasjon. Nå, basert på jobb- og avdelingsnumrene, kan vi entydig bestemme navnene deres ved å bruke verdiene i referansetabellene:

VELG e.ID,e.Name,p.Name Stillingsnavn,d.Name Avdelingsnavn FRA Ansatte e LEFT JOIN Avdelinger d ON d.ID=e.DepartmentID LEFT JOIN Stillinger p ON p.ID=e.PositionID

I objektinspektøren kan vi se alle objektene som er opprettet for en gitt tabell. Herfra kan du utføre ulike manipulasjoner med disse objektene - for eksempel endre navn på eller slette objekter.

Det er også verdt å merke seg at tabellen kan referere til seg selv, dvs. du kan lage en rekursiv lenke. La oss for eksempel legge til et annet felt ManagerID i tabellen vår med ansatte, som vil indikere den ansatte som denne ansatte rapporterer til. La oss lage et felt:

ENDRINGSTABELL Ansatte ADD ManagerID int
Dette feltet tillater en NULL-verdi; feltet vil være tomt hvis det for eksempel ikke er noen overordnede over den ansatte.

La oss nå lage en UTENLANDSK NØKKEL for tabellen Ansatte:

ENDRINGSTABELL Ansatte ADD CONSTRAINT FK_Employees_ManagerID UTENLANDSKE NØKKEL (ManagerID) REFERANSER Ansatte(ID)
La oss nå lage et diagram og se hvordan relasjonene mellom tabellene våre ser ut på det:

Som et resultat bør vi se følgende bilde (tabellen Ansatte er koblet til tabellene Stillinger og Avdelinger, og refererer også til seg selv):

Til slutt er det verdt å si at referansenøkler kan inkludere flere alternativer ON DELETE CASCADE og ON UPDATE CASCADE, som indikerer hvordan man skal oppføre seg ved sletting eller oppdatering av en post som er referert til i referansetabellen. Hvis disse alternativene ikke er spesifisert, kan vi ikke endre ID i katalogtabellen for en post som er referert fra en annen tabell, og vi vil heller ikke kunne slette en slik post fra katalogen før vi sletter alle rader som refererer til denne posten eller la oss oppdatere referansene i disse linjene til en annen verdi.

La oss for eksempel gjenskape tabellen som spesifiserer ON DELETE CASCADE-alternativet for FK_Employees_DepartmentID:

DROP TABLE Ansatte CREATE TABLE Ansatte(ID int NOT NULL, Navn nvarchar(30), Bursdagsdato, E-post nvarchar(30), PositionID int, DepartmentID int, ManagerID int, BEGRENSNING PK_Employees PRIMÆR NØKKEL (ID), CONSTRAINTEDELFORDELING_Department KDEVDELING_DEMEY ) REFERANSER Avdelinger(ID) PÅ SLETT CASCADE, BEGRENSNING FK_Employees_PositionID FOREIGN KEY(PositionID) REFERANSER Posisjoner(ID), CONSTRAINT FK_Employees_ManagerID UTENLANDSKE NØKKEL (ManagerID) REFERENCES Ansatte INSERT,Del,Dag,Dag,AnsattID,AnsattID) mentID, ManagerID )VERDIER (1000,N"Ivanov I.I.","19550219",2,1,NULL), (1001,N"Petrov P.P.","19831203",3,3,1003), (1002 ,N"Sidorov S.S." "19760607",1,2,1000), (1003,N"Andreev A.A.","19820417",4,3,1000)
La oss slette avdelingen med ID 3 fra avdelingstabellen:

SLETT avdelinger WHERE ID=3
La oss se på dataene i tabellen Ansatte:

VELG * FRA Ansatte

ID	Navn	Fødselsdag	E-post	Posisjons-ID	Avdelings-ID	ManagerID
1000	Ivanov I.I.	1955-02-19	NULL	2	1	NULL
1002	Sidorov S.S.	1976-06-07	NULL	1	2	1000

Som du ser ble også dataene for avdeling 3 fra tabellen Ansatte slettet.

Alternativet ON UPDATE CASCADE oppfører seg på samme måte, men det er effektivt når du oppdaterer ID-verdien i katalogen. Hvis vi for eksempel endrer ID-en til en stilling i stillingskatalogen, vil i dette tilfellet avdelings-IDen i tabellen Ansatte bli oppdatert til den nye ID-verdien som vi angir i katalogen. Men i dette tilfellet vil det rett og slett ikke være mulig å demonstrere dette, fordi ID-kolonnen i avdelingstabellen har IDENTITY-alternativet, som ikke vil tillate oss å utføre følgende spørring (endre avdelings-ID 3 til 30):

OPPDATERT avdelinger SET ID=30 WHERE ID=3
Det viktigste er å forstå essensen av disse 2 alternativene PÅ SLETT CASCADE og PÅ OPPDATERING AV CASCADE. Jeg bruker disse alternativene svært sjelden og anbefaler at du tenker deg nøye om før du spesifiserer dem i en referansebegrensning, fordi hvis du ved et uhell sletter en oppføring fra en katalogtabell, kan dette føre til store problemer og skape en kjedereaksjon.

La oss gjenopprette avdeling 3:

Vi gir tillatelse til å legge til/endre IDENTITY-verdi SET IDENTITY_INSERT avdelinger ON INSERT avdelinger(ID,navn) VALUES(3,N"IT") -- vi forbyr å legge til/endre IDENTITY-verdi SET IDENTITY_INSERT avdelinger AV
La oss tømme tabellen Ansatte fullstendig ved å bruke TRUNCATE TABLE-kommandoen:

TRUNCATE TABLE Ansatte
Og igjen vil vi laste inn dataene på nytt ved å bruke den forrige INSERT-kommandoen:

INSERT Ansatte (ID,Navn,Fødselsdag,PosisjonsID,DepartmentID,ManagerID)VERDIER (1000,N"Ivanov I.I.","19550219",2,1,NULL), (1001,N"Petrov P.P." ,"19831203",3 ,3,1003), (1002,N"Sidorov S.S.","19760607",1,2,1000), (1003,N"Andreev A.A.","19820417" ,4,3,1000)

La oss oppsummere

For øyeblikket er flere flere DDL-kommandoer lagt til vår kunnskap:

• Å legge til IDENTITY-egenskapen i et felt – lar deg gjøre dette feltet til et automatisk utfylt felt (tellerfelt) for tabellen;
• ENDRE TABELL tabellnavn LEGG TIL list_of_fields_with_characteristics – lar deg legge til nye felt i tabellen;
• ENDRE TABELL tabellnavn SLIPPE KOLONNE list_fields – lar deg fjerne felt fra tabellen;
• ENDRE TABELL tabellnavn LEGG TIL BEGRENSNING constraint_name UTENLANDSKE NØKKEL(Enger) REFERANSER table_reference (felt) – lar deg definere forholdet mellom tabellen og referansetabellen.

Andre restriksjoner – UNIQUE, DEFAULT, CHECK

Ved å bruke en UNIK begrensning kan du si at verdien for hver rad i et gitt felt eller sett med felt må være unik. Når det gjelder tabellen Ansatte, kan vi pålegge en slik begrensning i E-post-feltet. Bare forhåndsfyll e-post med verdier hvis de ikke allerede er definert:

OPPDATERING Ansatte SET E-post=" [e-postbeskyttet]" WHERE ID=1000 OPPDATERING Ansatte SET E-post=" [e-postbeskyttet]" WHERE ID=1001 OPPDATERING Ansatte SET E-post=" [e-postbeskyttet]" WHERE ID=1002 OPPDATERING Ansatte SET E-post=" [e-postbeskyttet]"HVOR ID=1003
Nå kan du legge en unikhetsbegrensning på dette feltet:

ENDRINGSTABELL Ansatte ADD CONSTRAINT UQ_Employees_Email UNIQUE(Email)
Nå vil ikke brukeren kunne legge inn samme e-post for flere ansatte.

En unik begrensning heter vanligvis som følger - først kommer prefikset "UQ_", deretter navnet på tabellen og etter understreken kommer navnet på feltet som denne begrensningen brukes på.

Følgelig, hvis en kombinasjon av felt må være unik i sammenheng med tabellrader, viser vi dem atskilt med komma:

ALTER TABLE tabellnavn LEGG TIL BEGRENSNING begrensningsnavn UNIK(felt1,felt2,...)
Ved å legge til en DEFAULT-begrensning i et felt, kan vi spesifisere en standardverdi som vil bli erstattet hvis, når du setter inn en ny post, dette feltet ikke er oppført i listen over felt til INSERT-kommandoen. Denne begrensningen kan settes direkte når du oppretter tabellen.

La oss legge til et nytt ansettelsesdato-felt i Employees-tabellen og kalle det HireDate og si at standardverdien for dette feltet vil være gjeldende dato:

ENDRINGSTABELL Ansatte ADD LeieDato dato IKKE NULL STANDARD SYSDATETIME()
Eller hvis HireDate-kolonnen allerede eksisterer, kan følgende syntaks brukes:

ENDRINGSTABELL Ansatte LEGG TIL STANDARD SYSDATETIME() FOR HireDate
Her spesifiserte jeg ikke navnet på begrensningen, fordi... i tilfellet DEFAULT har jeg den oppfatning at dette ikke er så kritisk. Men hvis du gjør det på en god måte, så tror jeg at du ikke trenger å være lat, og du bør angi et normalt navn. Dette gjøres som følger:

ALTER TABLE Ansatte ADD CONSTRAINT DF_Employees_HireDate DEFAULT SYSDATETIME() FOR HireDate
Siden denne kolonnen ikke eksisterte før, når den legges til hver post, vil gjeldende datoverdi settes inn i HireDate-feltet.

Når du legger til en ny oppføring, vil gjeldende dato også settes inn automatisk, selvfølgelig, med mindre vi uttrykkelig setter det, dvs. Vi vil ikke angi det i listen over kolonner. La oss vise dette med et eksempel uten å spesifisere HireDate-feltet i listen over tilleggsverdier:

INSERT Employees(ID,Name,Email)VALUES(1004,N"Sergeev S.S."," [e-postbeskyttet]")
La oss se hva som skjedde:

VELG * FRA Ansatte

ID	Navn	Fødselsdag	E-post	Posisjons-ID	Avdelings-ID	ManagerID	LeieDato
1000	Ivanov I.I.	1955-02-19	[e-postbeskyttet]	2	1	NULL	2015-04-08
1001	Petrov P.P.	1983-12-03	[e-postbeskyttet]	3	4	1003	2015-04-08
1002	Sidorov S.S.	1976-06-07	[e-postbeskyttet]	1	2	1000	2015-04-08
1003	Andreev A.A.	1982-04-17	[e-postbeskyttet]	4	3	1000	2015-04-08
1004	Sergeev S.S.	NULL	[e-postbeskyttet]	NULL	NULL	NULL	2015-04-08

CHECK-kontrollbegrensningen brukes når det er nødvendig å kontrollere verdiene som er satt inn i feltet. La oss for eksempel pålegge denne begrensningen på personellnummerfeltet, som for oss er en ansattidentifikator (ID). Ved å bruke denne begrensningen sier vi at personellnummer må ha en verdi fra 1000 til 1999:

ENDRINGSTABELL Ansatte ADD BEGRENSNING CK_Employees_ID CHECK(ID MELLOM 1000 OG 1999)
Begrensningen heter vanligvis på samme måte, først med prefikset "CK_", deretter navnet på tabellen og navnet på feltet som denne begrensningen er pålagt.

La oss prøve å sette inn en ugyldig post for å sjekke at begrensningen fungerer (vi bør få den tilsvarende feilen):

INSERT Employees(ID,Email) VALUES(2000," [e-postbeskyttet]")
La oss nå endre den innsatte verdien til 1500 og sørge for at posten er satt inn:

INSERT Employees(ID,Email) VALUES(1500," [e-postbeskyttet]")
Du kan også opprette UNIQUE og CHECK-begrensninger uten å spesifisere et navn:

ENDRING TABELL Ansatte LEGG TIL UNIK(E-post) ENDRING TABELL Ansatte LEGG TIL KONTROLL (ID MELLOM 1000 OG 1999)
Men dette er ikke en veldig god praksis, og det er bedre å spesifisere navnet på begrensningen eksplisitt, fordi For å finne ut av det senere, som vil være vanskeligere, må du åpne objektet og se på hva det er ansvarlig for.

Med et godt navn kan mye informasjon om begrensningen læres direkte fra navnet.

Og følgelig kan alle disse begrensningene opprettes umiddelbart når du oppretter en tabell, hvis den ikke eksisterer ennå. La oss slette tabellen:

DROP TABLE Ansatte
Og vi vil gjenskape den med alle de opprettede restriksjonene med én CREATE TABLE-kommando:

LAG TABELL Ansatte(ID int IKKE NULL, Navn nvarchar(30), Bursdagsdato, E-post nvarchar(30), StillingsID int, AvdelingsID int, Leiedato IKKE NULL STANDARD SYSDATETIME(), -- for STANDARD vil jeg gjøre et unntak CONSTRAINT PK_Employees PRIMARY KEY (ID), CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY(DepartmentID) REFERENCES Avdelinger(ID), CONSTRAINT FK_Employees_PositionID UTENLANDSKE NØKKEL(PositionID) REFERENCES Positions(ID), CONSTRAINT UQ_Employees_Eemployees_E- EEN 1000 OG 1999) )

INSERT ansatte (ID, navn, bursdag, e-post, posisjons-ID, avdelings-ID) VERDIER (1000,N"Ivanov I.I.","19550219"," [e-postbeskyttet]",2,1), (1001,N"Petrov P.P.","19831203"," [e-postbeskyttet]",3,3), (1002,N"Sidorov S.S.","19760607"," [e-postbeskyttet]",1,2), (1003,N"Andreev A.A.","19820417"," [e-postbeskyttet]",4,3)

Litt om indeksene som ble opprettet ved opprettelse av PRIMÆRKØKKEL og UNIKE begrensninger

Som du kan se i skjermbildet ovenfor, ble det automatisk opprettet indekser med samme navn (PK_Employees og UQ_Employees_Email) når du opprettet PRIMÆRKØKKEL- og UNIQUE-begrensningene. Som standard er indeksen for primærnøkkelen opprettet som KLUSTERET, og for alle andre indekser som IKKE KLUSTERET. Det er verdt å si at konseptet med en klyngeindeks ikke er tilgjengelig i alle DBMS-er. En tabell kan bare ha én KLUSTERET indeks. CLUSTERED – betyr at tabellpostene vil bli sortert etter denne indeksen, vi kan også si at denne indeksen har direkte tilgang til alle data i tabellen. Dette er hovedindeksen i tabellen, for å si det sånn. For å si det enda grovere, er dette en indeks knyttet til en tabell. En gruppert indeks er et veldig kraftig verktøy som kan hjelpe med søkeoptimalisering, men la oss bare huske dette for nå. Hvis vi vil fortelle at den grupperte indeksen ikke skal brukes på primærnøkkelen, men på en annen indeks, så når vi oppretter primærnøkkelen, må vi spesifisere alternativet IKKE CLUSTERED:

ALTER TABLE tabellnavn LEGG TIL BEGRENSNING begrensningsnavn PRIMÆR NØKKEL IKKE KLUSTERET(felt1,felt2,...)
La oss for eksempel gjøre begrensningsindeksen PK_Employees ikke-klynget, og begrensningsindeksen UQ_Employees_Email clustered. Først av alt, la oss fjerne disse begrensningene:

ENDRE TABELL Ansatte SLIPPER BEGRENSNING PK_Ansatte ENDRING TABELL Ansatte SLIPPER BEGRENSNING UQ_Employees_Email
La oss nå lage dem med alternativene CLUSTERED og IKKE-CLUSTERED:

ENDRE TABELL Ansatte ADD CONSTRAINT PK_Employees PRIMÆR NØKKEL IKKE KLUSTERET (ID) ENDRING TABELL Ansatte ADD CONSTRAINT UQ_Employees_Email UNIQUE CLUSTERED (E-post)
Nå, ved å velge fra Employees-tabellen, vil vi se at postene er sortert etter UQ_Employees_Email-klyngeindeksen:

VELG * FRA Ansatte

ID	Navn	Fødselsdag	E-post	Posisjons-ID	Avdelings-ID	LeieDato
1003	Andreev A.A.	1982-04-17	[e-postbeskyttet]	4	3	2015-04-08
1000	Ivanov I.I.	1955-02-19	[e-postbeskyttet]	2	1	2015-04-08
1001	Petrov P.P.	1983-12-03	[e-postbeskyttet]	3	3	2015-04-08
1002	Sidorov S.S.	1976-06-07	[e-postbeskyttet]	1	2	2015-04-08

Tidligere, når den grupperte indeksen var PK_Employees-indeksen, ble postene sortert etter ID-feltet som standard.

Men i dette tilfellet er dette bare et eksempel som viser essensen av en klynget indeks, fordi Mest sannsynlig vil forespørsler gjøres til tabellen Ansatte ved å bruke ID-feltet, og i noen tilfeller vil det kanskje selv fungere som en katalog.

For kataloger er det vanligvis tilrådelig at den grupperte indeksen bygges på primærnøkkelen, fordi i forespørsler refererer vi ofte til katalogidentifikatoren for å få for eksempel navnet (Posisjon, Avdeling). La oss huske her det jeg skrev ovenfor, at en klynget indeks har direkte tilgang til tabellrader, og det følger at vi kan få verdien av en hvilken som helst kolonne uten ekstra overhead.

Det er fordelaktig å bruke en klyngeindeks på felt som samples oftest.

Noen ganger blir tabeller opprettet med en nøkkel basert på et surrogatfelt; i dette tilfellet kan det være nyttig å lagre CLUSTERED indeksalternativet for en mer passende indeks og spesifisere IKKE CLUSTERED når du oppretter en surrogat primærnøkkel.

La oss oppsummere

På dette stadiet har vi blitt kjent med alle typer restriksjoner, i deres enkleste form, som er opprettet av en kommando som "ALTER TABLE table_name ADD CONSTRAINT constraint_name...":

• PRIMÆRNØKKEL- primærnøkkel;
• UTENLANDSKE NØKKEL– sette opp tilkoblinger og overvåke referanseintegriteten til data;
• UNIK– lar deg skape unikhet;
• KRYSS AV– lar deg sikre riktigheten av de angitte dataene;
• MISLIGHOLDE– lar deg angi en standardverdi;
• Det er også verdt å merke seg at alle restriksjoner kan fjernes ved å bruke kommandoen " ENDRE TABELL tabellnavn DROPPSBEGRENSNING constraint_name".

Vi berørte også delvis temaet indekser og undersøkte begrepet klynge ( Klynget) og ikke-gruppert ( IKKE-KLUSTERET) indeks.

Opprette frittstående indekser

Med uavhengig her mener vi indekser som ikke er opprettet under PRIMÆRKØKKEL eller UNIK begrensning.

Indekser på et felt eller felt kan opprettes med følgende kommando:

CREATE INDEX IDX_Employees_Name ON Employees(Name)
Også her kan du spesifisere alternativene KLUSTERET, IKKE KLUSTERET, UNIK, og du kan også spesifisere sorteringsretningen for hvert enkelt felt ASC (standard) eller DESC:

LAG UNIK IKKE-KLUSTERET INDEKS UQ_Employees_EmailDesc ON Ansatte (E-post DESC)
Når du oppretter en ikke-klynget indeks, kan alternativet IKKE-KLUSTERET utelates, fordi det er underforstått som standard og vises her ganske enkelt for å indikere posisjonen til CLUSTERED eller IKKE CLUSTERED-alternativet i kommandoen.

Du kan slette indeksen med følgende kommando:

DROP INDEX IDX_Employees_Name ON Ansatte
Enkle indekser, så vel som begrensninger, kan opprettes i sammenheng med CREATE TABLE-kommandoen.

La oss for eksempel slette tabellen igjen:

DROP TABLE Ansatte
Og vi vil gjenskape den med alle de opprettede restriksjonene og indeksene med én CREATE TABLE-kommando:

OPPRETT TABELL Ansatte(ID int NOT NULL, Navn nvarchar(30), Bursdagsdato, E-post nvarchar(30), StillingsID int, AvdelingsID int, Ansettelsesdato IKKE NULL BEGRENSNING DF_Employees_HireDate DEFAULT SYSDATETIME(),AnsattID PKEMARY, ansattID int, CONSTRAINT ), CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY(DepartmentID) REFERENCES Departments(ID), CONSTRAINT FK_Employees_PositionID FOREIGN KEY(PositionID) REFERENCES Positions(ID), CONSTRAINT FK_Employees_ManagerID UTFERENCID UTLANDS, CONSTRAINT FK_Employees_ManagerID UEFERENCID FOREIGN KEY. loyees_Email UNIQUE(E-post), BEGRENSNING CK_Employees_ID CHECK(ID MELLOM 1000 OG 1999), INDEX IDX_Employees_Name(Name))
Til slutt, la oss sette inn våre ansatte i tabellen:

INSERT ansatte (ID, navn, bursdag, e-post, stillings-ID, avdelings-ID, leder-ID) VERDIER (1000,N"Ivanov I.I.","19550219"," [e-postbeskyttet]",2,1,NULL), (1001,N"Petrov P.P.","19831203"," [e-postbeskyttet]",3,3,1003), (1002,N"Sidorov S.S.","19760607"," [e-postbeskyttet]",1,2,1000), (1003,N"Andreev A.A.","19820417"," [e-postbeskyttet]",4,3,1000)
I tillegg er det verdt å merke seg at du kan inkludere verdier i en ikke-klynget indeks ved å spesifisere dem i INCLUDE. De. i dette tilfellet vil INCLUDE-indeksen minne litt om en klynget indeks, bare nå er ikke indeksen knyttet til tabellen, men de nødvendige verdiene er knyttet til indeksen. Følgelig kan slike indekser forbedre ytelsen til utvalgsspørringer (SELECT); hvis alle de oppførte feltene er i indeksen, kan det hende at tilgang til tabellen ikke er nødvendig i det hele tatt. Men dette øker naturligvis størrelsen på indeksen, fordi verdiene til de oppførte feltene dupliseres i indeksen.

Utdrag fra MSDN. Generell kommandosyntaks for å lage indekser

LAG [UNIKK] [KLUSTERET | IKKE KLUSTERET ] INDEX index_name PÅ