재고되고 있는 데이터 정규화, Part 1: 비즈니스 기록의 역사

재고되고 있는 데이터 정규화, Part 1: 비즈니스 기록의 역사

컴퓨터 시스템에서 유지되는 기록의 조사

소개

이 기사에서는 상업용 시스템의 데이터 정규화의 역할이[30] 변화하는 과정을 설명한다. 1970년대 이후, 데이터 정규화가 정의되었을 때 컴퓨터 기술과 시스템 및 애플리케이션은 상당히 진화했다. 특히 1970년대에는 데이터 구조가 안정적이었으며 디스크 공간은 매우 제한되어 있었고 비즈니스 정보는 종이에 기록되어 있었다. 종이를 컴퓨터가 읽을 수 있는 형식(예: 천공 카드)으로 변환하려면 사람들과 입/출력(I/O) 디바이스가 필요했다. 은행과 같은 기관에서 소유한 대형 컴퓨터는 메모리 용량이 512KB였으며 가격은 거의 142,000,000였다. 대형 기관에는 모든 컴퓨터 시스템과 데이터를 저장하기 위해 10MB의 디스크 공간이 있었다. 1970년대에는 인터넷 인프라가 막 구축되기 시작했으며 월드 와이드 웹은 10년이 지난 후에나 개발되었다.

디스크 공간이 극히 제한되어 있었기 때문에 최신 정보만 저장해서 애플리케이션에서 사용할 수 있게 하였다. 정규화는 이름, 주소 또는 주문 정보와 같은 각 데이터 조각을 디스크에서 정확히 한 번만 표시하여 데이터 이상 항목을 피하고 공간을 보존할 수 있게 한다. 일반적으로 데이터 정규화는 컴퓨터 시스템에만 존재하며 데이터의 원래 비즈니스 표현과 일치하지는 않는다. 21세기에는 비즈니스 데이터가 거의 언제나 웹 서비스 요청의 주문 메시지와 같은 디지털 형식으로 작성되었다. 따라서 정규화는 디지털로 표현된 기존의 비즈니스 기록을 쪼개서 데이터베이스에 저장한 다음, 나중에 다시 재구성하여 이러한 비즈니스 기록을 표시하고 사용한다.

관계형 모델의 기반이 되는 가정이 변화되었다. 오늘날에는 대부분이 시스템과 정보 구조가 더 이상 단순하거나 고정되어 있지 않고 복잡하며 빠른 속도로 변한다. 오늘날의 세계에서는 프로세스로서의 정규화가 애자일 시스템의 전달과 시스템의 애자일 전달 모두에 억제제로 역할을 한다.

이 기사에서는 상업용 컴퓨터가 도입되기 전후의 역사를 살펴보면서 기록 유지에 대해 소개할 것이다. 주목할 만한 점은 역사적으로는 비즈니스 기록을 "그대로" 저장하였으며 컴퓨터가 도입되면서 기록을 여러 개의 조각으로 분리(정규화)하기 시작했다. 이 기사에서는 1970년대에 데이터 정규화를 개발하게 된 동기를 살펴본다. 그다음에는 어느 정도의 데이터 비정규화가 일반적으로 적용되는 타협점이 된다는 점을 설명한다. 끝으로 이 기사에서는 비즈니스 기록이 디지털 형식으로 작성될 수 있게 하는, 비즈니스 기록에 대한 웹의 영향을 살펴본다. 결과적으로 처음에는 비즈니스 기록을 컴퓨터에서 원래 구조로 저장하고 처리하는 것이 가능했다.

히스토리를 통해 기록 유지

이 섹션에서는 컴퓨터가 도입되기 이전의 기록 유지의 특성을 설명하는데, 이는 컴퓨터가 도입되면서 생긴 중요한 변화를 이해하는 데 도움이 된다. 이러한 변화는 나중에 설명한다.

오래 전인 BC 3천년 경에 고대 수메리아[?1]에서 진흙판 형태의 수집된 영수증이 발견되었으며 이러한 영수증은 교환된 후, 기록 유지를 위해 저장되었다. BC 18세기[?2] 경에는 바빌로니아의 대부 기록이 발견되었다. BC 1792년에 바빌론에서 발견된 함무라비 법전에는[3] 진흙판으로 된 기록의 처리 및 유지를 통제하는 문구가 포함되어 있다. 예를 들면, 다음과 같다.

- 빚을 지고 있는데, 폭풍우로 인해 곡식이 피해를 입거나, 수확에 실패하거나 물이 부족하여 곡물이 성장하지 않으면, 그 해에는 채권자에게 곡물을 주지 않아도 되므로 빚진 사람은 계약서(진흙판)를 수정하고 그 해의 이자는 지불하지 않는다.

