Database as Enterprise Models 데이터베이스의 정의: Self describing collection of integrated records. 비즈니스를 스스로 나타낼 수 있는 통합된 데이터레코드의 집합체 그러나 좀 더 구체적으로 표현하자면 과연 데이터베이스란 무엇인가?

활발히 진행 중인 비즈니스현장이 있다고 하자. 물건이 오가고, 돈이 돌아가고, 사람들이 분주히 움직이는 중에 누군가가 다음과 같이 물어볼 수 있다. 현재 우리의 사업은 어떤 상태인가요? 이 질문자의 궁금증을 풀어주기 위해서 회사의 모든 부서를 데리고 돌아다니면서 직접 비즈니스의 현장을 직접 보여줄 수 도 있을 것이다. 여기 모든 것이 있으니 직접 보세요. 이런 경우 대부분 다음과 같은 대답이 돌아 올 것이다. 현장을 직접 보아서는 잘 알 수가 없는데 혹시 정리된 표는 없나요? 회사의 상태를 표로 나타내기 위해서는 회사의 모든 일들과 발생하는 데이터를 모아서 기록하여야 할 것이다.

모든 상품의 이름을 기록하고, 상품의 개수를 기록하고, 들어오고 나가는 모든 돈을 계산하여 기록하고 등 등… 모든 것을 다 기록할 수는 없을 것이다. 그러나 고생을 해서 모든 것을 다 찾아서 기록하였다고 한다면 그 결과물은 결국 비즈니스를 문서로 나타내는 한 개의 복사본이 될 것이다. 이 문서를 처음 질문자에게 제공한다면 질문자는 만족할 것인가? 아마 다음과 같은 질문이 되 돌아 올 것이다. 아니 내 말은 올해 영업실적이 작년에 비해서 어떤지 알고 싶어서요, 그리고 우리 회사 직원의 규모는 어느 정도인가 알고 싶습니다. 이 정도의 질문에 답하기 위해서는 ‘연도별 영업실적’, ‘부서별 인원현황’ 정도만 조사하면 되었을 것이다. 제공된 자료에는 너무 많은 불필요한 정보가 담겨있게 되고 결국 많은 시간과 노력을 낭비한 결과가 될 것이다.

데이터베이스 설계자의 딜레마 필요한 질문에만 답하기 위해서는 데이터의 합계를 구하고(통합), 불필요한 내용은 생략(일반화) 해야 할 것이다. 연도별 영업실적을 보여주기 위해서는 모든 영업의 1년간의 통계 값만 보관하면 될 것이다. 또한, 만약 영업의 형태가 ‘도매’, ‘소매’, ‘국제’로 세분화 되어 있고 서로 다른 특징이 있더라고 이런 차이점을 무시하고 하나의 ‘영업’으로 묶어서 처리해야 할 것이다. 따라서 통합과 일반화를 거친 데이터에는 많은 세부정보가 결여되어 있기 때문에 혹시 있을 지도 모르는 세분화된 질문에는 답을 할 수 없게 될 것이다. 즉, 연도별 영업실적 자료로는 월별 영업실적을 알 수 없다. 또한 하나로 일반화된 영업실적으로부터 국제영업부분에 대한 정보를 얻을 수 없을 것이다.

데이터의 통합(Aggregation)과, 일반화(Generalization) 모든 가능한 미래의 질문을 조사하여 해당 질문에 최대한 답을 할 수 있는 (절대로 발생하지 않을 질문에 대하여는 답을 할 수 없는) 정도까지 통합과 일반화를 진행하여야 한다. 누가 언제 어떤 질문을 할 지 어떻게 알 수 있는가? 데이터의 통합과 일반화는 어느 정도까지가 적당할 것인가? 요구사항 분석

Sally Enterprise 샐리는 레모네이드 가판대 장사를 하기로 결정하였다. 통합과 일반화를 설명하기 위하여 간단하고도 가능한 비즈니스형태를 예로 들어보자. 샐리는 레모네이드 가판대 장사를 하기로 결정하였다. 레모네이드를 레몬, 설탕, 물을 사용하여 유리주전자에 담아서 가판대에 진열하여 팔려고 한다. 레모네이드는 고정된 가격을 정하여 유리컵에 한 잔씩 제공하려고 한다. 레모네이드가 부족해지면 다시 제조하여 주전자를 채운다 레모네이드를 만드는 양은 그날의 날씨(온도, 기후), 하루 중 시간대(오전, 오후 등), 그리고 예상되는 고객의 수에 따라서 결정한다. 재료가 부족해지면 친구인 제프를 가게로 보내서 필요한 재료를 구입한다. (그래야 자리를 비우지 않고 계속 장사를 할 수 있다)

Sally Enterprise 그러나 제프는 조금 덜렁대는 성격이라서 가끔 필요한 재료의 구입에 문제를 발생시킬 수도 있다. 따라서 제프가 정확히 일을 처리하도록 독려하기 위하여 재료의 구입이 정확히 이루어지면 그에 대한 보상을 하기로 한다. 제프에 대한 보상은 제프가 가게로 재료를 사러 간 동안에 판매되는 레모네이드에 대하여 한 잔 당 100원씩 지급하기로 한다. (이것은 샐리가 자리를 비우지 않고 계속 장사를 할 수 있음으로 해서 발생하는 이익에 대한 배분이다) 샐리는 가끔 사업이 어떻게 돌아가고 있는지 알고 싶어질 것이다.

