En indre sammenføjning kræver, at hver række i de to sammenføjede tabeller har matchende kolonneværdier og er en almindeligt anvendt sammenføjningsoperation i applikationer, men bør ikke antages at være det bedste valg i alle situationer. Indre sammenføjning opretter en ny resultattabel ved at kombinere kolonneværdier for to tabeller (A og B) baseret på sammenføjningspredikatet. Forespørgslen sammenligner hver række A med hver række B for at finde alle par af rækker, der tilfredsstiller sammenføjningspredikatet. Når sammenføjningspredikatet er opfyldt ved at matche ikke-NULL-værdier, kombineres kolonneværdier for hvert matchede par af rækker af A og B til en resultatrække.

Resultatet af sammenføjningen kan defineres som resultatet af først at tage det kartesiske produkt (eller krydsføjning) af alle rækker i tabellerne (kombinere hver række i tabel A med hver række i tabel B) og derefter returnere alle rækker, der opfylder sammenføjningspredikatet. Faktiske SQL-implementeringer bruger normalt andre tilgange, såsom hash-sammenføjninger eller sorteringsfusioner, da beregning af det kartesiske produkt er langsommere og ofte kræver en uoverkommelig stor mængde hukommelse at gemme.

SQL specificerer to forskellige syntaktiske måder at udtrykke sammenføjninger på: “eksplicit sammenføjningsnotation” og “implicit tilslutningsnotation”. Den “implicitte sammenkædningsnotation” betragtes ikke længere som en bedste praksis, selvom databasesystemer stadig understøtter den.

“Eksplicit sammenkædningsnotation” bruger nøgleordet JOIN, valgfrit forud for nøgleordet INNER for at specificere den tabel, der skal sammenføjes, og nøgleordet ON for at specificere prædikaterne for sammenføjningen følgende eksempel:

SELECT employee.LastName, employee.DepartmentID, department.DepartmentName FROM employee INNER JOIN department ONemployee.DepartmentID = department.DepartmentID;

Den “implicit sammenføjningsnotation” viser blot t han tabeller til sammenføjning i FROM -sætningen i SELECT -sætningen ved hjælp af kommaer til at adskille dem. Det specificerer således en krydsforbindelse, og WHERE -klausulen kan muligvis anvende yderligere filterprædikater (som fungerer sammenligneligt med sammenføjningspredikaterne i den eksplicitte notation).

Følgende eksempel svarer til det foregående, men denne gang ved hjælp af implicit join notation:

SELECT employee.LastName, employee.DepartmentID, department.DepartmentName FROM employee, departmentWHERE employee.DepartmentID = department.DepartmentID;

Forespørgslerne i eksemplerne ovenfor vil deltage i medarbejder- og afdelingstabellerne ved hjælp af kolonnen DepartmentID i begge tabeller. Hvor DepartmentID for disse tabeller matcher (dvs. sammenføjelsespredikatet er opfyldt), kombinerer forespørgslen kolonnerne LastName, DepartmentID og DepartmentName fra de to tabeller til en resultatrække. Hvor DepartmentID ikke stemmer overens, genereres der ingen resultatrækker.

Resultatet af udførelsen af forespørgslen ovenfor bliver således:

Medarbejderen “Williams” og afdelingen “Marketing” vises ikke i resultaterne af forespørgslens udførelse. Ingen af disse har nogen matchende rækker i den anden respektive tabel: “Williams” har ingen tilknyttet afdeling, og ingen medarbejdere har afdeling ID 35 (“Marketing”). Afhængigt af de ønskede resultater kan denne adfærd være en subtil fejl, som kan undgås ved at erstatte den indre sammenføjning med en ydre sammenføjning.

Indre sammenføjning og NULL-værdier Rediger

Programmører skal tage særlig forsigtighed ved sammenføjning af tabeller på kolonner, der kan indeholde NULL-værdier, da NULL aldrig vil matche nogen anden værdi (ikke engang NULL selv), medmindre sammenføjningsbetingelsen udtrykkeligt bruger et kombinationspredikat, der først kontrollerer, at sammenføjningskolonnerne er NOT NULL før du anvender de resterende prædikatbetingelser. Den indre sammenføjning kan kun bruges sikkert i en database, der håndhæver referentiel integritet, eller hvor sammenføjningskolonnerne garanteret ikke er NULL. Mange transaktionsbehandlingsrelationsdatabaser er afhængige af standardopdateringsstandarder for atomicitet, konsistens, isolation, holdbarhed (ACID) for at sikre dataintegritet, hvilket gør indre sammenføjninger til et passende valg. Transaktionsdatabaser har dog normalt også ønskelige sammenføjningskolonner, der har tilladelse til at være NULL.Mange rapporterende relationsdatabaser og datalagre bruger batchopdateringer med høj volumen Extract, Transform, Load (ETL), som gør det vanskelig eller umuligt at håndhæve referenceintegritet, hvilket resulterer i potentielt NULL-sammenkædningskolonner, som en SQL-forespørgselsforfatter ikke kan ændre, og som medfører, at indre sammenføjninger udelades data uden indikation af en fejl. Valget om at bruge en indre sammenføjning afhænger af databasedesignet og datakarakteristikkerne. En ydre venstre sammenføjning kan normalt erstattes af en indre sammenføjning, når sammenføjningskolonnerne i en tabel kan indeholde NULL-værdier.

