ERP 데이터베이스의 비정규화 및 소프트웨어 개발에 미치는 영향: Tortuga에서 선술집 열기

안녕하세요! 제 이름은 Andrey Semenov이고 Sportmaster의 수석 분석가입니다. 이번 포스팅에서는 ERP 시스템 데이터베이스의 비정규화 문제를 제기하고 싶습니다. 일반적인 조건과 구체적인 예를 살펴보겠습니다. 해적과 선원을 위한 멋진 독점 선술집이 될 것이라고 가정해 보겠습니다. 해적과 선원은 서로 다르게 섬겨야 합니다. 선한 신사들의 아름다움에 대한 생각과 소비 패턴이 크게 다르기 때문입니다.

모두를 행복하게 만드는 방법은 무엇입니까? 그러한 시스템을 설계하고 유지하는 데 열중하는 일을 어떻게 피할 수 있습니까? 평소의 해적과 선원들만이 선술집에 오기 시작하면 어떻게 해야 할까요?

모든 것이 컷 아래에 있습니다. 하지만 순서대로 가자.

1. 한계 및 가정

위의 모든 사항은 관계형 데이터베이스에만 적용됩니다. 인터넷을 포함하여 잘 다루어지는 수정, 삭제, 삽입 이상 형태의 비정규화 결과는 고려되지 않습니다. 이 간행물의 범위를 벗어나는 경우에는 여권 시리즈 및 번호, 날짜 및 시간 등과 같은 고전적인 예를 포함하여 비정규화가 일반적인 경우가 있습니다.

이 게시물에서는 수학 용어를 참조하지 않고 직관적이고 실제로 적용 가능한 정규 형식의 정의를 사용합니다. 실제 비즈니스 프로세스(BP) 검토 및 산업용 소프트웨어 설계에 적용할 수 있는 형태입니다.

데이터 웨어하우스, 보고 도구 및 통합 계약(정보를 표 형식으로 표현)의 설계는 소비 용이성과 이를 달성하기 위한 의식적인 비정규화 사용이 무결성보다 우선할 수 있다는 점에서 ERP 시스템 데이터베이스의 설계와 다르다고 주장됩니다. 보호 데이터. 나는 이 의견에 동의하며 아래 설명된 내용은 ERP 시스템의 마스터 데이터 및 트랜잭션 데이터 모델에만 적용됩니다.

대부분의 독자가 일상생활에서 이해할 수 있는 예를 사용하여 정규형에 대한 설명을 제공합니다. 그러나 시각적 예시로서 단락 4-5에서는 의도적으로 "허구적인" 작업이 의도적으로 사용되었습니다. 이를 수행하지 않고 교과서의 예(예: 포인트 2의 동일한 주문 저장 모델)를 취하면 독자의 초점이 제안된 프로세스 분해에서 모델로 이동하는 상황에 처할 수 있습니다. IS에 데이터를 저장하기 위한 프로세스와 모델을 구축하는 방법에 대한 개인적인 경험과 인식. 즉, 두 명의 자격을 갖춘 IT 분석가를 고용하여 한 명은 승객을 운송하는 물류 담당자에게 서비스를 제공하고 다른 한 명은 마이크로칩 생산을 위한 기계를 운송하는 물류 담당자에게 서비스를 제공하도록 합니다. 자동화된 BP에 대해 미리 논의하지 않고 철도 여행에 대한 정보를 저장하기 위한 데이터 모델을 생성하도록 요청하세요.

각 분석가가 자신에게 익숙한 프로세스와 작업에 의존하기 때문에 제안된 모델에서 눈에 띄게 다른 속성 집합뿐만 아니라 다양한 엔터티 집합도 발견할 가능성이 XNUMX이 아닙니다. 그리고 그러한 상황에서는 평가 기준이 없기 때문에 어떤 모델이 "올바른"지 말할 수 없습니다.

2. 일반 형태

데이터베이스의 첫 번째 정규형 모든 속성의 원자성이 필요합니다.
특히 객체 A에 키가 아닌 속성 a와 b가 있고(예: c=f(a,b)) 객체 A를 설명하는 테이블에 속성 c의 값을 저장하면 데이터베이스에서 첫 번째 정규형이 위반됩니다. . 예를 들어, 주문 사양이 수량을 나타내는 경우 측정 단위는 제품 유형에 따라 다릅니다. 어떤 경우에는 조각일 수도 있고, 다른 리터에서는 조각으로 구성된 세 번째 패키지일 수도 있습니다(Good_count_WR 위의 모델에서). , 그러면 데이터베이스에서 속성의 원자성이 위반됩니다. 이 경우 주문 사양의 테이블 클러스터가 무엇인지 말하기 위해서는 IS의 작업 프로세스에 대한 대상 설명이 필요하며 프로세스가 다를 수 있으므로 "올바른" 버전이 많을 수 있습니다.

데이터베이스의 두 번째 정규형 IS의 작업 프로세스와 관련된 각 엔터티에 대한 첫 번째 양식과 자체 테이블을 준수해야 합니다. 한 테이블에 종속성 c=f1(a) 및 d=f2(b)가 있고 종속성 c=f3(b)가 없으면 테이블에서 두 번째 정규형이 위반됩니다. 위의 예에서는 Order 테이블의 주문과 주소 간에 종속성이 없습니다. 거리나 도시 이름을 변경하면 주문의 필수 속성에는 아무런 영향이 없습니다.

세 번째 정규형 데이터베이스 두 번째 정규형을 준수해야 하며 서로 다른 엔터티의 속성 간에 기능적 종속성이 없어야 합니다. 이 규칙은 다음과 같이 공식화될 수 있습니다: "계산할 수 있는 모든 것은 계산되어야 합니다." 즉, 객체 A와 B가 두 개 존재하는 경우, 객체 A의 속성을 저장한 테이블에 객체 C의 속성이 나타나고, 객체 B의 속성이 b이므로 c=f4(b)가 존재하면 제XNUMX정규형은 다음과 같다. 위반됩니다. 아래 예에서 주문 기록의 수량 속성(Total_count_WR)은 세 번째 정규형을 위반한다고 분명히 주장합니다.

3. 정규화 적용에 대한 나의 접근 방식

1. 대상 자동화 비즈니스 프로세스만이 분석가에게 데이터 저장 모델을 생성할 때 엔터티와 속성을 식별하기 위한 기준을 제공할 수 있습니다. 프로세스 모델을 생성하는 것은 일반 데이터 모델을 생성하기 위한 전제 조건입니다.

2. 다음 조건 중 일부 또는 전부가 충족되는 경우 엄격한 의미에서 제XNUMX정규형을 달성하는 것은 ERP 시스템 생성의 실제 실무에서 실용적이지 않을 수 있습니다.

• 자동화된 프로세스는 거의 변경되지 않으며,
• 연구개발 기한이 촉박하고,
• 데이터 무결성에 대한 요구 사항은 상대적으로 낮습니다(산업용 소프트웨어의 잠재적인 오류로 인해 소프트웨어 고객이 금전적 손실이나 고객 손실로 이어지지 않음).
• 기타

설명된 조건에서 일부 개체의 수명주기와 해당 속성을 식별하고 설명하는 비용은 경제적 효율성의 관점에서 정당화되지 않을 수 있습니다.

3. 이미 생성된 IS에서 데이터 모델의 비정규화로 인한 결과는 코드에 대한 철저한 예비 연구와 테스트를 통해 완화될 수 있습니다.

4. 비정규화는 데이터 소스를 조사하고 비즈니스 프로세스를 설계하는 단계부터 개발 단계, 구현 기간부터 시스템 개발 기간까지 인건비를 이전하는 방법입니다.

5. 다음과 같은 경우에는 데이터베이스의 세 번째 정규형을 사용하는 것이 좋습니다.

• 자동화된 비즈니스 프로세스의 변화 방향은 예측하기 어렵습니다.
• 구현 및/또는 개발 팀 내 업무 분담이 약합니다.
• 통합 회로에 포함된 시스템은 자체 계획에 따라 개발됩니다.
• 데이터 불일치로 인해 회사는 고객 손실이나 비용 손실을 초래할 수 있습니다.

