INFOGA I (DMX)

gäller för: SQL Server Analysis Services

Bearbetar det specificerade datautvinningsobjektet. För mer information om bearbetningsmodeller och gruvstrukturer, se Bearbetningskrav och överväganden (Data Mining).

Om en gruvstruktur specificeras, bearbetar uttalandet gruvstrukturen och alla dess tillhörande gruvmodeller. Om en miningmodell specificeras, behandlar uttalandet bara miningmodellen.

Syntax

  
INSERT INTO [MINING MODEL]|[MINING STRUCTURE] <model>|<structure> (<mapped model columns>) <source data query>  
INSERT INTO [MINING MODEL]|[MINING STRUCTURE] <model>|<structure>.COLUMN_VALUES (<mapped model columns>) <source data query>  

Arguments

modell
En modellidentifierare.

struktur
En strukturidentifierare.

Mappade modellkolumner
En kommaseparerad lista över kolumnidentifierare och nästlade identifierare.

Källdatafråga
Källfrågan i det leverantörsdefinierade formatet.

Anmärkningar

Om du inte specificerar MINING MODEL eller MINING STRUCTURE söker Analysis Services efter objekttypen baserat på namnet och bearbetar rätt objekt. Om servern innehåller en mining-struktur och en mining-modell med samma namn, returneras ett fel.

Genom att använda den andra syntaxformen, INFOGA IN ITO*<OBJEKT>*. COLUMN_VALUES kan du infoga data direkt i modellkolumnerna utan att behöva träna modellen. Denna metod tillhandahåller kolumndata till modellen på ett koncist, ordnat sätt som är användbart när man arbetar med dataset som innehåller hierarkier eller ordnade kolumner.

Om du använder INSERT INTO med en mining-modell eller en mining-struktur, och utelämnar de <mappade modellkolumnerna> och <källdatafrågeargumenten> , fungerar satsen som ProcessDefault, med bindningar som redan finns. Om bindningar inte finns returnerar satsen ett felmeddelande. För mer information om ProcessDefault, se Bearbetningsalternativ och inställningar (Analystjänster). Följande exempel visar syntaxen:

INSERT INTO [MINING MODEL] <model>  

Om du anger MINING MODEL och tillhandahåller mappade kolumner samt en källdatafråga, bearbetas modellen och tillhörande struktur.

Följande tabell ger en beskrivning av resultatet av olika former av påståendet, beroende på objektens tillstånd.

Statement	Objektens tillstånd	Result
INFOGA I GRUVMODELLEN*<modell>*	Gruvstrukturen bearbetas.	Gruvmodellen är processad.
	Gruvstrukturen är obearbetad.	Gruvmodellen och gruvstrukturen bearbetas.
	Gruvstrukturen innehåller ytterligare gruvmodeller.	Processen misslyckas. Du måste återbearbeta strukturen och de tillhörande gruvmodellerna.
INFOGA I GRUVSTRUKTUR*<struktur>*	Gruvstrukturen är bearbetad eller obearbetad.	Gruvstruktur och tillhörande gruvmodeller bearbetas.
INFOGA I MINING MODEL*<model>* som innehåller en källfråga eller INFOGA I MINING STRUKTUR*<struktur>* som innehåller en källfråga	Antingen strukturen eller modellen innehåller redan innehåll.	Processen misslyckas. Du måste rensa objekten innan du utför denna operation genom att använda DELETE (DMX).

Mappade modellkolumner

Genom att använda elementet <mappade modellkolumner> kan du mappa kolumnerna från datakällan till kolumnerna i din miningmodell. Elementet för <den avbildade modellkolumnerna> har följande form:

<column identifier> | SKIP | <table identifier> (<column identifier> | SKIP), ...  

Genom att använda SKIP kan du utesluta vissa kolumner som måste finnas i källfrågan, men som inte finns i miningmodellen. SKIP är användbart när du inte har kontroll över kolumnerna som ingår i indataraduppsättningen. Om du skriver din egen OPENQUERY är det bättre att utelämna kolumnen från SELECT-kolumnlistan istället för att använda SKIP.

SKIP är också användbart när en kolumn från indataradmängden behövs för att utföra en join, men kolumnen inte används av gruvstrukturen. Ett typiskt exempel på detta är en mining-struktur och miningmodell som innehåller en nästlad tabell. Indataraden för denna struktur kommer att ha en främmande nyckelkolumn som används för att skapa en hierarkisk raduppsättning med hjälp av SHAPE-klausulen, men främmande nyckelkolumnen används nästan aldrig i modellen.

Syntaxen för SKIP kräver att du infogar SKIP på positionen för den enskilda kolumnen i indataradmängden som inte har någon motsvarande kolumn för mining-struktur. Till exempel, i exemplet med nästlad tabell nedan måste OrderNumber väljas i APPEND-klausulen så att den kan användas i RELATE-klausulen för att specificera joinen; men du vill inte infoga OrderNumber-data i den nästlade tabellen i mining-strukturen. Därför använder exemplet nyckelordet SKIP istället för OrderNumber i argumentet INSERT INTO.

Källdatafråga

Källdatafrågeelementet <> kan inkludera följande typer av datakällor:

• OPENQUERY

• OPENROWSET

• FORM

• Alla Analysis Services-frågor som returnerar en raduppsättning

För mer information om typer av datakällor, se <källdatafråga>.

Grundläggande exempel

Följande exempel använder OPENQUERY för att träna en Naiv Bayes-modell baserad på den riktade e-postdatan i databasen AdventureWorksDW2025 .

INSERT INTO NBSample (CustomerKey, Gender, [Number Cars Owned],  
    [Bike Buyer])  
OPENQUERY([AdventureWorksDW2022],'Select CustomerKey, Gender, [NumberCarsOwned], [BikeBuyer]   
FROM [vTargetMail]')  

Exempel på nästlad tabell

Följande exempel använder SHAPE för att träna en association mining-modell som innehåller en nästlad tabell. Observera att första raden innehåller SKIP istället OrderNumber, vilket krävs i SHAPE_APPEND-satsen men inte används i miningmodellen.

INSERT INTO MyAssociationModel  
    ([OrderNumber],[Models] (SKIP, [Model])  
    )  
SHAPE {  
    OPENQUERY([AdventureWorksDW2022],'SELECT OrderNumber  
    FROM vAssocSeqOrders ORDER BY OrderNumber')  
} APPEND (  
    {OPENQUERY([AdventureWorksDW2022],'SELECT OrderNumber, model FROM   
    dbo.vAssocSeqLineItems ORDER BY OrderNumber, Model')}  
  RELATE OrderNumber to OrderNumber)   
AS [Models]  

Se även

Data mining Extensions (DMX) datadefinitionssatser
Data mining Extensions (DMX) datamanipulationsuttalanden
Data Mining Extensions (DMX) Statement Reference