Enhver datakolonne, der kan være NULL (tom), bør aldrig bruges som et link i en indre sammenføjning, medmindre det tilsigtede resultat er at eliminere rækkerne med NULL-værdien. Hvis NULL sammenføjningskolonner bevidst skal fjernes fra resultatsættet, kan en indre sammenføjning være hurtigere end en ydre sammenføjning, fordi tabellen sammenføjes og filtreres i et enkelt trin. Omvendt kan en indre sammenføjning resultere i katastrofalt langsom ydeevne eller endda et servernedbrud, når det bruges i et stort volumenforespørgsel i kombination med databasefunktioner i en SQL Where-klausul. En funktion i en SQL Hvor klausul kan resultere i, at databasen ignorerer relativt kompakte tabelindekser. Databasen kan læse og indre sammenføje de valgte kolonner fra begge tabeller, før antallet af rækker reduceres ved hjælp af filteret, der afhænger af en beregnet værdi, hvilket resulterer i en relativt enorm mængde ineffektiv behandling.

Når et resultatsæt produceres ved at forbinde flere tabeller, herunder mastertabeller, der bruges til at slå op i fuldtekstbeskrivelser af numeriske identifikationskoder (en opslagstabel), en NULL-værdi i en hvilken som helst af de fremmede nøgler kan resultere i, at hele rækken elimineres fra resultatsættet uden indikation af fejl. En kompleks SQL-forespørgsel, der inkluderer en eller flere indre sammenføjninger og flere ydre sammenføjninger, har den samme risiko for NULL-værdier i de indvendige sammenføjningskolonnekolonner.

En forpligtelse til SQL-kode, der indeholder indre sammenføjninger forudsætter, at NULL sammenføjningskolonner ikke vil være introduceres ved fremtidige ændringer, herunder leverandøropdateringer, designændringer og massebehandling uden for applikationens datavalideringsregler såsom datakonverteringer, migreringer, bulkimport og fusioner.

Man kan yderligere klassificere indre sammenføjninger som equi-sammenføjninger, som naturlige sammenføjninger eller som tværføjninger.

Equi-joinEdit

En equi-join er en bestemt type komparatorbaseret sammenføjning, der kun bruger ligestillingssammenligninger ved hjælp af andre sammenligningsoperatorer (såsom <) diskvalificerer en sammenføjning som en equi-sammenføjning. Forespørgslen vist ovenfor har allerede givet et eksempel på en equi-sammenføjning:

SELECT *FROM employee JOIN department ON employee.DepartmentID = department.DepartmentID;

Vi kan skrive equi-join som nedenfor,

SELECT *FROM employee, departmentWHERE employee.DepartmentID = department.DepartmentID;

Hvis co søjler i en equi-join har samme navn, SQL-92 giver en valgfri stenografisk notation til at udtrykke equi-joins ved hjælp af USING -konstruktionen:

SELECT *FROM employee INNER JOIN department USING (DepartmentID);

USING -konstruktionen er mere end blot syntaktisk sukker, da resultatsættet adskiller sig fra resultatet sæt af versionen med det eksplicitte prædikat. Specifikt vil alle kolonner, der er nævnt i USING -listen, kun vises én gang med et ukvalificeret navn snarere end en gang for hver tabel i sammenføjningen. I ovenstående tilfælde vil der være en enkelt DepartmentID kolonne og ingen employee.DepartmentID eller department.DepartmentID .

USING -klausulen understøttes ikke af MS SQL Server og Sybase.

Natural joinEdit

The natural join er et specielt tilfælde af equi-join. Natural join (⋈) er en binær operator, der skrives som (R ⋈ S), hvor R og S er relationer. Resultatet af den naturlige sammenføjning er sættet med alle kombinationer af tupler i R og S, der er ens på deres fælles attributnavne.For eksempel overveje tabellerne Medarbejder og Afdeling og deres naturlige sammenføjning:

Dette kan også bruges til at definere sammensætning af relationer. For eksempel er sammensætningen af medarbejder og afdeling deres sammenføjning som vist ovenfor, projiceret på alle undtagen den fælles attribut DeptName. I kategoriteori er sammenføjningen nøjagtigt fiberproduktet.

Den naturlige sammenføjning er uden tvivl en af de vigtigste operatører, da den er den relationelle modstykke til logisk AND. Bemærk, at hvis den samme variabel vises i hvert af de to prædikater, der er forbundet med AND, så står denne variabel for den samme ting, og begge udseende skal altid erstattes af den samme værdi. Især den naturlige sammenføjning tillader kombinationen af relationer, der er forbundet med en fremmed nøgle. I ovenstående eksempel er der sandsynligvis en fremmed nøgle fra Employee.DeptName til Dept.DeptName og derefter kombinerer den naturlige sammenkædning af Employee and Dept alle medarbejdere med deres afdelinger. Dette fungerer, fordi den fremmede nøgle holder mellem attributter med samme navn. Hvis dette ikke er tilfældet som i den fremmede nøgle fra Afdelingsleder til Medarbejder.Navn, skal disse kolonner omdøbes, før den naturlige sammenføjning tages. En sådan sammenføjning omtales undertiden også som en equi-sammenføjning.