- 타인의 토지나 집을 샀는데 이 토지나 집이 토지세의 적용을 받는 경우 해당 판매 계약서(진흙판)는 파기되고(무효로 선언됨) 매수자는 돈을 잃게 된다. 토지와 집은 원래의 소유자에게 되돌아간다.

역사적으로 보면 거래 정보를 기록하기 위해 엄대와[?4][?5] 같은 다양한 메커니즘을 도입하였으며 이러한 것들은 종이보다 더 저렴했으며 더 신속하게 이용할 수 있었다. 중세 유럽에서는 막대기에 새김눈을 표기한 후, 세로로 쪼갰다. 반으로 자른 두 개의 막대기에는 동일한 새김눈이 있으며 각 거래 당사자는 증거로서 표시된 막대기의 절반을 받았다. 그런 후에는 이 막대기를 보관하여 유지했다. 쪼개진 엄대는 1826년까지 영국 정부에서 세금을 관리하기 위해 계속해서 사용했다. 더욱 현대적인 기록 방법이[?5] 도입되면서 1834년에는 엄대 상점을 소각하라는 명령이 내려졌다.

20세기 말까지는 비즈니스 거래, 판매 계산서, 계약서 및 기타 중요한 문서를 기록하기 위해 종이와 초창기의 파피루스 및 피지[?6]를 널리 사용했다. 기록물에는 서명을 하였으며 때로는 왁스로 밀봉을 하고 관련된 상인의 표식을 부착했다. 복식 부기와 같은 방법은 15세기에 도입되었다. 서류 작업이 증가했기 때문에 서기가 상인을 지원했다. 20세기에 들어와 컴퓨터가 상업용으로 전환되면서 기업에서는 시스템에 컴퓨터를 도입하기 시작했으며 이렇게 하기 위해서는 실제 종이 기록을 컴퓨터가 인식할 수 있는 표현으로[??7] 전환해야 했다.

컴퓨터가 도입되기 전에는 거래 당사자 간에 교환되는 정보의 정확한 사본을 캡처하여 유지하는 것이 기본적인 기록 보관 원칙이었다. 기록물에는 서명을 하거나 몇 가지 방법으로 표시를 하고 "그대로" 저장하여 나중에 다시 사용할 수 있게 했다. 역사적으로 보면 비즈니스 기록과 계약서의 저장 및 처리를 통제하는 규정이 존재했다.

컴퓨터 시스템의 기록 관리

이 섹션에서는 20세기의 두 번째 파트에서 데이터베이스가 도입된 환경과 이러한 시스템의 기본 목적을 설명한다.

1950년대와 1960년대에 상업 비즈니스를 지원하기 위해 디지털 컴퓨터 시스템을 도입하면서 처음으로 기록이 종이 천공 카드에[8] 저장되었으며 이러한 천공 카드는 입출력을 위해 자주 사용되었다. 오퍼레이터가 비즈니스 거래가 표현된 종이 기록물의 내용을 카드에 입력했기 때문에 컴퓨터가 정보를 읽고 사용할 수 있었다(그림 1). 천공된 카드를 사용하던 시기에 컴퓨터에 데이터를 입력한 방법과 일치하지는 않지만, 컴퓨터 시스템 안에서 저장되고 처리 되는 데이터는 종이에 있는 실제 비즈니스 거래와 더 이상 일치하지 않았다.

대용량 데이터를 컴퓨터 시스템에 입출력하기 위해 계속해서 천공 카드를 사용했지만 1980년대에는 자기 테이프를[9] 사용했으며 곧 디스크 스토리지가[?10] 1960년대의 대형 시스템에서 사용되던 천공 카드를 대체했다. 디스크 스토리지 시대가 도래하면서(그림 2), 디스크의 개별 부분을 프로그래밍 방식으로 주소를 지정할 수 있게 되었기 때문에 데이터를 직접적으로 신속하게 액세스할 수 있는 기능이 가능해졌다. 디스크가 존재하기 이전에는 대부분의 처리가 일괄처리로[?11] 수행되었으며 이런 경우에는 데이터가 테이프에 있는 파일이나 천공 카드에 저장된 순서대로 처리되었다. 디스크를 사용하게 되면서 데이터를 무작위로 액세스할 수 있게 되었다.

