부울 값을 결정할 수없는 경우 수행 할 작업


38

지금까지 Excel 시트에만 관리되는 회 사용 웹 응용 프로그램을 구축하고 있습니다. 우리는 지금 거의 끝났지 만 최근에는 해당 시트의 모든 데이터를 새 시스템으로 가져 오는 작업이 할당되었습니다. 이 시스템은 Java로 빌드되었지만이 가져 오기는 한 번만 수행하므로 대신 스크립트를 Python으로 작성하고 SQL 쿼리로 직접 가져 오기로 결정했습니다. 여기에 문제가 있습니다. 새 데이터 모델에는 기존 데이터에 포함되지 않은 몇 가지 새로운 속성이 포함되어 있습니다. 대부분의 경우, 이것은 문제가되지 않습니다. 정보를 찾을 수없는 곳에 null을 넣습니다. 그러나 나는 부울이며 기본적으로 NULL이 될 수없는 몇 가지 속성을 발견했습니다. 먼저 데이터베이스의 해당 필드에 대해 null을 허용하려고했지만 수석 개발자는 그렇게하지 말라고 지시했습니다. 향후 시스템에 문제가 발생할 수 있습니다. 그리고 지금은 무엇을 해야할지 잘 모르겠습니다. 명백한 해결책은 모든 알 수없는 부울 값을 기본값으로 false로 설정하는 것이지만 실제로는 그것이 거짓인지 여부를 알지 못하기 때문에 잘못된 것 같습니다.

예 : hasRadio 매개 변수가있는 엔티티 Car가 있다고 가정합니다. 이제이 데이터 모델로 데이터를 가져와야하지만 데이터에는 "모델"및 "컬러"열만 있으며 라디오가 있거나없는 것이 아닙니다. 의도적으로 널이 될 수없는 경우 "hasRadio"열에 무엇을 넣습니까?

이 상황에서 가장 좋은 방법은 무엇입니까? 회사에 누락 된 데이터를 수동으로 채우도록 지시해야합니까? 아니면 기본값이 false입니까?


70
나를 위해 NULL을 허용하는 것이 올바른 해결책 일 것입니다. 당신의 선배가 "앞으로 우리 시스템에 문제를 일으킨다"보다 더 구체적 이었습니까? 그렇지 않다면 더 구체적인 이유를 물어보십시오.
larsbe

48
FileNotFound분명히 기본값으로 설정해야합니다 .
당신은

7
부울 필드, "isValidHasRadio"또는 다른 것을 추가 할 수 있습니까?
하이드

9
올바른 해결책은 입력 데이터 가비지를 고려하고 전체 트랜잭션을 중단 한 다음 해당 데이터 가비지로 간주 해서는 안되는 작업 정의를 조정하도록 요구하는 것 입니다. 다른 방법은 없습니다.
Sarge Borsch

17
그건 그렇고, 나는 null 값을 좋아하지 않습니다. 오히려 '알 수 없음', '라디오 있음'및 '라디오가 없음'으로 열거 형을 사용하고 싶습니다. 이렇게하면 앞으로 '통합 TV가있는 라디오'와 같은 라디오 유형을 지정해야하는 경우 요구 사항을 다루고 성장할 여지가 있습니다.
Machado

답변:


129

이는 주로 요구 사항 분석 문제이며 스테이크 데이터가 "부울"이라는 사실과 관련이 없습니다. 데이터베이스 또는 다른 종류의 데이터 스토리지에서 테이블을 초기화해야하고 일부 열에 대한 입력이 불완전한 경우 먼저 시스템 사용자 또는 고객이 올바른 기본값으로 생각하는 것을 찾아야합니다. 해당 열에 대해 모든 단일 속성에 대해 이것을 찾아야하므로 일반적으로 정답 이 없습니다 .

일반적으로 다음 경우 중 하나가 발생합니다.

  • 특정 열에 대해 좋은 기본값이 있습니다. 사용자는 모든 레코드에 대해 값이 초기에 동일한 지 신경 쓰지 않아도 필요할 때 나중에 올바른 값을 쉽게 설정할 수 있습니다

  • 다른 정보에서 이상적인 기본값을 결정하는 방법이 있으므로이 규칙을 코드에 넣을 수 있습니다

  • 사용자 또는 고객은 입력 데이터를 확장하고 결 측값을 데이터베이스로 가져 오기 전에 (수동으로) 제공합니다.

  • 특정 열 및 / 또는 레코드에 대한 올바른 기본값은 없으며 데이터를 가져와야하지만 사용자 는 특정 값이 이미 초기화 된 레코드와없는 레코드 를 알고 싶어합니다 . 따라서 나중에 값을 입력하고 값 이 이미 올바르게 설정된 레코드와 그렇지 않은 레코드를 추적 할 수 있습니다 .

