Begränsningar för Azure Databricks

  • Artikel

Azure Databricks stöder standardsatser för SQL-begränsningshantering. Begränsningarna delas in i två kategorier:

  • Framtvingade contraints säkerställer att kvaliteten och integriteten för data som läggs till i en tabell verifieras automatiskt.
  • Begränsningar för informations primärnyckel och sekundärnyckel kodar relationer mellan fält i tabeller och tillämpas inte.

Alla begränsningar för Azure Databricks kräver Delta Lake.

Delta Live Tables har ett liknande begrepp som kallas förväntningar. Se Hantera datakvalitet med Delta Live Tables.

Framtvingade begränsningar för Azure Databricks

När en begränsning överträds misslyckas transaktionen med ett fel. Två typer av begränsningar stöds:

  • NOT NULL: anger att värden i specifika kolumner inte får vara null.
  • CHECK: anger att ett angivet booleskt uttryck måste vara sant för varje indatarad.

Viktigt!

Om du lägger till en begränsning uppgraderas tabellskrivarens protokollversion automatiskt om den tidigare skrivarversionen var mindre än 3. Se Hur hanterar Azure Databricks Delta Lake-funktionskompatibilitet? för att förstå versionshantering av tabellprotokoll och vad det innebär att uppgradera protokollversionen.

Ange en NOT NULL begränsning i Azure Databricks

Du anger NOT NULL begränsningar i schemat när du skapar en tabell. Du släpper eller lägger till NOT NULL begränsningar med kommandot ALTER TABLE ALTER COLUMN .

CREATE TABLE people10m (
  id INT NOT NULL,
  firstName STRING,
  middleName STRING NOT NULL,
  lastName STRING,
  gender STRING,
  birthDate TIMESTAMP,
  ssn STRING,
  salary INT
) USING DELTA;

ALTER TABLE people10m ALTER COLUMN middleName DROP NOT NULL;
ALTER TABLE people10m ALTER COLUMN ssn SET NOT NULL;

Innan du lägger till en NOT NULL begränsning i en tabell verifierar Azure Databricks att alla befintliga rader uppfyller villkoret.

Om du anger en NOT NULL begränsning för en kolumn kapslad i en struct får den överordnade structen inte heller vara null. Kolumner kapslade i matris- eller karttyper accepterar NOT NULL inte begränsningar.

Se SKAPA TABELL [USING] och ALTER TABLE ALTER COLUMN.

Ange en CHECK begränsning i Azure Databricks

Du hanterar CHECK begränsningar med hjälp av kommandona ALTER TABLE ADD CONSTRAINT och ALTER TABLE DROP CONSTRAINT . ALTER TABLE ADD CONSTRAINT verifierar att alla befintliga rader uppfyller villkoret innan de läggs till i tabellen.

CREATE TABLE people10m (
  id INT,
  firstName STRING,
  middleName STRING,
  lastName STRING,
  gender STRING,
  birthDate TIMESTAMP,
  ssn STRING,
  salary INT
) USING DELTA;

ALTER TABLE people10m ADD CONSTRAINT dateWithinRange CHECK (birthDate > '1900-01-01');
ALTER TABLE people10m DROP CONSTRAINT dateWithinRange;

Se ÄNDRA TABELL LÄGG TILL VILLKOR OCH ÄNDRA TABELLAVLÄMNINGSVILLKOR.

CHECK begränsningar exponeras som tabellegenskaper i utdata från kommandona DESCRIBE DETAIL och SHOW TBLPROPERTIES .

ALTER TABLE people10m ADD CONSTRAINT validIds CHECK (id > 1 and id < 99999999);

DESCRIBE DETAIL people10m;

SHOW TBLPROPERTIES people10m;

Deklarera primärnyckel och sekundärnyckelrelationer

Viktigt!

Den här funktionen finns som allmänt tillgänglig förhandsversion.

Kommentar

  • Begränsningar för primärnyckel och sekundärnyckel är tillgängliga i Databricks Runtime 11.3 LTS och senare.
  • Begränsningar för primärnyckel och sekundärnyckel kräver Unity Catalog och Delta Lake.

Du kan använda primärnyckel- och sekundärnyckelrelationer på fält i Unity Catalog-tabeller. Primära och externa nycklar är endast informationsbaserade och tillämpas inte. Sekundärnycklar måste referera till en primärnyckel i en annan tabell.

Du kan deklarera primära nycklar och sekundärnycklar som en del av tabellspecifikationssatsen när tabellen skapas. Den här satsen tillåts inte under CTAS-instruktioner. Du kan också lägga till begränsningar i befintliga tabeller.

CREATE TABLE T(pk1 INTEGER NOT NULL, pk2 INTEGER NOT NULL,
                CONSTRAINT t_pk PRIMARY KEY(pk1, pk2));
CREATE TABLE S(pk INTEGER NOT NULL PRIMARY KEY,
                fk1 INTEGER, fk2 INTEGER,
                CONSTRAINT s_t_fk FOREIGN KEY(fk1, fk2) REFERENCES T);

Du kan fråga information_schema eller använda DESCRIBE för att få information om hur begränsningar tillämpas i en viss katalog.

Se: