DBMS 2
DA, SQL, DB보안 등 실무자를 위한 위한 DB기술 바이블!
SQL Server 2005 설치하면서 가장 먼저 알 수 있는 사실은 설치 작업이 통합되어 있다는 것입니다. 이제 더 이상 Analysis Services와 같은 일부 기능을 위해 설치 프로그램을 별도로 실행할 필요가 없습니다. Reporting Services와 같은 기능을 설치할 수 없다면 이는 컴퓨터가 그 기능의 설치 요구 사항을 충족시키지 않는 것입니다. 필수 기능에 대한 자세한 설명은 추가 정보 파일을 참조하십시오. 설치 프로세스에 따라 다음을 설치합니다. Reporting Services를 사용하려면 IIS가 설치되고 정확하게 구성되어 있어야 합니다. Reporting Services는 SQL Server 2005 Business Intelligence 기능 집합의 필수적인 부분이므로 시간이 들더라도 IIS를 구성 및 설치하는 것이 좋습니다. Analysis Services에 익숙한 고객이라면 Analysis Services 메타데이터 리포지토리가 없는 것을 의아해 할 것입니다. SQL Server 2000에서는 Analysis Services 리포지토리가 Microsoft Access 데이터베이스로 제공되었지만 Analysis Services 2005에는 메타데이터 리포지토리가 없습니다. 대신 Analysis Services 데이터베이스 메타데이터 정보는 XML 파일로 저장되어 Analysis Services가 관리합니다. 이 XML 파일은 필요할 경우 소스 제어 아래에 둘 수 있습니다. Business Intelligence Development Studio를 사용하여 BI 데이터베이스 개체를 개발하고 SQL Server Management Studio를 사용하여 이 BI 개체를 실행 및 유지 관리하는 것이 좋습니다 SQL Server Management Studio에서 Integration Services 패키지와 Analysis Services 큐브 및 마이닝 모델을 설계할 수 있지만 Business Intelligence Development Studio는 BI 응용 프로그램 설계 및 디버깅에 사용하기에 보다 효과적입니다. 기존 DTS 패키지나 Analysis Services 데이터베이스를 업그레이드하기 보다는 새 응용 프로그램으로 시작하면 아마 더 많은 것을 배울 수 있을 것입니다. 기존 패키지나 데이터베이스가 있는 경우 이것을"다시 만드는"편이 유용할 수도 있습니다. 기존 개체 업그레이드는 이 새로운 도구와 기능 및 개념에 더 익숙해진 다음 시도해 보십시오. 많은 고객이 SQL Server 도구를 사용하여 이제 익숙해진 하나 이상의 원본 시스템의 비즈니스 인텔리전스 구조를 가진 시스템을 개발하게 될 것입니다. 이 시스템은 Integration Services를 사용하여 차원 관계형 데이터 웨어하우스에 데이터를 채우고, 데이터 웨어하우스는 다시 Analysis Services 데이터베이스에 데이터를 채웁니다. 그러나 SQL Server 2005는 서로 다른 구성 요소를 없애거나 가상화함으로써 이 일반 적인 설계로부터 벗어나는 많은 옵션을 제공합니다. SQL Server 2005 관계형 데이터베이스 엔진은 데이터 웨어하우스 방식 응용 프로그램의 설계 및 유지 관리에 유용한 일부 기능을 포함하고 있습니다. 이러한 기능은 다음과 같습니다. 트랜잭션 데이터베이스에서 관계형 작업 보고를 오프로드하는데 사용되는 일반적인 기술은 보고 서버를 유지 관리하는 것입니다. 보고 서버는 약간의 지연 시간을 가지면서, 대개의 경우 전날의 트랜잭션 데이터베이스 이미지를 유지 관리합니다. 또한 보고 서버는 대부분의 보고 및 데이터 웨어하우스 추출에 사용됩니다. Microsoft SQL Server 2005에는 보고 서버를 아주 쉽게 만들고 유지 관리할 수 있는 데이터베이스 미러링과 데이터베이스 스냅샷이라는 새로운 두 가지 기능이 추가되었습니다. 이제 SQL Server 보고 서버의 지연 시간은 하루에 한 번 미만으로 훨씬 더 짧아집니다. 또한, 보고 서버는 트랜잭션 시스템의 대기 시스템 역할을 할 수 있도록 만들어졌습니다. 보고 서버를 만들려면 먼저 가용성이 높Server 2005의 기능인 데이터베이스 미러를 만듭니다. 자세한 내용은 SQL Server Books Online에서"데이터베이스 미러링 개념"항목을 참조하십시오. 데이터베이스 미러는 직접 쿼리할 수가 없는데, 두 번째 새로운 기능인 데이터 스냅샷이 바로 이 역할을 합니다. 이 미러에서 데이터베이스 스냅샷을 만들면 보고를 위해 데이터의 추가 사본을 제공할 수 있습니다. 데이터베이스 스냅샷은 특정 시간대의 읽기 전용 데이터베이스 사본이며, 원본 데이터베이스가 변경될 때 새로운 정보로 자동 업데이트되지 않습니다. 데이터베이스 스냅샷은 수많은 사용 시나리오가 존재하는 다방면에 관계된 항목입니다. 자세한 내용은 SQL Server Books Online에서“데이터베이스 뷰 이해”항목을 참조하십시오. 그러나 지금은 스냅샷의 정보 저장 방식이 매우 공간 효율적이라는 것만 알고 넘어 갑니다. 데이터베이스 스냅샷 유지 관리는 그 데이터베이스 스냅샷이 기반으로 하는 트랜잭션 데이터베이스에 약간의 영향을 미치긴 하지만, 보고를 위한 데이터의 전체 뷰를 제공하기 위해 다수의 데이터베이스 스냅샷이 존재할 수 있습니다. 데이터베이스 미러에서 데이터베이스 스냅샷을 만들면 대기 서버를 손쉽게 만들어 시스템 가용성을 높일 수 있으므로 데이터베이스 스냅샷이 고가용성 솔루션에 사용될 뿐만 아니라 보고 서버로서의 이중 임무를 다할 수 있습니다. 분할된 테이블과 인덱스는 데이터를 가로 단위로 구분하므로, 행 그룹이 개별 파티션으로 매핑됩니다. 이 데이터에서 실행되는 쿼리와 같은 작업은 테이블이나 인덱스 전체가 하나의 엔티티인 것처럼 실행됩니다. 관계형 데이터 웨어하우스에서 팩트 테이블이 테이블 분할의 가장 유력한 후보이며, 날짜별 구분이 가장 일반적인 분할 전략입니다. SQL Server Books Online의“분할된 테이블 및 인덱스 만들기”항목에 설명된 것처럼, 분할된 테이블 정의는 다음 세 단계로 이루어집니다. 여러 테이블이 동일한 파티션 구성표를 사용할 수 있습니다. 대부분의 데이터 웨어하우스 응용 프로그램은 점점 줄어들고 있는 작은 로드 창에서 점점 늘어나는 엄청난 양의 데이터를 로드하기 위해 허덕이고 있습니다. 일반적인 프로세스는 몇몇 원본 시스템에서 데이터를 추출한 다음 이들 시스템 전반에서 그 데이터를 정리, 변환, 종합화 및 합리화하는 것입니다. 데이터 관리 응용 프로그램은 그 로드 창 내에서 추출, 변환, 로딩(ETL) 프로세스를 모두 완료해야 합니다. 일반적으 로 이 시스템의 비즈니스 사용자는 이 시스템이 데이터 웨어하우스를 쿼리에 사용할 수 없는 시간을 최소화할 수 있기를 강력히 요구합니다. 새 데이터가 기존 데이터 웨어하우스에 삽입되는 데이터 관리 응용 프로그램의"쓰기"단계는 사용자에게 미치는 영향을 최소화하고 신속하 게 이루어져야 합니다. 데이터를 신속하게 로드하기 위해서는 데이터 복구 모델이 반드시 대량 기록 또는 텍스트여야 하며 테이블은 비어 있거나 인덱스 없이 데이 터만 들어 있어야 합니다. 이러한 조건이 충족되어야만 비 로그 작업을 로드할 수 있습니다. 분할된 테이블이 존재하지 않았던 SQL Server 2000에서는 일반적으로 초기 기록 데이터 웨어하우스 로드만이 이러한 조건을 충족시킬 수 있었습니다. 그래서 대형 데이터 웨어하우스를 가진 일부 고객은 별도의 실제 테이블에 UNION ALL 뷰를 구성하여 의사 파티션 구조를 구축했으며, 이러한 테이블은 비 로그 기술을 사용하 는 개별 로드 주기로 채워졌습니다. 하지만 이 방법은 그리 만족스럽지 않았고, SQL Server 2005 분할 테이블은 더 우수한 기능을 제공합니 다. SQL Server 2005에서는 파티션에 직접 비 로그 로드를 수행할 수 없습니다. 그러나 의사(pseudo) 파티션을 호출할 별도의 테이블로 로드할 수는 있습니다. 특정 조건에서는 매우 빠르게 발생하는 메타데이터 작업으로서 의사(pseudo) 파티션을 분할 테이블로 전환할 수 있습니다. 이 기술은 다음 두 가지 요구 사항을 충족합니다. 그 외에도, 의사(pseudo) 파티션은 별도의 테이블로 백업할 수 있으므로 시스템 관리 효율이 향상됩니다. 많은 데이터 웨어하우스는 그 데이터 웨어하우스 내에 세부 데이터 이동 창을 가지고 있습니다. 예를 들면 팩트 테이블은 3년, 5년 또는 10년 간 데이터를 보관할 수 있습니다. 따라서 오래된 데이터는 정기적으로 그 테이블에서 제거됩니다. 계속해서 데이터를 없애는 가장 큰 이유는 쿼리 성능을 높이고 저장 비용을 최소화하기 위한 것입니다. SQL Server 2005 파티션을 이용하면 분할된 큰 팩트 테이블에서 오래된 데이터를 아주 쉽게 제거할 수 있습니다. 앞서 설명한 것처럼 빈 의사(pseudo) 파티션을 만들어 그 파티션을 분할된 테이블로 전환하기만 하면 됩니다. 그러면 분할된 이 테이블은 채워진 파티션이 있던 자리에 빈 파티션이 생기며, 비어 있는 이 의사(pseudo) 파티션에 데이터가 채워집니다. 이렇게 되면 필요에 따라 의사(pseudo) 파티션을 백업하거나 자르거나 제거할 수 있습니다. 파티션 함수를 재정의하여 비어 있는 모든 파티션을 하나로 병합할 수 있는 옵션도 있습니다. 다음은 데이터 웨어하우징에 유용하게 사용될 중요한 몇 가지 새 데이터 형식입니다. Varchar(max), nvarchar(max), varbinary(max)는 데이터를 최고 2GB까지 보유하며, text, ntext, image 데이터 형식의 대체 형식으로 유용 하게 사용할 수 있을 것입니다. 이러한 확장 문자 형식은 확장된 메타데이터 및 다른 설명 정보를 한 데이터 웨어하우스에 보관하는 데 유용합니다. 몇몇 새 분석 함수가 Transact-SQL 내에 기본 분석 기능을 제공합니다. 이 함수를 사용하면 Analysis Services 전체가므로 데이터 웨어하우스에 유용할 것입니다. 또한, 이러한 복잡한 계산은 일반적으로 유용한 데이터 속성을 개발하 는 데이터 준비 과정에도 사용됩니다. ROW_NUMBER. 결과 집합의 순차 행 번호를 반환합니다. RANK. 결과 집합의 행 순위를 반환합니다. 값이 같은 행이 없다면 RANK는 ROW_NUMBER와 같습니다. 값이 동일하게 정렬된 행은 모두 동일한 순위를 가지며, 다음 순위는 다시 ROW_NUMBER와 일치합니다. 다시 말해, 1, 2행의 값이 동일하다면 1행과 2행은 RANK=1이, 3행 은 RANK=3이 반환되며 RANK=2가 반환되는 행은 없습니다. DENSE_RANK. 결과 집합의 행 순위를 반환합니다. DENSE_RANK 함수는 RANK와 비슷하지만 RANK 함수에서 발생하는 틈이 없다는 점이 다릅니다. 즉, 위의 예에서 1행과 2행은 RANK=1 이, 3행은 RANK=2가 반환됩니다. NTILE. 정렬된 집합을 거의 동일한 크기의 지정된 그룹 수로 나눕니다. PIVOT 연산자를 사용하면 쿼리에서 중단 값에 따라 결과 집합을 피벗하여 크로스탭 보고서를 생성할 수 있습니다. 예를 들어 테이 들어 있는 경우 PIVOT 연산자를 사용하면 [Actuals]와 [Budgets]라는 이름의 열을 가진 크로스탭 보고서를 생성할 수 있습니다. 한편 UNPIVOT 연산자를 사용하면 한 행을 다수의 행으로 나눌 수 있습니다. 즉, 위의 예에서 [Actuals]와 [Budgets]가 있는 행 집합을 이러한 값이 붙은 다수의 행으로 변환할 수 있습니다. SQL Server 이전 버전에서는 복잡한 Transact-SQL SELECT 문을 작성해야만 데이터를 회전할 수 있었습니다. PIVOT과 UNPIVOT 연산자는 데이터를 회전할 수 있는 간단한 메커니즘을 제공합니다. "재귀 쿼리"가 아주 유용하게 사용되는 몇 가지 경우가 있습니다. SQL Server 2005의 새로운 기능을 이용하면 재귀 쿼리는 쉽지는 않더라도 가능하게 됩니다. 재귀 쿼리는 셀프 조인 기능이 있는 테이블의 쿼리입니다. 가장 일반적으로 사용되는 2가지 예는 직원 및 관리자 정보가 들어 있는 테이블과 자재 명세서 테이블입니다. 셀프 조인 테이블은 AdventureWorks 데이터베이스, Employee 테이블을 보면 알 수 있습니다. 한 상사에게 직접 보고하는 직원의 수와 같이 직접적인 관계에 대한 셀프 조인 테이블에 쿼리하기는 쉽습니다. 하지만"한 관리자의 조직에 있는 직원 수는 얼마입니까?"와 같은 질문은 답하기가 좀 더 어렵습니다. 이 문제를 해결하는 SQL Server 2005 관계형 데이터베이스 기능을"재귀 일반 테이블 식"이라고 합니다 자세한 내용은 SQL Server Books Online에서"WITH "항목을 참조하십시오.관계형 데이터 웨어하우징
SQL Server 2005 시작
관계형 데이터 웨어하우징
보고 서버:
테이블 파티션
파티션 분할은 다음과 같은 효과가 있습니다.
본 문서에서는 팩트 테이블의 범위 분할만을 다루며, 테이블 분할에 대한 전체적인 설명은 제공하지 않습니다. 테이블 분할에 대한 자세한 내용은 SQL Server Books Online을 참조하십시오.
가 장 일반적인 분할 구성표는 팩트 테이블을 년, 분기, 월 또는 일 등의 날짜 범위로 분할하는 것입니다. 대부분의 경우 큰 팩트 테이블을 날짜별로 분할하면 관리 효율성이 상당히 향상됩니다. 쿼리 성능을 높이려면 시간 차원 테이블도 동일한 파티션 구성표를 사용하여 분할해야 합니다.
테이블 파티션을 사용한 신속한 데이터 로드
이 파티션 전환 작업은 거의 1초도 걸리지 않을 만큼 매우 신속하게 이루어집니다.
테이블 파티션을 사용한 신속한 데이터 삭제
Transact-SQL 기능 향상
새로운 데이터 형식
새로운 분석 함수
PIVOT 및 UNPIVOT 연산자
재귀 쿼리