Sally Enterprise의 모델링 위와 같은 작고 간단한 비즈니스에서 조차도 모든 상황을 다 나타낼 수 는 없다. 레모네이드 비즈니스의 중요한 몇 가지 측면(aspects)만을 선정하는 작업이 필요하다. 이 선택작업이 Sally Enterprise의 모델을 결정하게 된다. 많은 것을 측정하게 되면 모델은 세분화되고 복잡해질 것이다. 몇몇 가지 측면의 행위만 측정할 경우 모델은 개략적인 모델이 될 것이다. 예를 들어서 들어오는 수입금, 나가는 재료비, 레모네이드가 제조되는 횟수 만을 측정 기록하게 된다면 이 모델로부터는 현금 통 안의 돈의 현재 금액과 레모네이드를 만들기 위하여 부엌을 몇 번 들락거렸는지 등 만을 알 수 있을 것이다(너무 일반화 되었다) 이런 모델을 자동차 모델과 비교하면 자동차를 표현하기 위하여 길쭉한 육면체의 나무토막 하나를 보여주는 것과 같다고 할 수 있다. 자동차 모델

Sally Enterprise의 모델링(세분화) 샐리의 비즈니스 모델을 좀 더 세분화 하기 위하여서는: 재료의 종류별 양을 측정하고, 제프가 구입한 재료의 정확도를 확인하기 위하여 재료별 주문한 양과 받은 양, 그리고 재료 구입비를 측정해야 한다. 또한 제프에세 보상금을 지급하기 위해서는 제프가 가게로 심부름간 동안에 판매되는 레모네이드의 수를 따로 측정해야 한다. 이 모델은 앞의 모델에 비하여 덜 통합되고, 적게 일반화 되었다. 이 모델로부터 좀 더 많은 질문에 대한 답을 할 수 있을 것이다. 자동차 모델과 비교하면 나무토막을 조각하여 앞과 뒤를 구분할 수 있게 된 상태이다. 세분화된 자동차 모델

Sally Enterprise의 모델링(좀 더 세분화) 앞의 모델에 추가하여 판매를 예측할 수 있는 데이터를 추가해 보자. 판매량을 예측하기 위하여서는 고객의 구입기록과 구매습관을 관찰 기록할 수 있을 것이다. 이 데이터는 날씨, 하루 중 의 시간대에 따라 차이가 있을 것이다. 또한 레모네이드 제조 관리를 원한다면 샐리의 레모네이드 제조법(재료의 사용 량 등)을 기록하여야 한다. 이 모델로부터는 날씨와 시간대에 따라서 필요한 재료의 양을 결정할 수 있는 등의 보다 많은 질문의 답을 찾아낼 수 있을 것이다. 자동차 모델과 비교하면 앞의 모델에 바퀴를 붙인 것과 같다. 좀 더 세분화된 자동차 모델

Sally Enterprise의 모델링(좀 더 세분화) 사업이 어느 정도의 이익을 내고 있는지에 대한 답을 하기 위하여 모델을 계속해서 세분화해 보자. 투자된 금액을 추적하기 위하여 고정자산에 대한 데이터를 기록하여야 한다. 샐리는 가판대 테이블, 유리주전자, 컵, 의자 등이 시간이 지나감에 따라서 가치가 하락하는 것(감가상각)을 기록해야 한다. 또한 컵을 닦기 위한 세정제와 부러쉬 등의 소모품에 들도 측정해야 한다. 이 모델로부터는 세무업무에 관련된 질문에 대한 답도 가능해 진다. 자동차 모델에 비유한다면 문짝과, 후드, 트렁크들까지도 갖추게 된 것이다.

Sally Enterprise의 모델링(좀 더 세분화) 앞의 세분화 과정은 끝없이 진행될 수 있다. 사업의 규모와 비용 등을 예상하기 위하여 일별, 월별, 요일별 자료가 필요하게 되고 또 경제적 요인 즉, 소비자의 구매력, 화폐가치의 변동 등의 측정도 필요하게 될 것이다. 고정자산의 감가상각을 좀 더 정확하게 측정하기 위하여서는 자산의 사업적, 비사업적 사용도 구별하여 측정해야 할 것이다. 또한 어떤 고객은 컵을 유난히 더럽게 사용하여 더 많은 세척 비용이 지출될 수 있을 것이다. 이 문제를 해결하기 위하여 추가 세척비용을 계산하기 위한 데이터가 측정되어야 하고 이 비용을 더럽게 사용하는 고객에게 청구하기 위한 별도의 가격 정책을 운영하여야 한다. 이 세분화 과정은 어느 정도에서 끝내야 할 것인가? 어느 정도의 디테일이면 충분히 모든 질문에 답을 할 수 있을까?