Mere formelt er semantikken i den naturlige sammenføjning defineret som følger:

R ⋈ S = {t ∪ s ∣ t ∈ R ∧ s ∈ S ∧ F un (t ∪ s)} {\ displaystyle R \ bowtie S = \ left \ {t \ cup s \ mid t \ in R \ \ land \ s \ in S \ \ land \ {\ mathit {Fun}} (t \ cup s) \ right \}},

hvor Fun er et predikat, der er sandt for en relation r, hvis og kun hvis r er en funktion. Det kræves normalt, at R og S skal have mindst en fælles attribut, men hvis denne begrænsning udelades, og R og S ikke har nogen fælles attributter, bliver den naturlige sammenføjning nøjagtigt det kartesiske produkt.

naturlig sammenføjning kan simuleres med Codds primitiver som følger. Lad c1,…, cm være attributnavne, der er fælles for R og S, r1,…, rn være attributnavne, der er unikke for R, og lad s1,…, sk være attributter unikke for S. Antag desuden, at attributnavne x1,…, xm hverken er i R eller i S. I et første trin kan de fælles attributnavne i S nu omdøbes:

T = ρ x 1 / c 1,…, xm / cm (S) = ρ x 1 / c 1 (ρ x 2 / c 2 (… ρ xm / cm (S)…)) {\ displaystyle T = \ rho _ {x_ {1} / c_ {1}, \ ldots, x_ {m} / c_ {m}} (S) = \ rho _ {x_ {1} / c_ {1}} (\ rho _ {x_ {2} / c_ {2 }} (\ ldots \ rho _ {x_ {m} / c_ {m}} (S) \ ldots))}

Så tager vi det kartesiske produkt og vælger de tupler, der skal sammenføjes:

U = π r 1,…, rn, c 1,…, cm, s 1,…, sk (P) {\ displaystyle U = \ pi _ {r_ {1}, \ ldots, r_ {n}, c_ {1}, \ ldots, c_ {m}, s_ {1}, \ ldots, s_ {k}} (P)}

En naturlig sammenføjning er en type ækvivalent join, hvor sammenføjningspredikatet opstår implicit ved at sammenligne alle kolonner i begge tabeller, der har de samme kolonnenavne i de sammenføjede tabeller. Den resulterende sammenføjede tabel indeholder kun en kolonne for hvert par af lige navngivne kolonner. I tilfælde af at der ikke findes nogen kolonner med de samme navne, er resultatet en krydsforbindelse.

De fleste eksperter er enige om, at NATURLIGE JOIN’er er farlige og derfor stærkt fraråder deres anvendelse. Faren skyldes utilsigtet tilføjelse af en ny kolonne, der hedder det samme som en anden kolonne i den anden tabel. En eksisterende naturlig sammenføjning kan derefter “naturligt” bruge den nye kolonne til sammenligning, hvilket gør sammenligninger / matches ved hjælp af forskellige kriterier (fra forskellige kolonner) end før. Således kunne en eksisterende forespørgsel producere forskellige resultater, selvom dataene i tabellerne ikke er blevet ændret, men kun udvidet.Brugen af kolonnenavne til automatisk at bestemme tabellinks er ikke en mulighed i store databaser med hundreder eller tusinder af tabeller, hvor det vil lægge en urealistisk begrænsning på navngivningskonventioner. Virkelige verdens databaser er almindeligt designet med udenlandske nøgledata, der ikke er konsekvent befolket (NULL-værdier er tilladt) på grund af forretningsregler og kontekst. Det er almindelig praksis at ændre kolonnenavne på lignende data i forskellige tabeller, og denne mangel på stiv konsistens henviser naturlige sammenføjninger til et teoretisk koncept til diskussion.

Ovenstående prøveforespørgsel til indre sammenføjninger kan udtrykkes som en naturlig Deltag på følgende måde:

SELECT *FROM employee NATURAL JOIN department;

Som med den eksplicitte USING -klausul, kun en DepartmentID-kolonne forekommer i den sammenføjede tabel uden kvalifikation:

PostgreSQL, MySQL og Oracle su pport naturlige sammenføjninger; Microsoft T-SQL og IBM DB2 gør det ikke. Kolonnerne, der bruges i sammenføjningen, er implicitte, så sammenføjningskoden ikke viser, hvilke kolonner der forventes, og en ændring i kolonnenavne kan ændre resultaterne. I SQL: 2011-standarden er naturlige sammenføjninger en del af den valgfri F401, “Udvidet sammenføjet tabel”, pakke.

I mange databasemiljøer styres kolonnenavnene af en ekstern leverandør, ikke forespørgseludvikleren. En naturlig sammenføjning forudsætter stabilitet og konsistens i kolonnenavne, som kan ændre sig under leverandørmandaterede versionopgraderinger.