CREATE VIEW(Transact-SQL)

적용 대상:Microsoft Fabric의 Microsoft Fabric SQL 데이터베이스에 있는 Microsoft Fabric Warehouse의 SQL Server Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System(PDW)SQL 분석 엔드포인트

쿼리에 의해 내용(열과 행)이 정의되는 가상 테이블을 만듭니다. 이 문을 사용하여 데이터베이스에서 하나 이상의 테이블에 있는 데이터의 뷰를 만들 수 있습니다. 예를 들어 뷰는 다음과 같은 용도로 사용할 수 있습니다.

• 각 사용자가 데이터베이스를 보는 시각에 초점을 맞추고 데이터 조작을 간소화하며 사용자 지정할 수 있습니다.

• 뷰는 원본이 되는 기본 테이블에 직접 액세스할 수 있는 권한을 부여하지 않고 뷰를 통해 데이터에 액세스하도록 하기 때문에 보안 메커니즘으로 사용할 수 있습니다.

• 이전 버전과 호환되는 인터페이스를 통해 스키마가 변경된 기존 테이블을 에뮬레이트할 수 있습니다.

Transact-SQL 구문 표기 규칙

SQL Server 및 Azure SQL Database 구문

CREATE [ OR ALTER ] VIEW [ schema_name . ] view_name [ (column [ ,...n ] ) ]
[ WITH <view_attribute> [ ,...n ] ]
AS select_statement
[ WITH CHECK OPTION ]
[ ; ]  

<view_attribute> ::=
{  
    [ ENCRYPTION ]  
    [ SCHEMABINDING ]  
    [ VIEW_METADATA ]
}

Azure Synapse Analytics 및 병렬 데이터 웨어하우스에 대한 구문입니다.

CREATE VIEW [ schema_name . ] view_name [  ( column_name [ ,...n ] ) ]   
AS <select_statement>   
[;]  

<select_statement> ::=  
    [ WITH <common_table_expression> [ ,...n ] ]  
    SELECT <select_criteria>  

Microsoft Fabric Data Warehouse 및 SQL 분석 엔드포인트에 대한 구문입니다.

CREATE [ OR ALTER ] VIEW [ schema_name . ] view_name [  ( column_name [ ,...n ] ) ]   
[ WITH <view_attribute> [ ,...n ] ] AS <select_statement>   
[;]

<view_attribute> ::=
{  
    [ SCHEMABINDING ]  
}

<select_statement> ::=  
    [ WITH <common_table_expression> [ ,...n ] ]  
    SELECT <select_criteria>  

적용 대상: Azure SQL Database 및 SQL Server (SQL Server 2016(13.x) SP1부터)

이미 있는 경우에만 뷰를 조건부로 변경합니다.

schema_name
뷰가 속한 스키마의 이름입니다.

view_name
뷰의 이름입니다. 뷰 이름은 반드시 식별자에 적용되는 규칙을 준수해야 합니다. 뷰 소유자 이름을 지정하는 것은 선택 사항입니다.

column
뷰에 있는 열에 사용할 이름입니다. 열 이름은 열이 산술 식, 함수 또는 상수에서 파생되는 경우에만 필요합니다. 두 개 이상의 열이 동일한 이름을 가질 수 있는 경우(일반적으로 조인 때문에) 또는 뷰의 열이 파생된 열의 이름과 다른 이름을 지정하는 경우 문에서 SELECT 열 이름을 할당할 수도 있습니다.

열을 지정하지 않으면 뷰 열은 문의 열과 SELECT 동일한 이름을 가져옵니다.

뷰가 수행할 동작을 지정합니다.

select_statement

SELECT 뷰를 정의하는 문입니다. 이 문은 둘 이상의 테이블과 다른 뷰를 사용할 수 있습니다. 만들어진 뷰의 절에서 참조되는 개체 중에서 SELECT 선택하려면 적절한 권한이 필요합니다.

뷰는 특정 테이블의 행과 열의 하위 집합일 필요는 없습니다. 둘 이상의 테이블 또는 복잡성의 절이 있는 다른 뷰를 사용하는 뷰를 SELECT 만들 수 있습니다.

인덱싱된 뷰 정의에서 문은 SELECT 단일 테이블 문이거나 선택적 집계가 있는 다중 테이블 JOIN 이어야 합니다.

뷰 정의의 절에는 SELECT 다음을 포함할 수 없습니다.

• ORDER BY 명령문의 select 목록에 SELECT 절이 TOP 없는 한 절

  중요

  절은 ORDER BY 뷰 정의에서 or OFFSET 절에 의해 반환되는 행을 TOP 결정하는 데만 사용됩니다. ORDER BY 쿼리 자체에도 지정되지 않는 한 ORDER BY 뷰가 쿼리될 때 정렬된 결과를 보장하지 않습니다.

• INTO 키워드

• OPTION 절

• 임시 테이블 또는 테이블 변수 참조

select_statement 문을 사용 SELECT 하므로 절에 지정된 FROM 대로 조인 힌트 및 테이블 힌트를 사용하는 것이 유효합니다. 자세한 내용은 FROM(Transact-SQL) 및 SELECT(Transact-SQL)를 참조하세요.

함수 및 여러 SELECT 문을 select_statement 구분 UNION 하거나 UNION ALL 사용할 수 있습니다.

뷰에 대해 실행된 모든 데이터 수정 명령문이 select_statement 내의 기준 집합을 준수하도록 설정합니다. 뷰 WITH CHECK OPTION 를 통해 행을 수정하면 수정이 커밋된 후에도 뷰를 통해 데이터가 계속 표시됩니다.

적용 대상: SQL Server 2008(10.0.x) 이상 및 Azure SQL Database

문 텍스트를 포함하는 sys.syscomments 의 CREATE VIEW 항목을 암호화합니다. 사용하면 WITH ENCRYPTION 보기가 SQL Server 복제의 일부로 게시되지 않습니다.

기본 테이블의 스키마에 뷰를 바인딩합니다. 지정된 경우 SCHEMABINDING 뷰 정의에 영향을 주는 방식으로 기본 테이블 또는 테이블을 수정할 수 없습니다. 뷰 정의 자체를 먼저 수정하거나 삭제하여 수정할 테이블에 대해 종속성을 제거해야 합니다. 사용하는 SCHEMABINDING경우 select_statement 두 부분으로 구성된 이름(스키마)을 포함해야 합니다.object) 참조되는 테이블, 뷰 또는 사용자 정의 함수 참조된 개체는 모두 같은 데이터베이스에 있어야 합니다.

SCHEMABINDING 절로 만든 뷰에서 사용하는 뷰 또는 테이블은 뷰가 삭제되거나 변경되어 스키마 바인딩이 더 이상 존재하지 않는 경우에만 삭제할 수 있습니다. 그렇지 않으면 데이터베이스 엔진에서 오류가 발생합니다. 또한 스키마 바인딩이 있는 뷰에 참여하는 테이블에서 문을 실행하는 ALTER TABLE 것은 이러한 문이 뷰 정의에 영향을 줄 때 실패합니다.

뷰를 참조하는 쿼리에 대해 찾아보기 모드 메타데이터가 요청된 경우 SQL Server 인스턴스에서 기본 테이블 대신 뷰에 대한 메타데이터 정보를 DB-Library, ODBC 및 OLE DB API에 반환하도록 지정합니다. 찾아보기 모드 메타데이터는 SQL Server 인스턴스가 이 클라이언트 쪽 API에 반환하는 추가 메타데이터입니다. 이 메타데이터를 사용하면 클라이언트 쪽 API가 업데이트할 수 있는 클라이언트 쪽 커서를 구현할 수 있습니다. 찾아보기 모드 메타데이터에는 결과 집합의 열이 속한 기본 테이블에 대한 정보가 포함되어 있습니다.

뷰를 VIEW_METADATA사용하여 만든 보기의 경우 찾아보기 모드 메타데이터는 결과 집합의 뷰에서 열을 설명할 때 기본 테이블 이름이 아닌 뷰 이름을 반환합니다.

뷰를 사용하여 WITH VIEW_METADATA뷰를 만들 때 타임스탬프 열을 제외한 모든 열은 뷰 INSTEAD OF INSERT 에 있거나 INSTEAD OF UPDATE 트리거되는 경우 업데이트할 수 있습니다. 업데이트할 수 있는 뷰에 대한 자세한 내용은 주의를 참조하세요.