마지막 경우는 수석이 선호하는지 여부에 따라 부울 값의 경우에도 초기화되지 않았거나 알 수없는 상태를 나타 내기 위해 NULL과 같은 것이 필요합니다. 특정 열에 NULL 값을 사용하지 못하게하는 모호한 기술적 이유가있는 경우 추가 부울 열 ( hasRadioIsUnknown) 을 도입 하거나 3을 사용하여 "알 수 없음"상태를 다른 방식으로 시뮬레이션해야합니다. 부울 대신 -valued 열거 형 (예 HasNoRadio=0: HasRadio=1,, Unknown=2) 그러나 철저한 요구 사항 분석을 수행 한 후 그러한 해결 방법이 실제로 필요한지 확인하기 위해 선배에게 다시 문의하십시오.


29
또한 NULL을 편리하게 사용하는 다른 열에도 동일한 대답이 적용됩니다. 이것이 올바른 기본값인지 확인해야합니다. 예를 들어, 다른 열에 "processingIsFinished"라고 표시되어 있고 고객 주문 내역에서 오래된 데이터를 가져 오는 경우 (웹샵 생각) 일부 프로세스가 트리거되지 않도록 값을 "NULL"이 아닌 "true"로 설정해야 할 수 있습니다. 아직 처리되지 않은 항목이있을 때 (해당 열의 해석에 따라)
프랭크 홉킨스

1
이것은 기능적인 문제입니다. 모델 (우수한 모델과 새로운 모델)이 일치하지 않기 때문에 이러한 경우를 고려하여 마이그레이션 프로세스를 검토해야합니다. 진행 방법을 말할 수있는 유일한 것은 이해 관계자 (고객 또는 누구)입니다. 기술적으로는 여러 가지 방법으로 해결할 수 있지만 기능 상으로는 한 가지 방법으로 만 해결할 수 있습니다. 권리.
Laiv

12
나는이 고장을 좋아한다. 이 맥락에서 null에 대한 나의 불쾌감은 주로 명확한 의미가 없기 때문입니다. 알 수 없음 그러나 null은 알 수 없거나 적용 할 수 없음을 의미합니까? 누구나 어떻게 알 겠어요? 그것이 당신에게 의미가 있다고해서 다른 사람들이 그것을 똑같이 볼 것이라는 것을 의미하지는 않습니다.
candied_orange

옵션 4 : 특정 열 값이없는 레코드는 실제로 쓸모가 없으므로 가져 오기에서 제외해야합니다. 옵션 5 : 모든 수신 데이터를 가져 오기 전에 수정해야합니다. 많은 옵션은 요구와 예산에 달려 있습니다. 오래된 데이터를 가져 오는 것은 항상 큰 혼란입니다.
jpmc26

@ jpmc26 : 글쎄, OP가 문자 그대로 쓴 것을 고수하기 때문에 옵션 4를 포함하지 않았습니다 (손실 된 데이터가 수입 데이터에 확실히 포함되어 있지 않은 경우). 옵션 5는 NULL 값의 필요성을 피하는 또 다른 방법이므로 실제로 언급 할 가치가 있습니다. 이에 따라 내 대답을 편집했습니다.
Doc Brown

39

이것은 기술적 인 질문이 아닙니다. 비즈니스 규칙 질문입니다. 따라서 "비즈니스"를 요청해야합니다.

제품 소유자 및 / 또는 이해 관계자에게 접근하여 다음과 같이 말합니다.

신청서에서 요청한 필드 중 하나에 대한 데이터가 불완전합니다. 기본값을 사용 하시겠습니까? "알 수 없음"을 유효한 값으로 추가 하시겠습니까? 또는 가져 오기 전에 팀원이 데이터를 수정하도록 하시겠습니까?

아마도 일부 토론이 이어질 것입니다. 그러나 그것은 기본적으로 입니다. 기술 솔루션은보다 복잡한 비즈니스 규칙에서 자연스럽게 흐릅니다.