1960년대에는 많은 데이터베이스 시스템[?12]과 직접 액세스 파일 시스템이[13] 개발되어 여러 사용자가 동시에 액세스하고 업데이트할 수 있는 디스크에 저장된 데이터를 관리하고 새롭게 사용 가능해진 디스크 스토리를 이용할 수 있게 되었다. 가장 일반적으로 사용된 데이터베이스 구조 중 두 가지는 네트워크 모델(CODASYL)[14]과 계층 구조 모델(IMS)이다[?15]. 데이터베이스에 데이터를 저장하고 애플리케이션을 구현하기 이전에 담당 직원이(데이터 분석가 또는 데이터베이스 관리자)이 데이터 설계를 수행하여 그 시대에는 여전히 종이에 기록되어 있었던 비즈니스 데이터를 계층 구조나 네트워크로 재구성했다. 분석가는 두 가지 데이터 설계 모델, 즉 비즈니스 기록을 프로그래머가 액세스하고 조작할 수 있는 계층 구조에 맵핑하는 논리적 설계와 계층 구조와 네트워크를 디스크에 맵핑하는 물리적 모델을 생성했다. 프로그램은 논리적 모델을 학습했으며 그 시대에 널리 사용된 프로그래밍 언어를 위해 데이터베이스 시스템과 함께 제공된 탐색 가능한 프로그래밍 인터페이스를 통해 데이터베이스에 액세스할 수 있었다(예: 상위 요소 안에서 다음 하위 요소 가져오기).

1970년대에는 대단히 성공한 관계형 모델이[30] 도입되었으며 이 모델은 21세기에도 계속해서 비즈니스 시스템에서 사용되었다. 이 모델에서는 비즈니스 데이터를 테이블에 저장한다. 관계형 모델에서는 탐색 가능한 액세스가 필요 없지만, 여전히 데이터를 분석하여 프로그래머가 선언적 언어인 SQL로 비즈니스 데이터를 액세스하는 테이블로 재구성해야 한다. 1970년대와 1980년대에는 비즈니스 데이터를 여전히 종이에 기록했기 때문에 주로 스캐너를 사용하거나 오퍼레이터가 양식을 다시 입력하여 비즈니스 데이터를 변환해야 했다. 일반적으로 비즈니스 데이터를 재구성하는 과정은 데이터 정규화 원칙을[?16][?17] 따르며 데이터 중복과 이상 항목을 최소화하기 위해 21세기에도 계속해서 데이터 정규화를 학습하고 사용한다.

관계형 데이터베이스 개념이 정리되고 있던 시대에 널리 사용된 디스크 스토리지 디바이스는 200MB를 유지하는 3330 모델 11이었으며 이 모델의 구입 가격은 ,000 - ,000(1970년대 달러) 정도였다[?19]. 1980년대 관계형 데이터베이스가 널리 사용되기 시작했을 때 매우 인기 있던 디스크는 3380 모델이었다. 이 모델은 벽장 정도의 크기를 하고 있었고 1.2GB의 스토리지를 포함하고 있었으며 가격은 0,000였다[?20]. 따라서 디스크 스토리지 1MB의 가격이 0(1970년대 달러)를 넘었으며 이 가격은 2010년의 수천 달러와 맞먹는 금액이다[21].

일반적으로 관계형 데이터베이스 시스템은 시그너처와 연관된 보안 정보를 유지보수하지 않고 정보 조각을 정확히 한 번, 즉 최신 버전만 포함하기 때문에 감사를 수행하기가 어렵다. 예를 들어, 분쟁이 발생하는 경우에 보험 정책과 관련 소송을 감사할 수 있게 하려면 관계형 데이터베이스 시스템에서 실제 비즈니스의 기록의 사본을 저장해야 한다는 점이 곧 분명해졌다. 또한, 비즈니스 데이터를 특정 기간 동안 저장할 것을 요구하는 규정을 준수하려면 문서 시스템이 필요했다. 1980년 후반에는 종이 기록물의 이미지를 저장하기 위해 엔터프라이즈 문서 관리 시스템이라고[?23] 하는 새로운 소프트웨어 카테고리가 개발되었다. 이러한 시스템은 동일한 데이터를 관계형 테이블에 저장하는 데이터베이스와는 다르다. 21세기에는 엔터프라이즈 문서 관리를 엔터프라이즈 컨텐츠 관리로 부른다[24].

20세기에는 컴퓨터 안에서의 기록 관리의 기본 원칙이 컴퓨터가 작동하는 방식에 적합한 스토리지 모델을 도입하고 주어진 데이터 항목을 정확히 한 번만 저장하여 스토리지를 최소화하는 것이었다. 실제 종이 기록물의 정확한 사본이 필요한 경우에는 이러한 작업을 정확히 수행하기 위해 별도의 시스템을 구축했으며 이로 인해 동일한 데이터를 여러 번 저장하게 되었다. 기록의 저장 및 처리를 통제하는 규정이 계속 증가했다.

데이터 정규화 프로세스

이 섹션에서는 20세기의 두 번째 파트에서 데이터베이스가 도입된 환경과 이러한 시스템의 기본 목적을 설명한다.

이 섹션에서는 1970년 내내 도입된 정상 양식과 더불어 1970년에 처음 도입된 데이터 정규화 프로세스의 목적과 효과를 설명한다.