현재 데이터베이스에서만 뷰를 만들 수 있습니다. 쿼리 CREATE VIEW 일괄 처리의 첫 번째 문이어야 합니다. 최대 1,024개의 열을 뷰에 포함시킬 수 있습니다.

뷰를 통해 쿼리할 때 데이터베이스 엔진은 문에 참조된 모든 데이터베이스 개체가 존재하는지, 문의 컨텍스트 내에서 유효한지, 데이터 변경 문이 데이터 무결성 규칙을 위반하지 않는지 확인합니다. 확인이 실패하면 오류 메시지가 반환됩니다. 성공적으로 확인한 경우 작업이 기본 테이블에 대한 동작으로 변환됩니다.

뷰가 삭제된 테이블이나 뷰에 종속된 경우 뷰를 사용하려고 하면 데이터베이스 엔진에서 오류 메시지를 표시합니다. 새 테이블이나 뷰가 만들어지고 삭제된 테이블을 대체하기 위해 테이블 구조가 이전의 기본 테이블과 달라지지 않은 경우 뷰를 다시 사용할 수 있게 됩니다. 새 테이블이나 뷰 구조가 변경된 경우에는 뷰를 삭제하고 다시 만들어야 합니다.

절을 사용하여 뷰를 만들지 SCHEMABINDING 않은 경우 뷰의 정의에 영향을 주는 뷰의 기본 개체를 변경할 때 sp_refreshview 실행합니다. 그렇지 않으면 뷰를 쿼리할 때 예기치 않은 결과가 발생할 수 있습니다.

뷰를 만들면 뷰에 대한 정보가 sys.views, sys.columns 및 sys.sql_expression_dependencies 카탈로그 뷰에 저장됩니다. 문의 텍스트 CREATE VIEW 는 sys.sql_modules 카탈로그 뷰에 저장됩니다.

숫자 또는 부동 소수점 식으로 정의된 뷰에서 인덱스를 사용하는 쿼리는 뷰에서 인덱스를 사용하지 않는 유사한 쿼리와 다른 결과를 가질 수 있습니다. 이러한 차이는 내부 테이블에 대한 작업 또는 UPDATE 도중INSERTDELETE의 반올림 오류로 인해 발생할 수 있습니다.

데이터베이스 엔진은 뷰가 만들어지는 시기와 SET QUOTED_IDENTIFIERSET ANSI_NULLS 설정을 저장합니다. 이러한 원래 설정은 뷰를 사용할 때 뷰를 구문 분석하기 위해 사용되므로 따라서 뷰에 액세스할 때 뷰 정의에 대한 SET QUOTED_IDENTIFIERSET ANSI_NULLS 모든 클라이언트 세션 설정은 영향을 주지 않습니다.

Azure Synapse Analytics에서 뷰는 스키마 바인딩을 지원하지 않습니다. 따라서 기본 개체를 변경하는 경우 뷰를 삭제하고 다시 만들어 기본 메타데이터를 새로 고쳐야 합니다. 자세한 내용은 Azure Synapse Analytics의 전용 SQL 풀 및 서버리스 SQL 풀을 사용한 T-SQL 뷰를 참조하세요.

Azure Synapse Analytics에서는 업다이블 뷰, DML 트리거(형식 또는 INSTEAD OF형식AFTER) 및 분할된 뷰가 지원되지 않습니다. 자세한 내용은 Azure Synapse Analytics의 전용 SQL 풀 및 서버리스 SQL 풀을 사용한 T-SQL 뷰를 참조하세요.

Azure Synapse Analytics에서는 분할된 뷰가 지원되지 않습니다. 자세한 내용은 Azure Synapse Analytics의 전용 SQL 풀 및 서버리스 SQL 풀을 사용한 T-SQL 뷰를 참조하세요.

Fabric SQL 데이터베이스에서는 뷰를 만들 수 있지만 Fabric OneLake에 미러링되지는 않습니다. 자세한 내용은 패브릭 SQL 데이터베이스 미러링의 제한 사항을 참조 하세요.

다음 조건이 만족되면 뷰를 통해 기본 테이블의 데이터를 수정할 수 있습니다.