9

일반적인 문제는 데이터 통합 이라는 더 큰 하위 영역의 일부인 데이터 정리 라는 프로그래밍의 전체 하위 영역입니다 . 이러한 종류의 문제를 피하는 것은 Excel 시트에서 마이그레이션하는 이유의 상당 부분이며 수석 개발자가 필드를 nullable로 허용하지 않는 이유 일 수 있습니다. 이것이 데이터 마이그레이션에서 가장 큰 복잡성 소스 중 하나라고 말하는 것은 부당하지 않다고 생각합니다.

더 많은 필드를 널 입력 가능하게 만들기 위해 데이터 모델을 변경하는 것은 물론 가능할 때마다 NULL을 사용하도록 선택하는 것은 잘못된 일입니다. Excel의 무결성 검사 기능이 약하거나 전혀 없기 때문에 이러한 문제가 많이 발생할 수 있습니다. 잘못된 것은 새 데이터베이스에서 무결성 검사를 제거하고 가비지를 덤프하는 것입니다. 이것은 단지 문제를 영속시키고 미래의 통합에 무의미한 데이터를 처리해야하는 복잡한 작업을 추가합니다.

차이점 중 일부는 데이터 모델 불일치 때문일 수 있습니다. 이 문제를 다루는 것은 데이터 모델 모두에 (친밀하게) 친숙하고 기존 모델을 새 모델에 매핑하는 방법을 아는 것입니다. 새로운 것이 오래된 것을 캡처 할 수있는 한. 그렇지 않은 경우 팀에 큰 문제가있을 수 있습니다. 열을 복사하는 것보다 더 많은 작업이 필요할 수 있습니다. Darkwing은 이것에 대한 훌륭한 예를 제공합니다 (그리고 왜 맹목적으로 NULL을 삽입하는 것이 잘못된 일인지). 이전 모델이 있었다면, 그 위에 정성 들여 ReceivedDateInProgress비트와 새로운 모델은을 가지고 StartDateProcessingEndTime, 당신은과를 설정하는 방법을 여부를 결정해야합니다 ProcessingEndTime. 사용 방법에 따라 합리적인 (임의의) 선택은 다음과 동일하게 설정하는 것일 수 있습니다.StartDate (또는 문제가 발생할 경우 곧).

그러나 차이점 중 일부는 누락되거나 손상된 데이터가 있어야하기 때문일 수 있습니다. (데이터 입력 오류 또는 데이터 처리 시스템의 과거 마이그레이션 또는 버그 처리가 제대로 이루어지지 않았을 가능성이 큽니다.) 팀원 중 누구도이를 예상하지 못한 경우 프로젝트 전체 시간의 20 %를 " 거의 "완료되었습니다. (이것은 보충 번호 였지만 훨씬 멀었습니다.그것보다 나쁘거나 잘못된 데이터의 양, 중요도, 복잡도, 데이터를 담당하는 담당자의 참여가 얼마나 쉬운 지 및 기타 요인에 따라 다릅니다.) 데이터가 " "하지만 거기에 없습니다. 일반적으로 이전 데이터 소스를 쿼리하여 문제의 범위를 결정하려고 시도합니다. 수십 또는 수백 개의 항목 인 경우 데이터 입력 오류 일 수 있으며 데이터를 담당하는 고객은 수동으로 데이터를 해결해야합니다 (예 : 값이 무엇인지 알려줍니다). 수백만 개의 항목 (또는 데이터의 상당 부분) 인 경우 그런 다음 해당 위치에 "있을 것"인지 올바르게 식별했는지 다시 고려해야합니다. 새 시스템의 모델링 오류를 나타낼 수 있습니다.

예를 들어, 수량 중 일부가 설명 할 수없는 것을 제외하고 수량 및 품목 당 총계 (단가는 아님)가있는 송장을 상상해보십시오. 이러한 송장을 처리하는 사람과 이야기하면 다음 시나리오 중 하나 이상을 생성 할 수 있습니다. 1) "빈 수량은 1의 수량을 의미합니다", 2) "오, 나는 그 품목이 약 $ 1,000 정도되는 것을 알고 있습니다. 분명히 이것은 2 ", 3)"그런 일이 발생하면이 다른 시스템에서 가격을 찾아서 나누고 둥글게됩니다 ", 4)"다른 시스템에서 찾게됩니다 ", 5)"실제 데이터가 아닙니다 ", 6)"이전에 본 적이 없습니다 ".