Sally Enterprise의 모델링 앞에서 언급한 데이터 중 어느 정도까지 샐리의 데이터베이스에 포함 되어야 할지에 대한 답은 샐리의 요구사항에 따라서 결정될 것이다. 만약 샐리에게 필요한 정보를 묻는다면 ‘내가 얼마를 벌었는지가 알고 싶어요.’ 라는 전형적인 답변이 돌아 올 것이다. (사용자는 그들의 요구사항을 너무 일반적이고 애매모호하게 표현하는 성향이 있다) 사용자 요구사항을 정확히 파악하는 것은 데이터베이스설계자의 책임이다.

Sally Enterprise의 모델링(운영비 측면) 모델링을 위해서 요구사항 분석 이외에 또 고려해야 할 사항은 사용자의 경제적인 능력이다. 앞에서 기술한 모델을 구현하기 위하여 샐리는 컴퓨터를 구매해야 할 것이다(노트북 정도) 그러나 레모네이드 영업을 위하여 노트북 컴퓨터를 구입한다면 그 투자된 비용을 환수하기 위하여 음료수의 가격을 높여야 할 것이고 비싼 가격의 음료수는 한 잔도 팔리지 않을 수도 있다.

샐리 데이터베이스의 수정 샐리의 레모네이드 가판대 사업이 진행되는 모습은 다음과 같을 것이다. 손님들은 레모네이드를 사서 마시고, 샐리는 계속 새로운 레모네이드를 만든다. 재료가 부족하면 주문을 하고 새로운 재료를 받는다. 새로운 제료법을 만들고 제프에게는 적당한 수수료를 지불한다. 데이터베이스 설계자는 매번 판매행위가 발생할 때마다 그에 대한 처리를 하나의 트랜젝션 단위로 취급하고 그에 따른 데이터베이스의 수정사항을 다음과 같이 정리할 수 있다. SELL LEMONADE (레모네이드가 팔릴때): 유리 주전자의 레모네이드의 양을 한 컵 분량만큼 감소시킨다. 현금통의 돈의 금액을 한 잔에 해당하는 금액만큼 증가 시킨다. 유리주전자의 레모네이드의 양이 적어짐에 따라서 적당한 시점에 샐리에게 새로운 레모네이드를 제조하도록 메시지를 통하여 알려 준다.

FILL PITCHER: (유리주전자에 레모네이드를 추가할 때): 유리주전자의 레모네이드의 양을 증가시킨다. 레모네이드 제조방법에 따라 사용된 만큼의 레몬 양을 재고에서 감소 시킨다. 레모네이드 제조방법에 따라 사용된 만큼의 설탕의 양을 재고에서 감소 시킨다. 생산량에 대한 데이터를 갱신한다. 재고량이 기준 이하로 내려가면 시스템이 샐리에게 재료를 주문할 것을 메시지로 알린다. (이 결과 주문을 위한 다른 트랜젝션이 유발된다) BUY LEMON(SUGAR): (레몬,설탕 구입): 레몬(설탕)의 주문양을 증가시킨다 레몬(설탕) 구입비를 총 금액에서 감소시킨다. 제프에게 수고비를 지급하기 위하여 판매유형을 심부름형으로 변경시킨다.

RECEIVE LEMON(SUGAR): (레몬,설탕 도착): 레몬(설탕)의 주문양을 감소시킨다 레몬(설탕)의 양을 재고에 증가시킨다. 주문한 양과 도착한 양이 정확하면 판매유형을 원래대로 환원하고 제프에게 지급될 금액을 계산하여 증가시킨다. PAY JEFF(제프에세 심부름값 지급): 제프에게 지불할 금액을 감소 시킨다.

데이터베이스 시스템의 실패 앞에서 본 바와 같이 데이터베이스 설계과정은 즉흥적이고 경험을 필요로 한다(정해진 알고리즘적인 방법이 없다). 지속적으로 수정하고 정제해 나가는 과정에서 데이터베이스는 조금씩 완벽에 가까워 진다. 그러나 문제의 발생은 항상 예고 없이 찾아온다. 한참 바쁜 와중에 샐리가 레모네이드가 들어있는 유리주전자를 떨어뜨려서 엎질렀다. 샐리는 급하게 부엌으로 가서 새로 레모네이드를 만들어서 주전자를 채웠다. 시스템은 주전자의 양이 바뀐 것을 모른다. 석 잔의 레모네이드가 더 팔린 후에 시스템은 주전자의 레모네이드를 추가로 제조하라는 메시지를 내보내고 사용되는 양 만큼의 레몬과 설탕의 양을 재고에서 감소 시킨다. 샐리는 메시지를 보지 못했다. 시스템이 레몬의 재고가 부족한 것으로 판단하고 재료를 주문하라는 메시지를 내 보낸다. BUY LEMON 트랜잭션이 시작되어 레몬의 주문 양을 증가시키고 판매 유형을 심부름 유형으로 바꾼다. 제프는 낮잠을 자느라고 가게로 가지 않았다. 한 시간 정도 지난 후 데이터베이스의 내용은 실제 내용과 다른 상태가 된다.