• 및 문을 비롯한 UPDATEINSERTDELETE 모든 수정은 하나의 기본 테이블의 열만 참조해야 합니다.

• 뷰에서 수정하는 열은 테이블 열에 있는 기본 데이터를 직접 참조해야 합니다. 다음과 같은 기타 방법으로 열이 파생되면 안 됩니다.

  • 집계 함수: AVG, ,COUNT, SUMMIN, MAX, GROUPINGSTDEV, STDEVPVAR및 .VARP

  • 계산: 다른 열을 사용하는 식으로 열을 계산할 수 없습니다. 집합 연산자 UNION, UNION ALL, CROSSJOIN, EXCEPT 및 INTERSECT를 사용하여 구성한 열은 계산되지만 업데이트할 수 없습니다.

• 수정되는 열은 , HAVING또는 DISTINCT 절의 GROUP BY영향을 받지 않습니다.

• TOP은 뷰 의 select_statement 절과 WITH CHECK OPTION 함께 사용되지 않습니다.

이전의 제한이 뷰 자체에 적용되는 것과 마찬가지로 뷰의 FROM 절 하위 쿼리에 적용됩니다. 일반적으로 데이터베이스 엔진은 뷰 정의에서 특정 기본 테이블에 대해 이루어진 수정을 분명하게 추적할 수 있어야 합니다. 자세한 내용은 뷰를 통해 데이터 수정을 참조하세요.

이전의 제한으로 인해 뷰를 통해 직접 데이터를 수정할 수 없는 경우 다음 방법을 사용하세요.

• INSTEAD OF 트리거

  INSTEAD OF 트리거는 뷰를 업데이트할 수 있도록 보기에 만들 수 있습니다. INSTEAD OF 트리거는 트리거가 정의된 데이터 수정 문 대신 실행됩니다. 이 트리거를 사용하면 데이터 수정 문을 처리할 일련의 동작을 지정할 수 있습니다. 따라서 특정 데이터 수정 문(INSERTUPDATE또는DELETE)에 대한 뷰에 대한 트리거가 있는 경우 INSTEAD OF 해당 뷰는 해당 문을 통해 업데이트할 수 있습니다. 트리거에 대한 INSTEAD OF 자세한 내용은 DML 트리거를 참조하세요.

• 분할된 뷰

  뷰가 분할 뷰일 경우 특정 제한에 따라 뷰를 업데이트할 수 있습니다. 필요할 경우 데이터베이스 엔진은 사용하고 있는 모든 테이블 및 뷰가 동일한 SQL Server 인스턴스에 있는 로컬 분할 뷰, 그리고 뷰의 테이블 중 하나 이상이 다른 서버나 원격 서버에 있는 분산형 분할 뷰로 구분합니다.

분할된 뷰는 동일한 방식으로 구조화된 멤버 테이블에 의해 UNION ALL 정의되는 뷰이지만 동일한 SQL Server 인스턴스 또는 페더레이션된 데이터베이스 서버라는 SQL Server 서버의 자율 인스턴스 그룹에 여러 테이블로 별도로 저장됩니다.

분할 체계를 디자인할 때 각 파티션에 속하는 데이터가 명확해야 합니다. 예를 들어 Customers 테이블의 데이터는 Customers_33에 있는 Server1 멤버 테이블, Customers_66에 있는 Server2 멤버 테이블 및 Customers_99에 있는 Server3 멤버 테이블의 세 위치에 분산되어 있습니다.

Server1의 분할 뷰는 다음과 같이 정의됩니다.

--Partitioned view as defined on Server1  
CREATE VIEW Customers  
AS  
--Select from local member table.  
SELECT *  
FROM CompanyData.dbo.Customers_33  
UNION ALL  
--Select from member table on Server2.  
SELECT *  
FROM Server2.CompanyData.dbo.Customers_66  
UNION ALL  
--Select from member table on Server3.  
SELECT *  
FROM Server3.CompanyData.dbo.Customers_99;  

일반적으로 뷰의 형식이 다음과 같은 경우에 분할 뷰라고 합니다.

SELECT <select_list1>  
FROM T1  
UNION ALL  
SELECT <select_list2>  
FROM T2  
UNION ALL  
...  
SELECT <select_listn>  
FROM Tn;  