6. 데이터 모델의 설계는 대상 비즈니스 프로세스의 모델과 IS의 프로세스와 관련해서만 분석가가 수행해야 합니다. 개발자가 데이터 모델을 설계하는 경우, 특히 원자 속성을 분리하는 데 필요한 조건인 속성 값 간의 차이를 이해할 정도로 주제 영역에 몰입해야 합니다. 따라서 특이한 기능을 수행합니다.

4 예시 문제

항구에 작은 로봇 선술집이 있다고 가정해 보겠습니다. 귀하의 시장 부문: 항구에 와서 휴식이 필요한 선원과 해적. 선원들에게는 백리향을 곁들인 차를 판매하고, 해적에게는 턱수염을 빗기 위한 럼주와 뼈 빗을 판매합니다. 선술집 자체의 서비스는 로봇 여주인과 로봇 바텐더가 제공합니다. 귀하의 높은 품질과 저렴한 가격 덕분에 귀하는 경쟁사를 몰아냈고 배에서 내리는 모든 사람이 항구에 있는 유일한 선술집인 귀하의 선술집으로 오게 되었습니다.

선술집 정보 시스템 단지는 다음 소프트웨어로 구성됩니다.

• 클라이언트의 특징적인 특징을 바탕으로 카테고리를 인지하는 클라이언트 조기경보 시스템
• 로봇 호스티스 및 로봇 바텐더를 위한 제어 시스템
• 판매 시점까지 창고 및 배송 관리 시스템
• 공급업체 관계 관리 시스템(SURP)

프로세스 :

조기 경보 시스템은 배에서 내리는 사람들을 인식합니다. 어떤 사람이 깨끗하게 면도를 했다면 그녀는 그를 선원으로 식별하고, 어떤 사람이 수염을 기르고 있는 것으로 밝혀지면 그는 해적으로 식별됩니다.

선술집에 들어가면 손님은 자신의 카테고리에 따라 로봇 여주인의 인사말을 듣습니다. 예를 들어 "호호호, 친애하는 해적님, XNUMX번 테이블로 가세요..."

손님은 로봇 바텐더가 카테고리에 따라 이미 상품을 준비한 지정된 테이블로 이동합니다. 로봇 바텐더는 다음 배송 분량을 늘려야 한다는 정보를 창고 시스템에 전송하고, 창고 IS는 보관 잔액을 기준으로 관리 시스템에서 구매 요청을 생성합니다.

조기 경보 시스템은 내부 IT에서 개발했을 수도 있지만, 바 로봇 관리 프로그램은 귀하의 비즈니스를 위해 특별히 외부 계약자가 개발했을 수도 있습니다. 그리고 창고 관리 및 공급업체와의 관계 관리 시스템은 시장에서 제공되는 맞춤형 패키지 솔루션입니다.

5. 비정규화의 예와 그것이 소프트웨어 개발에 미치는 영향

비즈니스 프로세스를 설계할 때 인터뷰한 해당 분야 전문가들은 전 세계의 해적들이 럼주를 마시고 턱수염을 뼈 빗으로 빗으며, 선원들은 백리향과 함께 차를 마시고 항상 깨끗하게 면도를 한다고 만장일치로 말했습니다.

클라이언트 유형의 디렉토리는 회사의 전체 정보 회로에 공통되는 1 - 해적, 2 - 선원이라는 두 가지 값으로 나타납니다.

클라이언트 알림 시스템은 이미지 처리 결과를 인식된 클라이언트의 식별자(ID)와 유형(선원 또는 해적)으로 즉시 저장합니다.

인식된 개체 ID
클라이언트 카테고리

100500
해적

100501
해적

100502
선원

다시 한 번 알아두자면

1. 우리 선원들은 사실 면도를 한 사람들이다.
2. 우리 해적들은 실제로 수염을 기른 ​​사람들이다

이 경우 구조가 세 번째 정규형을 추구하도록 하려면 어떤 문제를 제거해야 합니까?

• 속성 원자성 위반 - 클라이언트 카테고리
• 분석된 사실과 결론을 하나의 테이블에 혼합
• 서로 다른 엔터티의 속성 간의 기능적 관계가 고정되었습니다.

정규화된 형식에서는 다음과 같은 두 개의 테이블을 얻게 됩니다.