데이터 정규화는 스토리지가 비싸기 때문에 데이터베이스에 있는 실제 비즈니스 기록을 나타내는 테이블로 구성된 콜렉션을 계획하여 데이터가 중복되지 않도록 하기 위한 방법론이다. 데이터가 중복되지 않도록 하면 이상 항목을 업데이트하는 작업이 발생하지 않는다. 데이터 정규화는 광범위하게 매우 잘 기록되어 있다[?18]. 데이터 정규화는 실제 비즈니스 기록의 모든 특성과 기본 ID(키)를 나타내는 하나의 대용량 테이블로 시작하며 SQL과 같은 언어로 쿼리를 단순화하기 위해 계층 구조(반복 그룹)를 제거한다. 그 다음에는 결과 테이블에 있는 모든 정보 데이터와 기능적 종속 항목이 제거된다.

정규화를 달성하기 위해 필요한 모든 특성 있는 하나의 테이블을 기본 및 외부 키를 통해 링크되는 더 많은 테이블로 분리한다. 데이터 정규화의 결과로 하나의 비즈니스 기록이 수십 또는 수백 개의 테이블로 표현된다. 실제로는 존재하지 않는 다수의 인공 키와 연관 인덱스가 도입되지만, 이런 것들은 실제 비즈니스의 기록을 재구성하기 위해 필요하다. 다양한 버전의 비즈니스 기록(예: 주문)을 저장한 후, 이 주문을 개정하는 경우에는 테이블 집합체를 쿼리하고 유지보수하는 것과 관련된 모든 테이블을 버전화해야 한다. 스토리지를 보존하기 위한 또 다른 접근 방식은 전체 버전을 테이블 전체에 계단식으로 배치하여 프로그래머를 더욱 복잡하게 하는 대신에 델타만 저장하는 것이다.

1980년에는 스토리지 2MB의 비용이 미국에 있는 컴퓨터 프로그래머의 1주일 임금과 거의 비슷했다[?19][?22]. 2010년에는 스토리지 1GB의 비용이 몇 분 간의 컴퓨터 프로그래머 임금에도 미치지 못할 정도로 미미할 뿐이었으며 스토리지 가격은 계속해서 하락했다. 게다가 메모리가 풍부해졌으며 SSD(Solid State Disk)와 같은 새로운 종류의 스토리지가 등장하면서 I/O 조작 비용(지연)이 계속해서 감소하고 있다. 관계형 데이터베이스에서는 예외적으로 비정규화된 아티팩트를 저장하기 위해 일반적으로 스토리지 매체를 사용하며 이러한 예로는, 파일 서버, 웹 서버 및 컨텐츠 저장소, 애플리케이션 서버 등이 있다.

관계형 스토리지를 컴퓨터 시스템이 도입되기 전에 기록 관리를 위해 사용했고 언제나 "그대로" 저장되는 종이 기록물과 진흙판 및 엄대와 비교해 보자. 이러한 것을 다른 형식으로 쪼개거나 변환하여 저장하지 않는 이유는 여러 가지가 있다. 첫째, 일반적으로 저장 공간이 충분했으며 이 공간을 보존할 필요도 없었다. 둘째, 이러한 아티팩트를 변환하고 재구성하려면 비용이 많이 든다. 셋째, 이러한 기록을 원래의 형식으로 저장하면 스토리지에서 검색하여 사용하고 이해하기가 수월하다. 나중에 살펴보겠지만, 실제 디지털 비즈니스 기록을 비정규화된 형식으로 저장하는 이유는 오늘날에도 동일하다.

19세기와 20세기에는 종이 기록물의 사용이 급격히 증가했기 때문에 일부 라이브러리와 아카이브의 경우에는 저장 공간이 문제가 되었다. 그 결과 필요한 저장 공간을 원래 자료의 0.25% - 3% 범위로 줄일 수 있는 마이크로 필름과 마이크로 피시가 발명되었다[25]. 그러나 이는 정보를 개념적으로 다른 방식으로 표현하지 않고 단지 압축만 하는 형식에 불과하다. 마찬가지로 오늘날에도 비정규화된 비즈니스 기록이 사용하는 저장 공간을 줄이기 위해 디지털 압축을 적용할 수 있다.

높은 스토리지 비용으로 인해 촉발된 데이터 정규화는 기록을 여러 개의 부분(때로는 수백 개의 부분)으로 분해한 다음 필요에 따라 다시 재구성하는 과정을 통해 컴퓨터로 비즈니스 기록을 표현한다. 단일 기록의 여러 파트를 서로 링크하려면 인공 키와 연관 인덱스가 필요하다. 이점은 비즈니스 기록을 그대로 저장하는 이전의 기록 보관 시스템(진흙판, 엄대, 종이 등)과 차별된다. 비즈니스 기록을 정규화하면 이해하기가 훨씬 더 어려우며 이러한 기록을 분리하고 재구성하는 데 추가로 비용이 들어간다.

경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다.
https://s1004games.com

역정규화 프로세스