1. SELECT list

   • 뷰 정의의 열 목록에서 멤버 테이블의 모든 열을 선택합니다.

   • 각 select list의 같은 서수 위치에 있는 열은 데이터 정렬 등의 형식이 같아야 합니다. 일반적으로 열의 경우 UNION와 같이 열이 암시적으로 변환 가능한 형식으로 충분하지 않습니다.

     또한 적어도 하나 이상의 열(예: <col>)이 같은 서수 위치에 있는 모든 SELECT 목록에 표시되어야 합니다. 멤버 테이블 <col>에서 CHECK 제약 조건 T1, ..., Tn이 각각 C1, ..., Cn에 정의되는 것과 같이 <col>을 정의합니다.

     C1 테이블에 정의되는 T1 제약 조건은 다음 형식을 따라야 합니다.

     C1 ::= < simple_interval > [ OR < simple_interval > OR ...]  
     < simple_interval > :: =   
     < col > { < | > | \<= | >= | = < value >}   
     | < col > BETWEEN < value1 > AND < value2 >  
     | < col > IN ( value_list )  
     | < col > { > | >= } < value1 > AND  
     < col > { < | <= } < value2 >  
     

   • 제약 조건은 <col>의 지정된 값이 모두 C1, ..., Cn 제약 조건을 최대 하나까지 만족시켜 제약 조건이 결합되지 않거나 겹치지 않는 일련의 간격을 구성하도록 해야 합니다. 결합되지 않은 제약 조건이 정의된 <col> 열을 분할 열이라고 합니다. 분할 열은 기본 테이블에 서로 다른 이름을 가질 수 있습니다. 앞에서 언급한 분할 열의 조건을 만족시키려면 제약 조건이 활성화되어 트러스트된 상태여야 합니다. 제약 조건이 사용하지 않도록 설정된 경우 해당 옵션을 사용하고 유효성을 검사하는 옵션을 ALTER TABLE사용하여 CHECK CONSTRAINT *constraint_name*WITH CHECK 제약 조건 검사를 다시 사용하도록 설정합니다.

     다음 예에서는 올바른 제약 조건 집합을 보여 줍니다.

     { [col < 10], [col between 11 and 20] , [col > 20] }  
     { [col between 11 and 20], [col between 21 and 30], [col between 31 and 100] }  
     

   • SELECT 목록에 같은 열을 여러 번 사용할 수 없습니다.

2. 분할 열

   • 분할 열은 테이블에 있는 PRIMARY KEY의 일부입니다.

   • 분할 열은 계산 열, ID 열, 기본 열 또는 timestamp 열이 될 수 없습니다.

   • 멤버 테이블의 동일한 열에 제약 조건이 둘 이상 있는 경우에는 데이터베이스 엔진에서 뷰가 분할 뷰인지 여부를 결정할 때 모든 제약 조건을 고려하지 않고 무시합니다. 분할 뷰의 조건을 만족하려면 분할 열에 분할 제약 조건이 하나만 있어야 합니다.

   • 분할 열의 업데이트 가능성에는 제한이 없습니다.

3. 멤버 테이블 또는 기본 테이블 T1, ..., Tn

   • 테이블은 4부분으로 된 이름 또는 OPENDATASOURCE나 OPENROWSET 기반 이름을 통해 참조되며 SQL Server를 실행하는 다른 컴퓨터의 로컬 테이블 또는 테이블이 될 수 있습니다. OPENDATASOURCE 및 OPENROWSET 구문은 테이블 이름을 지정할 수 있으나 통과 쿼리는 지정할 수 없습니다. 자세한 내용은 OPENDATASOURCE(Transact-SQL) 및 OPENROWSET(Transact-SQL)을 참조하세요.

     하나 이상의 멤버 테이블이 원격이면 뷰를 분산형 분할 뷰라고 하며 추가 조건이 적용됩니다. 자세한 내용은 이 섹션의 뒷부분에서 설명합니다.

   • 문과 UNION ALL 결합되는 테이블 집합에는 같은 테이블이 두 번 표시될 수 없습니다.

   • 멤버 테이블은 테이블의 계산 열에 대해 만들어진 인덱스를 가질 수 없습니다.

   • 멤버 테이블은 같은 수의 열에 모두 PRIMARY KEY 제약 조건이 있습니다.

   • 뷰에 있는 모든 멤버 테이블의 ANSI 패딩 설정이 같습니다. 이 옵션은 사용자 옵션 옵션 또는 sp_configure SET 문을 사용하여 설정할 수 있습니다.