• 확립된 특징 세트의 형태로 인식 결과를 얻습니다.

인식된 개체 ID
수염

100500
Да

100501
Да

100502
아니

• 설정된 특성을 해석하기 위해 IS에 내장된 로직을 적용하여 클라이언트 유형을 판단한 결과

인식된 개체 ID
식별번호
클라이언트 카테고리

100500
100001
해적

100501
100002
해적

100502
100003
선원

표준화된 데이터 스토리지 조직은 어떻게 IP 복합체의 개발을 촉진할 수 있습니까? 갑자기 새로운 고객이 생겼다고 가정해 보겠습니다. 수염이 없지만 어깨에 앵무새를 메고 걷는 일본 해적, 환경 운동가 해적이라면 왼쪽 가슴에 있는 그레타의 파란색 옆모습으로 쉽게 알아볼 수 있습니다.

당연히 환경 해적은 뼈 빗을 사용할 수 없으며 재활용 바다 플라스틱으로 만든 유사품을 요구합니다.

새로운 입력에 따라 프로그램 알고리즘을 재작업해야 합니다. 정규화 규칙을 따른다면 일부 시스템의 일부 프로세스 분기에 대한 입력만 보완하고 얼굴 털이 중요한 IS에 대해서만 새 분기를 생성하면 됩니다. 그러나 규칙을 따르지 않았기 때문에 클라이언트 유형 디렉토리의 값이 사용되는 전체 회로에서 전체 코드를 분석하고 어떤 경우에는 알고리즘이 전문가를 고려해야 함을 명확하게 설정해야 합니다. 클라이언트의 활동 및 기타 물리적 기능.

그런 형태로 추구하다 정규화하려면 운영 데이터가 포함된 두 개의 테이블과 두 개의 디렉터리가 필요합니다.

• 확립된 특징 세트의 형태로 인식 결과를 얻습니다.

인식된 개체 ID
왼쪽 가슴의 그레타
어깨 위의 새
수염

100510
1
1
1

100511
0
0
1

100512

1
0

• 클라이언트 유형을 결정한 결과(디렉토리의 설명이 표시되는 사용자 정의 보기로 둡니다)

감지된 비정규화는 시스템이 새로운 조건을 충족하도록 수정할 수 없음을 의미합니까? 당연히 아니지. 모든 정보 시스템이 직원 교체 없이 한 팀에 의해 생성되고 개발 내용이 잘 문서화되고 정보가 손실 없이 팀 내에서 전송된다고 상상한다면, 필요한 변경 사항은 무시할 만큼 적은 노력으로 이루어질 수 있습니다. 그러나 문제의 원래 상태로 돌아가면 공동 논의 프로토콜 인쇄용으로만 키보드 1,5개가 지워지고 조달 절차 처리용으로 키보드 0,5개가 지워집니다.

위의 예에서는 세 가지 정규형이 모두 위반되었으므로 별도로 위반해 보겠습니다.

첫 번째 정규형 위반:

귀하의 선술집에 속한 1.5톤 가젤 한 마리를 사용하여 상품이 공급업체 창고에서 귀하의 창고로 픽업되었다고 가정해 보겠습니다. 귀하의 주문 규모는 공급업체의 매출에 비해 너무 작아서 생산을 기다리지 않고 항상 일대일로 완료됩니다. 차량, 차량 유형 등 비즈니스 프로세스가 포함된 별도의 테이블이 필요합니까? 떠난 공급업체에 대한 주문에서 계획과 사실을 분리해야 합니까?

아래 모델을 사용하여 프로그램을 개발하는 경우 프로그래머가 얼마나 많은 "추가" 연결을 작성해야 하는지 상상해 보십시오.

제안된 구조가 불필요하게 복잡하다고 판단했다고 가정해 보겠습니다. 우리의 경우 주문 기록에서 계획과 사실을 분리하는 것은 중복된 정보이며 생성된 주문 사양은 도착한 상품의 수락 결과를 기반으로 다시 작성됩니다. - 품질이 좋지 않은 제품의 등급 지정 및 도착은 IS 외부에서 처리됩니다.
그러던 어느 날 선술집 홀 전체가 분개하고 깔끔한 해적들로 가득 차 있는 것을 보게 됩니다. 무슨 일이에요?