이 섹션에서는 역정규화가 일반적인 수단이 되는 상황을 설명한다. 첫 번째 사례는 데이터 웨어하우스의 데이터베이스 스키마이며 두 번째 사례는 Google BigTable[??47] 및 HBase[??49]와 같은 확장 가능한 새로운 데이터 저장소이다.

정규화의 고유한 단점은 두 가지이다. 첫째, 복잡한 비즈니스 기록으로 인해 정규화된 데이터베이스 스키마의 관계형 테이블 수가 증가하기 때문에 데이터 표현을 이해하기가 어려워진다. 결과적으로 쓰기 쿼리에 결합이 많이 필요해져서 쓰기 쿼리가 점점 더 복잡해진다[?46]. 둘째, 결합 수가 많이 증가하게 되어 데이터 검색 성능이 저하된다. 정규화된 테이블을 역정규화 하거나 비정규화된 디자인을 직접 사용하면 이런 문제점을 해결할 수 있다.

데이터 웨어하우스에서의 역정규화

1980년대와 1990년대에는 컴퓨팅 및 스토리지 디바이스의 용량이 증가한 반면에 비용은 하락했기 때문에 회사에서는 판매 보고서와 같은 대용량 히스토리 비즈니스 데이터를 축적하여 분석할 수 있었다. 직관적으로 표현된 데이터를 대상으로 복잡한 쿼리를 실행해야 하는 비즈니스 직원은 회사의 비즈니스 성능을 자세하게 파악하기 위해 이러한 웨어하우스를 사용했다. 그러나 "데이터 웨어하우스에서 정규화된 모델링을 사용하면 데이터를 직관적으로 빠르게 검색한다는 데이터 웨어하우징의 본래의 목적을 위배하게 된다"는 사실이 바로 발견되었다[??26].

결국, 역정규화된 스타 스키마가 데이터 웨어하우징을 위한 가장 인기 있는 데이터베이스 스키마가 되었다. 일반적으로 데이터 웨어하우스는 업데이트 트랜잭션을 수행하는 대신 새 데이터를 주기적으로 추가하므로 역정규화를 수행하면 스키마가 단순화될 뿐만 아니라 이상 항목 업데이트의 위험을 줄이면서 쿼리 성능을 개선할 수 있다.

스타 스키마는 "일일 판매량"과 같은 판매 기록이 포함된 하나 이상의 사실 테이블과 "상점", "제품", "날짜" 및 "고객"과 같은 여러 가지 차원 테이블로 구성된다. 각 차원과 사실 테이블 간에는 일대다 관계가 있다. 각 사실 테이블 행에는 여러 가지 수치, 즉 "수량"이나 "가격"과 같은 숫자 열뿐만 아니라 어떤 제품이 언제 어느 고객에게 어떤 상점에서 팔렸는지를 나타낼 모든 차원 테이블을 가리키는 외부 키가 포함되어 있다. 이는 비즈니스 관점에서 데이터를 직관적으로 바라본 것이며 관련된 비즈니스 차원에 따라 판매량과 같은 사실을 용이하게 분석할 수 있게 한다.

차원 테이블은 고도로 역정규화된다. 예를 들면, "product" 테이블에는 "brand" 및 "category"와 같은 열이 있으며 이 테이블에서는 여러 가지 제품에 동일한 문자열 값을 중복해서 표시할 수 있다. 정규화는 INTEGER 값을 브랜드 및 카테고리 키로 사용하고 각 브랜드 및 카테고리의 이름이 한 번만 존재하는 별도의 테이블을 사용한다. 이렇게 차원 테이블을 정규화하면 이해하기가 어려워지고 추가적인 결합이 필요한 눈송이 스키마가 발생하므로 이렇게 차원 테이블을 정규화하는 것을 피하게 된다.

데이터 웨어하우징에서 스타 스키마가 성공하면서 역정규화에는 OLAP 및 의사결정 지원 데이터베이스에 대한 이점이 있다는 사실을 일반적으로 이해할 수 있게 되었다. 예를 들면, Oracle의 데이터 웨어하우스 및 OLAP 데이터베이스 권장사항에는 "대규모의 역정규화" 및 "광범위한 중복성"이 포함되어 있다[27]. Oracle 11g의 테스트에서 다차원 쿼리는 정규화된 데이터베이스 스키마보다 역정규화된 데이터베이스 스키마에서 10 - 1000배 더 빠르게 실행된다는 사실이 확인되었다[?28]. 기타 연구 결과에서는 역정규화의 성능상 이점을 관계형 대수 및 쿼리 트리를 사용하여 이론적으로 설명했다[29].