분할된 뷰의 데이터를 수정하는 문에는 다음 제한이 적용됩니다.

• 이 문은 INSERT 기본 멤버 테이블에 DEFAULT 해당 열에 대한 제약 조건이 있거나 값을 허용하는 경우에도 뷰의 모든 열에 대한 NULL 값을 제공합니다. 정의가 있는 DEFAULT 멤버 테이블 열의 경우 문은 키워드 DEFAULT를 명시적으로 사용할 수 없습니다.

• 분할 열에 삽입되는 값은 기본 제약 조건 중 하나 이상을 충족합니다. 그렇지 않으면 제약 조건 위반으로 삽입 작업이 실패합니다.

• UPDATE 열에 DEFAULT 해당 멤버 테이블에 정의된 값이 있더라도 문은 키워드를 절의 값 SET 으로 DEFAULT 지정할 수 없습니다.

• 하나 이상의 멤버 테이블에 있는 ID 열인 뷰의 열은 또는 UPDATE 문을 사용하여 INSERT 수정할 수 없습니다.

• 멤버 테이블 중 하나에 타임스탬프 열이 있는 경우 또는 UPDATE 문을 사용하여 INSERT 데이터를 수정할 수 없습니다.

• 멤버 테이블 중 하나에 트리거 또는 ON UPDATE CASCADE/SET NULL/SET DEFAULTON DELETE CASCADE/SET NULL/SET DEFAULT 제약 조건이 포함되어 있으면 뷰를 수정할 수 없습니다.

• INSERT DELETE 동일한 UPDATE뷰를 사용하거나 문에 멤버 테이블을 사용하는 자체 조인이 있는 경우 분할된 뷰에 대한 작업은 허용되지 않습니다.

• 분할된 뷰로 데이터를 대량으로 가져오는 것은 지원되지 않거나 문에 INSERT ... SELECT * FROM OPENROWSET(BULK...) 의해 bcpBULK INSERT 지원되지 않습니다. 그러나 INSERT 문을 사용하여 분할된 뷰에 여러 행을 삽입할 수 있습니다.

  참고

  분할된 뷰를 업데이트하려면 사용자에게 멤버 테이블에 대한 권한 및 DELETE 권한이 있어야 합니다.INSERTUPDATE

분산형 분할 뷰(하나 이상의 멤버 테이블이 원격일 때)의 경우 다음 추가 조건이 적용됩니다.

• 분산 트랜잭션은 업데이트의 영향을 받는 모든 노드에서 원자성을 보장하기 위해 시작됩니다.

• XACT_ABORT SET작동할 ON 문 UPDATE또는 DELETE 문에 대한 INSERT옵션을 설정합니다.

• 분할 뷰에서 참조되는 smallmoney 형식의 원격 테이블 열은 money로 매핑됩니다. 따라서 로컬 테이블의 해당 열(SELECT 목록의 동일한 서수 위치에 있는 열)도 money 형식이어야 합니다.

• 데이터베이스 호환성 수준 110 이상에서는 분할 뷰에서 참조되는 smalldatetime 형식의 원격 테이블 열이 smalldatetime으로 매핑됩니다. 로컬 테이블의 해당 열(SELECT 목록의 동일한 서수 위치에 있는 열)은 smalldatetime이어야 합니다. 이 동작은 분할 뷰에서 참조되는 smalldatetime 형식의 원격 테이블 열이 datetime으로 매핑되고 로컬 테이블의 해당 열이 datetime 형식이어야 하는 이전 버전 SQL Server의 동작에서 달라진 점입니다. 자세한 내용은 ALTER DATABASE 호환성 수준(Transact-SQL)을 참조하세요.

• 분할 뷰의 연결된 서버는 루프백 연결 서버가 될 수 없습니다. 이 서버는 같은 SQL Server 인스턴스를 가리키는 연결된 서버입니다.