제안 된대로 상황을 자동으로 해결하는 몇 가지 방법을 나타낼 수 있지만 솔루션이 모든 경우에 적용되도록주의해야합니다. 데이터를 교차 점검 할 수있는 다른 시스템이 관여하는 것이 일반적이며 이는 좋은 일입니다. 그러나 교차 점검을 수행하기 위해 이러한 시스템에 액세스하여 이러한 시스템과 통합하기가 어려울 수있는 경우가 종종 있습니다. 데이터가 누락 된 것만이 아니라 시스템이 서로 충돌하는 경우가 종종 있습니다. 일부 수동 개입이 필요한 경우가 많으며, 규모에 따라 데이터 정리 작업을 위해 특별히 툴링 및 인터페이스를 만들어야 할 수도 있습니다. 종종 수행되는 작업은 데이터를 부분적으로 가져 오지만 누락 된 데이터가있는 행은 별도의 테이블로 전송되어 검토 할 수 있습니다.


14
요약 : 레거시 코드 처리가 불쾌하다고 생각되면 레거시 데이터를 처리하십시오.
피터 테일러

0

데이터 모델을 변경하십시오.

hasradio를 정규화하면 더 이상 null이 없습니다.

부울 값을 결정할 수 없으면 부울을 사용하지 마십시오.

부울 값이 널이되도록하여 부울이되는 것을 중지합니다. 부울은 False, True의 두 가지 상태를 가질 수 있습니다.

False, True, Unknown의 3 가지 상태가 필요합니다.

데이터 모델을 변경할 수있는 옵션이 있습니까?

(그리고 파이썬이나 자바에서 데이터베이스에서 데이터를 검색하는 경우 내가 생각한 또 다른 점은 레코드를 검색하고 hasradio 필드를 확인하는 것입니다. true인지 false인지를 확인하면 null이됩니까?)


2
데이터 모델 및 "hasRadio 밖으로 정상화"를 변경하여, 당신은 새 테이블을 추가하는 등의 평균 뭔가 가정 CarFeatures필드를, Car_ID, Feature_ID, Has_Feature? 좋은 생각 인 것 같습니다.
jpa

2
@ jpa 조금 까다로운 상황입니다. 우리 상황에 기록이 없다는 것은 알려지지 않았기 때문에 당신은 당신이하는 일에 대해 매우 분명해야합니다. 종종 레코드가 없다는 것은 그 기능이 없다는 것을 의미합니다.
Pieter B

1
당신은 잘못보고 있습니다, 피터 아무도 말했듯이 a bool가 두 개 이상의 값을 가지고 있다고 말하지 않습니다. A booltrue또는 false입니다. 그러나, OPS의 경우, 영업 이익은 처리되지 않고 bool직접하지만 오히려 Option<bool>/Maybe<bool>가질 수있는 Some -> true/falseNone.
Andy

@DavidPacker 내 주장은 아마 <bool>이기 때문에 원격으로 비슷한 것을 부르지 않으면 혼란스러워 할 것입니다. 부울을 사용한다고 주장하면 안전한 방법을 찾으십시오.
Pieter B

4
내 의견으로는, nullable 부울은 완전히 괜찮습니다. null 값에 문제가 없었지만 개발자를 만난 적이 있습니다.
Andy

-1

다른 사람들이 지적했듯이, 여기에있는 것은 진정한 부울이 아닌 부울 값이며 문제는 값을 부울로 설정하거나 다르게 처리하는 것입니다.

단일 부울 결과 대신 두 개의 부울 결과를 얻는 것이 가능합니다. 이들은 동의하거나 동의하지 않을 수 있습니다. 그들이 동의하면, 당신은 직접적인 참 / 거짓 결과를 얻게됩니다.

그러나 이들이 동의하지 않는 경우 결과가 불확실하고 상황에 따라 처리 방법을 결정할 기회가 있습니다. 어떤 경우에는 결정되지 않은 결과가 참으로 가장 잘 해석되는 반면, 다른 경우에는 가장 안전한 옵션에 따라 동일한 부정확 한 결과가 거짓으로 해석 될 수 있습니다.

그래도 결과는 불확실한 것으로보고 될 수 있으므로 값의 추가 뉘앙스는 값을 결정하고 재설정 할 수있을 때까지 완전히 손실되지 않습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.