의사결정 지원 데이터베이스에서 역정규화가 성공했음에도 불구하고 정규화는 일반적으로 강화된 OLTP 애플리케이션을 업데이트하는 데 적합했다. 그러나 21세기에 들어와서는 모든 데이터베이스 행의 전체 히스토리를 유지해야 하는 애플리케이션이 점점 더 증가하면서 OLTP 애플리케이션에 맞게 데이터베이스 스키마를 정규화해야 할 필요성이 변하고 있다. 따라서 대부분의 애플리케이션은 새 버전의 행만 삽입하지 기존 행을 업데이트하지 않으며[45], 이렇게 하면 역정규화된 스키마에서 이상 항목을 업데이트하는 위험과 정규화 필요성을 줄일 수 있다.

Google BigTable, HBase 및 기타 시스템에서의 역정규화

Google의 BigTable은 이산된 분산 다차원 정렬 맵으로 구현된 무공유 구조의 병렬 데이터베이스 시스템이다[47]. 이 시스템은 대용량 데이터 볼륨(페타 바이트)으로 확장할 수 있고 수백 또는 수천 개 이상의 컴퓨터에 분산할 수 있도록 설계되었다. 각 맵 항목에서 BigTable은 행 키, 열 키 및 시간소인으로 구성된 트리풀을 값에 맵핑한다. 또한, 열 키는 액세스 제어 및 압축의 기본 단위를 구성하는 열 패밀리로 그룹화된다.

BigTable의 데이터베이스 및 애플리케이션의 기본 설계 원칙 중 하나는 역정규화와 데이터 중복이며[?48], 이점은 기존의 관계형 데이터베이스 이론과 완전히 다르다. 그 목적은 데이터베이스를 최적화하여 읽기 액세스를 효과적이고 확장 가능하게 하는 데 있다. 역정규화는 하나의 읽기 연산으로 논리적 비즈니스 기록에 속하는 모든 필드를 검색할 경우에 사용된다.

값이 동일한 여러 개의 사본을 프로그램 방식으로 업데이트해야 할 수 있기 때문에 BigTable에서 역정규화를 수행하면 업데이트가 더욱 복잡해지고 효율성도 떨어지지만, 이러한 대가는 읽기/업데이트 비율이 높은 애플리케이션의 확장성을 강화하기 위해 허용된다. 또한, BigTable에서는 버전화를 용이하게 하기 위해 시간소인 필드를 사용하며, 이는 다수의 고객 주소 사본이나 제품 설명 사본이 특정 시점에서의 상황을 반영한다는 점을 의미한다.

논리적 일대다 관계가 있는 고객 및 주문을 저장하는 데이터베이스를 생각해 보자. 관계형 데이터베이스를 정규화하는 데는 고객 테이블 하나와 주문 테이블 하나 이렇게 최소 2개의 테이블이 필요하지만, 일반적으로 BigTable 설계에서는 고객 정보를 각 주문과 함께 반복한다. 이는 각각의 특정 주문에 대한 고객 정보의 상태를 나타낸다. 예를 들면, 고객은 주문할 때마다 동일한 주소를 사용할 수도 있고 그렇지 않을 수도 있다. 이런 점에서 역정규화된 표현은 실제 구매 주문 양식, 즉 원래의 비즈니스 기록과 유사하다.

BigTable과 비슷한 기타 구현으로는 HBase와 Cassandra가 있으며, 이러한 것도 역정규화된 데이터베이스 설계 방식을 따른다[49]. 마찬가지로 다른 연구 결과에서도 역정규화가 확장 가능한 웹 애플리케이션을 빌드하는 데 적합한 기술이라는 점을 확인할 수 있다[50].

데이터 웨어하우스는 비즈니스 사용자가 액세스하므로 저장된 데이터는 비즈니스 기록의 원래 구조와 직관적으로 비슷해야 하며 이렇게 하려면 역정규화를 사용해야 한다. 또한, 역정규화는 비즈니스 기록을 평가하는 데 필요한 관계형 결합의 수를 줄여서 성능을 개선한다. 마찬가지로 BigTable 및 HBase와 같은 새로운 데이터 저장소에서는 단순하고 확장 가능한 데이터 액세스를 제공하기 위해 역정규화를 사용한다.

웹의 영향

1990년대 중반에 시작된 비즈니스 기록의 디지털화는 웹의 상업적인 성공과 맞물려 있었다. 이번 섹션에서는 21세기 초에 비즈니스 기록을 표현하는 방법에 중요한 영향을 미친 웹의 주요 기술을 살펴본다.

1989년에는 많은 과학, 학술, 정부 및 상업적 기관에서 인터넷 인프라에 액세스해야 했기 때문에 인터넷을 기반으로 하는 프로젝트가 많이 개발되고 있었다. 이러한 프로젝트 중에는 월드 와이드 웹을[??34] 창조하는 데 기초가 된 HTML(Hypertext Markup Language) [??31], HTTP(Hypertext Transfer Protocol) [??32], URL(Universal Resource Locators)의[??33] 발명도 포함된다. HTTP에는 범용 주소 지정 스킴인 URL을 통해 HTML 문서에 주소를 지정하여 인터넷에 있는 HTML 문서를 검색하고 수정하기 위한 프로토콜이 정의되어 있다. 문서를 액세스하고 탐색하기 위해 범용 뷰어(브라우저[??35])가 많이 빌드되었으며 21세기에는 여러 가지 디바이스에서 이러한 뷰어를 사용했다.