이 옵션의 SET ROWCOUNT 설정은 업다이블 분할된 INSERTUPDATE뷰 및 원격 테이블과 관련된 , 및 DELETE 작업에 대해 무시됩니다.

멤버 테이블 및 분할 뷰 정의가 지정되면 SQL Server 쿼리 최적화 프로그램은 쿼리를 효율적으로 사용하는 지능적 계획을 수립하여 멤버 테이블의 데이터에 액세스합니다. CHECK 제약 조건 정의를 사용하여 쿼리 프로세서는 멤버 테이블에 키 값의 분포를 매핑합니다. 사용자가 쿼리를 실행하면 쿼리 프로세서는 맵을 절에 WHERE 지정된 값과 비교하고 멤버 서버 간에 최소한의 데이터 전송으로 실행 계획을 작성합니다. 따라서 일부 멤버 테이블이 원격 서버에 있는 경우 SQL Server 인스턴스는 분산 쿼리를 확인하므로 전송해야 하는 분산 데이터의 양이 최소화됩니다.

복제와 관련된 멤버 테이블에 분할 뷰를 만들려면 다음을 고려해야 합니다.

• 기본 테이블이 업데이트 구독이 있는 트랜잭션 복제 또는 병합 복제와 관련된 경우에는 uniqueidentifier 열도 SELECT 목록에 포함되어야 합니다.

  분할된 뷰에 대한 모든 INSERT 작업은 uniqueidentifier 열에 대한 값을 제공해야 NEWID() 합니다. UNIQUEidentifier 열에 대한 UPDATE 작업은 DEFAULT 키워드를 사용할 수 없으므로 값으로 제공해야 NEWID() 합니다.

• 뷰를 사용하여 수행된 업데이트의 복제는 서로 다른 두 데이터베이스에서 테이블이 복제될 때와 동일합니다. 서로 다른 복제 에이전트에서 테이블을 제공하며 업데이트 순서는 보장되지 않습니다.

데이터베이스에는 CREATE VIEW 권한이 필요하고 뷰를 만들 구성표에는 ALTER 권한이 필요합니다.

다음 예제에서는 또는 AdventureWorks2022 데이터베이스를 AdventureWorksDW2022 사용합니다.

다음 예제에서는 문을 사용하여 뷰를 SELECT 만듭니다. 간단한 뷰는 열 조합을 자주 쿼리할 때 유용합니다. 이 보기의 데이터는 AdventureWorks2022 데이터베이스의 테이블과 HumanResources.Employee 테이블에서 Person.Person 가져옵니다. 이 데이터는 Adventure Works Cycles의 직원 이름과 채용 날짜 정보를 제공합니다. 입사일 추적 담당자에게 이 테이블의 모든 데이터에 액세스할 권한을 주지 않아도 해당 뷰를 만들 수 있습니다.

CREATE VIEW hiredate_view  
AS
SELECT p.FirstName, p.LastName, e.BusinessEntityID, e.HireDate  
FROM HumanResources.Employee AS e   
JOIN Person.Person AS p ON e.BusinessEntityID = p.BusinessEntityID ;  
GO  

다음 예에서는 WITH ENCRYPTION 옵션을 사용하여 계산 열, 이름이 바뀐 열 및 복수 열을 보여 줍니다.

적용 대상: SQL Server 2008(10.0.x) 이상 및 SQL Database

CREATE VIEW Purchasing.PurchaseOrderReject  
WITH ENCRYPTION  
AS  
SELECT PurchaseOrderID, ReceivedQty, RejectedQty,   
    RejectedQty / ReceivedQty AS RejectRatio, DueDate  
FROM Purchasing.PurchaseOrderDetail  
WHERE RejectedQty / ReceivedQty > 0  
AND DueDate > CONVERT(DATETIME,'20010630',101) ;  
GO  

다음 예에서는 5개의 테이블을 참조하고 데이터 수정을 허용하여 시애틀에 사는 직원에게만 적용하는 dbo.SeattleOnly라는 뷰를 보여 줍니다.