귀하의 비즈니스가 성장함에 따라 소비도 증가한 것으로 나타났습니다. 옛날에는 가젤의 부피 및/또는 무게가 매우 드물게 과부화되는 경우 공급업체가 음료수보다 가젤의 우선순위를 정한다는 경영진의 결정이 내려졌습니다.

배송되지 않은 상품은 다음 주문에서 끝나고 새 항공편으로 떠났는데, 선술집 창고에 최소 잔액이있어 누락 된 사례를 알 수 없었습니다.

마지막 경쟁자는 항구에서 문을 닫았고, 차량의 최소 잔고 및 주기적인 저적재가 충분하다는 가정에 기초한 우선순위를 우회하여 가젤 과부하가 발생하는 경우가 일반적인 관행이 되었습니다. 생성된 시스템은 내장된 알고리즘에 따라 이상적으로 작동하며 계획된 주문을 이행하지 못하는 시스템적 실패를 추적할 수 있는 기회가 박탈됩니다. 손상된 평판과 불만족한 고객만이 문제를 감지할 수 있습니다.

세심한 독자라면 섹션 2와 섹션 5의 주문 사양(T_ORDER_SPEC)에 있는 주문 수량이 첫 번째 정규 형식의 요구 사항을 충족할 수도 있고 충족하지 않을 수도 있음을 알아차렸을 것입니다. 이는 선택된 상품 종류에 따라 본질적으로 다른 측정 단위가 동일한 필드에 포함될 수 있는지 여부에 따라 달라집니다.

두 번째 정규형 위반:

요구 사항이 증가함에 따라 다양한 크기의 차량을 몇 대 더 구입하게 됩니다. 위의 맥락에서 차량 디렉토리 생성은 중복된 것으로 간주되었으며, 결과적으로 배송 및 창고 요구 사항을 충족하는 모든 데이터 처리 알고리즘은 공급업체에서 창고로의 화물 이동을 독점적인 1,5톤 화물의 비행으로 인식합니다. 가젤 영양. 따라서 새 차량 구입과 함께 여전히 차량 디렉토리를 생성하지만 이를 완료할 때 화물 이동을 참조하는 모든 코드를 분석하여 각 특정 장소에서 참조가 특성에 암시되어 있는지 확인해야 합니다. 사업이 시작된 바로 그 차량의 모습입니다.

세 번째 정규형 위반:

어느 시점에서 충성도 프로그램을 만들기 시작하면 일반 고객의 기록이 나타납니다. 예를 들어, 로열티 프로그램이 시작될 때 고객이 관심을 갖는 모든 것이 고객의 기록에 배치될 수 있다면 보고에 사용하고 분석 시스템으로 전송하기 위해 개별 고객에 대한 판매에 대한 집계 데이터를 저장하는 자료 보기를 만드는 데 시간을 소비하는 이유는 무엇입니까? ? 그리고 실제로 언뜻보기에는 아무런 의미가 없습니다. 그러나 비즈니스가 새로운 판매 채널과 연결될 때마다 분석가 중에는 이러한 집계 속성이 존재한다는 것을 기억하는 사람이 있어야 합니다.

예를 들어 인터넷 판매, 공통 충성도 시스템에 연결된 유통업체를 통한 판매 등 각각의 새로운 프로세스를 설계할 때 누군가는 모든 새로운 프로세스가 코드 수준에서 데이터 무결성을 보장해야 한다는 점을 명심해야 합니다. 수천 개의 테이블이 있는 산업용 데이터베이스의 경우 이는 불가능한 작업처럼 보입니다.

물론 숙련된 개발자는 위에서 언급한 모든 문제를 제거하는 방법을 알고 있지만, 제 생각에는 숙련된 분석가의 임무는 문제를 밝히는 것이 아닙니다.

출판을 준비하는 동안 귀중한 피드백을 주신 선도적인 개발자 Evgeniy Yarukhin에게 감사의 말씀을 전하고 싶습니다.

문학

https://habr.com/en/post/254773/
코놀리 토마스, 베그 캐롤라인. 데이터 베이스. 설계, 구현 및 지원. 이론과 실습

출처 : habr.com