과학 기관은 과학 문서를 공유하기 위해 불완전한 웹을 사용한 최초의 사용자였다. 1995년 경에는 상업적 커뮤니티에서 웹을 사용했다. 많은 이용자들이 자신의 직장과 집에서 인터넷에 액세스하기 시작하면서 기존의 상업용 시스템에서 웹을 사용할 수 있게 하고 관계형 데이터베이스에 있는 데이터에 액세스할 수 있는 기능을 제공하는 웹의 중요성을 부각시키려는 경쟁이 생겼으며 그 결과 이용자가 패키지를 추적하거나 서비스와 상품을 주문할 수 있었다. 과거에는 이러한 활동을 직접 전화나 편지를 통해 수행했다. 웹으로 관계형 데이터베이스에 액세스하고 컨텐츠를 유비쿼터스 HTML로 변환하기 위한 인프라가 개발되었으며 사용자 인터페이스에 HTML을 사용한 애플리케이션이 개발되었다[36].

HTML은 대단한 성공을 거두게 되었다. 이점은 1997년까지는 버전이 4.0이었던 SGML(Standard Generalized Markup Language)[??38] 문서 정의에 기술되어 있다. SGML은 1960년대의 IBM GML(Generalized Markup Language)에서 유래된 것으로 마크업 정의를 위한 ISO 표준이다. XML(eXtensible Markup Language)은 [??37] SGML이 단순화된 것으로, HTML을 필요로 하는 완전한 SGML 구문 분석기보다 구문 분석기 구현이 용이하도록 1998년에 도입되었다. 모든 시작 태그에는 종료 태그가 있어야 한다는 규정은 SGML에는 없는 것으로 XML에서 단순화된 사례라고 할 수 있다.

XML이 도입되면서 HTML 이외에도 임의의 데이터 구조를 표현할 수 있는 어휘가 많이 생겨났다. 1990년대 말에는 실제 비즈니스 기록을 디지털 형식으로 작성했기 때문에, 종이 양식이나 석판이 비정규화된 비즈니스 기록인 것과 마찬가지로 웹으로 인해 입출력 매체로 부각된 XML은 비정규화된 형식의 비즈니스 기록을 표현하기 위한 당연한 선택이었다. SGML 프로세서를 이용하여 무료 오픈 소스 XML 소프트웨어를 개발하거나 잘 구성된 XML을 구문 분석할 수 있는 새로운 프로세서가 개발되면서 사용자 정의 구문 분석기에 대한 필요성이 사라졌다.

XML을 지원하기 위해 더 많은 스펙이 추가되었으며, 예를 들면, XML 스키마는 기관과 협회에서 특정 비즈니스 기록의 허용 가능한 컨텐츠를 구성하는 것을 정확하게 지정할 수 있게 한다. 구문 분석기의 유효성을 분석하는 기능이 광범위하게 사용 가능해졌다. 네임스페이스 덕택에 해당 데이터 정의를 다른 그룹에서 소유하고 있는 데이터를 비즈니스 기록에 포함할 수 있게 되었다. 네임스페이스를 이용하면 기관에서 비즈니스 기록 구조를 재사용하거나 분할 또는 확장할 수 있다. 피지와 종이에서 서명과 봉인을 사용한 것과 마찬가지로 방법으로 XML에 디지털 서명을 적용하여 XML이 위조되지 않았다는 것을 보장할 수 있다. WSDL, SOAP, RSS 및 Atom을 포함하여 XML 기록을 전달하는 방법이 기술된 스펙이 도입되었다. 이러한 스펙은 피드 기술 및 SOA(Service-Oriented Architecture)와 같은, 비즈니스 기록의 교환과 관련된 범용 프레임워크를 빌드할 수 있게 한다.

해당 산업의 XML 비즈니스 기록 표준을 정의하는 협회의 수가 증가했다. 기업에서는 자체 XML 비즈니스 기록을 정의하는 대신에 표준화된 XML 구조를 사용하기 시작했다. 이러한 사례로는 FpML(Financial Products Markup Language ) [??52], FIXML(Financial Information eXchange Protocol)[??54], EML(Election Markup Language)[??55], HL7(Health Level 7)[??56], HR-XML(Human Resources XML)[??57], OTA(Open Travel Alliance)[??58] 및 OAGIS(Open Applications Group Integration Specification)[??53]가 있다. IS20022 범용 금융 산업 메시지 스킴과[?59] 같은 형식이 은행에서 사용되었고 UBL(Universal Business Language)이[??60] 세계 곳곳에서 의무화되고 규정을 적용 받게 되었다. 컴퓨터가 없던 시기에는 진흙판과 종이를 사용했기 때문에 처음에는 다양한 산업에서 비즈니스 기록을 직접 저장하고 조작할 수 있게 되었다. 그러나 XML 비즈니스 기록을 정규화하여 저장하는 사례가 계속 되었다.