CREATE VIEW dbo.SeattleOnly  
AS  
SELECT p.LastName, p.FirstName, e.JobTitle, a.City, sp.StateProvinceCode  
FROM HumanResources.Employee e  
INNER JOIN Person.Person p  
ON p.BusinessEntityID = e.BusinessEntityID  
    INNER JOIN Person.BusinessEntityAddress bea   
    ON bea.BusinessEntityID = e.BusinessEntityID   
    INNER JOIN Person.Address a   
    ON a.AddressID = bea.AddressID  
    INNER JOIN Person.StateProvince sp   
    ON sp.StateProvinceID = a.StateProvinceID  
WHERE a.City = 'Seattle'  
WITH CHECK OPTION ;  
GO  

다음 예에서는 기본 제공 함수를 포함하는 뷰 정의를 보여 줍니다. 함수를 사용할 때는 파생 열의 열 이름을 지정해야 합니다.

CREATE VIEW Sales.SalesPersonPerform  
AS  
SELECT TOP (100) SalesPersonID, SUM(TotalDue) AS TotalSales  
FROM Sales.SalesOrderHeader  
WHERE OrderDate > CONVERT(DATETIME,'20001231',101)  
GROUP BY SalesPersonID;  
GO  

다음 예에서는 SUPPLY1, SUPPLY2, SUPPLY3 및 SUPPLY4 테이블을 사용합니다. 이러한 테이블은 서로 다른 지역에 있는 4개의 사무실의 공급업체 테이블에 해당합니다.

--Create the tables and insert the values.  
CREATE TABLE dbo.SUPPLY1 (  
supplyID INT PRIMARY KEY CHECK (supplyID BETWEEN 1 and 150),  
supplier CHAR(50)  
);  
CREATE TABLE dbo.SUPPLY2 (  
supplyID INT PRIMARY KEY CHECK (supplyID BETWEEN 151 and 300),  
supplier CHAR(50)  
);  
CREATE TABLE dbo.SUPPLY3 (  
supplyID INT PRIMARY KEY CHECK (supplyID BETWEEN 301 and 450),  
supplier CHAR(50)  
);  
CREATE TABLE dbo.SUPPLY4 (  
supplyID INT PRIMARY KEY CHECK (supplyID BETWEEN 451 and 600),  
supplier CHAR(50)  
);  
GO  
--Create the view that combines all supplier tables.  
CREATE VIEW dbo.all_supplier_view  
WITH SCHEMABINDING  
AS  
SELECT supplyID, supplier  
  FROM dbo.SUPPLY1  
UNION ALL  
SELECT supplyID, supplier  
  FROM dbo.SUPPLY2  
UNION ALL  
SELECT supplyID, supplier  
  FROM dbo.SUPPLY3  
UNION ALL  
SELECT supplyID, supplier  
  FROM dbo.SUPPLY4;  
GO
INSERT dbo.all_supplier_view VALUES ('1', 'CaliforniaCorp'), ('5', 'BraziliaLtd')    
, ('231', 'FarEast'), ('280', 'NZ')  
, ('321', 'EuroGroup'), ('442', 'UKArchip')  
, ('475', 'India'), ('521', 'Afrique');  
GO  

다음 예에서는 SELECT이 있는 OUTER JOIN 문을 사용하여 뷰를 만듭니다. 조인 쿼리의 결과가 뷰를 채웁니다.

CREATE VIEW view1  
AS 
SELECT fis.CustomerKey, fis.ProductKey, fis.OrderDateKey, 
  fis.SalesTerritoryKey, dst.SalesTerritoryRegion  
FROM FactInternetSales AS fis   
LEFT OUTER JOIN DimSalesTerritory AS dst   
ON (fis.SalesTerritoryKey=dst.SalesTerritoryKey);  

• ALTER TABLE(Transact-SQL)
• ALTER VIEW(Transact-SQL)
• DELETE (Transact-SQL)
• DROP VIEW(Transact-SQL)
• INSERT(Transact-SQL)
• 저장 프로시저 만들기
• sys.dm_sql_referenced_entities(Transact-SQL)
• sys.dm_sql_referencing_entities(Transact-SQL)
• sp_help(Transact-SQL)
• sp_helptext(Transact-SQL)
• sp_refreshview(Transact-SQL)
• sp_rename(Transact-SQL)
• sys.views(Transact-SQL)
• UPDATE(Transact-SQL)
• EVENTDATA(Transact-SQL)