21세기 초에는 많은 비즈니스 기록이 작성되어 XML로 표현되었다. XML 비즈니스 기록은 기관 간에 그리고 기관 내에서 파일 전송, HTTP, 웹 2.0 및 웹 서비스를 통해 교환되었다. 이러한 비즈니스 기록은 둘 이상의 당사자 간의 계약이나 비즈니스 오브젝트를 나타낸다. 일반적으로는 XML을 처리하는 것이 비효율적이라고 생각되었다. 그래서 계속해서 많은 아키텍트가 비즈니스 기록을 정규화된 관계형 테이블로 변환하는 시스템을 설계한 후, 1995년에 그랬던 것처럼 다시 HTML과 관계형 데이터를 상호 변환하고 1980년에 했던 것처럼 스캐너와 오퍼레이터를 활용하여 종이 기록과 관계형 데이터를 상호 변환한다.

요약

20세기 중반에 상업용 컴퓨팅이 도래할 때까지는 원래 비즈니스 기록을 작성한 형식과 동일한 형식으로 비즈니스 기록을 저장하고 처리했다. 석판, 엄대 및 종이 양식을 예로 들 수 있다. 컴퓨팅 시스템이 도입되면서 비즈니스 기록을 체계화하기 위해 데이터 정규화가 고안되었으며 그래서 각 데이터 항목을 정확히 한 번만 저장하여 스토리지를 보존하고 이상 항목의 업데이트를 피하게 되었다. 정규화는 그 당시의 설득력 있는 이유 때문에 1970년대에 개발되었다. 디스크 공간이 부족했고 비쌌으며, 비즈니스 기록은 지금처럼 복잡하지 않았기 때문에 각 정보의 최신 버전만 저장했다. 그래서 컴퓨터로 비즈니스 기록을 정규화된 표현으로 변환하려는 노력이 일반적으로 받아들여졌다.

1990년대 초에 데이터 웨어하우스와 비즈니스 인텔리전스가 출현하면서 정규화의 단점이 주목을 받게 되었다. 정규화된 데이터 스키마는 비즈니스 기록을 자연스럽게 표현한 것이 아니었기 때문에 비즈니스 사용자가 이해하기 어려웠고 분석적 비즈니스 쿼리를 표현하고 처리하기가 비효율적이었다. 결국 이러한 단점을 어느 정도 보완하기 위해 역정규화를 도입하게 되었다.

그리고 21세기에 들어와서도 IT 업계는 계속 변하고 있다. 디지털 스토리지의 MB당 비용이 엄청나게 하락했다. 저장 밀도와 압축 기능이 발전하면서 더 이상 정규화를 통해 공간을 절약할 필요가 없게 되었다. 마찬가지로 오늘날에는 감사 및 준수 규정에서 많은 애플리케이션이 데이터 오브젝트의 히스토리를 유지하도록 규정하고 있다. 결국, 기존 데이터를 업데이트하기 보다는 일반적으로 데이터 오브젝트의 새 버전과 변경되지 않는 버전을 삽입하게 되었으며 이로 인해 이상 항목을 업데이트하는 위험이 줄어들게 되었다. 따라서 데이터 정규화에 대한 필요성이 더 이상 1970년대에 그랬던 것처럼 보편적으로 적용되지는 않는다.

또한, 웹, 웹 서비스, 웹 2.0 기술이 성공하면서 비즈니스 기록이 디지털 형식(대부분은 XML로 작성됨)으로 작성되게 되었다. 클라이언트 측 소프트웨어에 XML과 파생 기술이 도입되었지만, 정규화가 필요한 데이터 변환으로 인해 데이터베이스를 포함하고 있는 서버측 소프트웨어를 설계하고 빌드 및 전개하려면 계속해서 사용자 정의가 많이 필요하다. 30년 동안 데이?쳤고 지금도 계속해서 시스템 설계의 핵심 부분으로 정규화를 가르치기 때문이다. 그러나 현재는 비즈니스 기록이 디지털 형식으로 되어 있을 뿐만 아니라 더 복잡하고 진화하고 있기 때문에 정규화를 사용하는 것을 조심스럽게 재검토해야 한다.

이 시리즈의 두 번째 파트에서는 XML과 기타 데이터 표현을 살펴보고 이러한 기술이 정규화의 일반적인 문제점을 언제 어떻게 완화할 수 있는지에 대해 설명할 것이다.

제공 : DB포탈사이트 DBguide.net