가위바위보 같은 데이터 정리. 피니시가 있는 게임인가요, 없는 게임인가요? 1부. 이론적

1. 초기 데이터

데이터 정리는 데이터 분석 작업이 직면한 과제 중 하나입니다. 이 자료는 지적 가치 형성에서 데이터베이스 분석의 실제 문제를 해결한 결과 발생한 개발 및 솔루션을 반영했습니다. 출처는 여기 "한티만시스크 자치 오크루그 - 우그라(Ugra) 영토 내 모든 유형의 부동산(토지 제외)에 대한 주 지적 평가 결과에 대한 보고서 번호 01/OKS-2019".

"부록 B. KS 결정 결과 5. 지적 가치 결정 방법에 대한 정보 5.1 비교 접근법"의 "비교 모델 total.ods"파일을 고려했습니다.

표 1. "비교 모델 total.ods" 파일에 있는 데이터 세트의 통계 지표
총 필드 수, 개 - 44
총 레코드 수, 개 - 365 490
총 문자 수, 개 — 101 714 693
레코드의 평균 문자 수(개) - 278,297
레코드 내 문자의 표준 편차(개) — 15,510
항목의 최소 문자 수(개) — 198
항목의 최대 문자 수(개) — 363

2. 소개 부분. 기본기준

지정된 데이터베이스를 분석하는 동안 모든 사람에게 분명한 것처럼 지정된 데이터베이스가 사용자에게 법적, 경제적 결과를 초래하기 때문에 정화 정도에 대한 요구 사항을 지정하는 작업이 구성되었습니다. 작업 과정에서 빅데이터 정리 정도에 대한 구체적인 요구 사항은 없는 것으로 나타났습니다. 이 문제에 대한 법적 규범을 분석한 결과, 나는 그것이 모두 가능성에서 형성된다는 결론에 도달했습니다. 즉, 특정 작업이 나타나고 해당 작업에 대한 정보 소스가 컴파일된 다음 데이터 세트가 형성되고 생성된 데이터 세트를 기반으로 문제 해결 도구가 구성됩니다. 결과 솔루션은 대안을 선택할 때 기준점이 됩니다. 나는 이것을 그림 1에 제시했습니다.



표준을 결정할 때 입증된 기술에 의존하는 것이 바람직하기 때문에 저는 다음에 제시된 요구 사항을 선택했습니다. "MHRA GxP 데이터 무결성 정의 및 업계 지침", 왜냐하면 나는 이 문서가 이 문제에 대해 가장 포괄적이라고 생각했기 때문입니다. 특히 이 문서의 섹션에는 "데이터 무결성 요구 사항이 수동(종이) 데이터와 전자 데이터에 동일하게 적용된다는 점에 유의해야 합니다."라고 나와 있습니다. (번역: "...데이터 무결성 요구 사항은 수동(종이) 데이터와 전자 데이터에 동일하게 적용됩니다.") 이 공식은 민사소송법 제71조의 조항에 있는 "서면 증거"의 개념과 매우 구체적으로 연관되어 있습니다. 70 CAS, 조항 75 APC, “서면” 조항. 84 민사소송법.

그림 2는 법학에서 정보 유형에 대한 접근 방식의 형성 다이어그램을 보여줍니다.

쌀. 2. 출처 여기에.

그림 3은 위의 ​​"지침" 작업에 대한 그림 1의 메커니즘을 보여줍니다. 비교를 통해 현대 정보 시스템 표준의 정보 무결성 요구 사항을 충족할 때 사용되는 접근 방식이 정보의 법적 개념과 비교하여 상당히 제한되어 있음을 쉽게 알 수 있습니다.

Pic.3

지정된 문서(지침)에서 기술 부분과의 연결, 데이터 처리 및 저장 기능은 18.2장의 인용문을 통해 잘 확인됩니다. 관계형 데이터베이스: "데이터와 메타데이터 간의 관계를 유지하는 대용량 파일 형식으로 데이터가 보관되므로 이 파일 구조는 본질적으로 더 안전합니다."

실제로 이 접근 방식에서는 기존의 기술적 역량으로 볼 때 비정상적인 것이 없으며 개념의 확장은 가장 많이 연구된 활동인 데이터베이스 설계에서 비롯되기 때문에 그 자체로는 자연스러운 프로세스입니다. 그러나 반면에 기존 시스템의 기술적 능력에 대한 할인을 제공하지 않는 법적 규범이 나타납니다. 예를 들면 다음과 같습니다. GDPR - 일반 데이터 보호 규정.

쌀. 4. 기술적 역량의 유입경로(출처).

이러한 측면에서, 원본 데이터 세트(그림 1)가 우선 저장되어야 하고, 두 번째로 추가 정보를 추출하기 위한 기초가 되어야 한다는 것이 분명해집니다. 예를 들어 교통 규칙을 기록하는 카메라는 어디에나 있고 정보 처리 시스템은 위반자를 제거하지만 예를 들어 고객이 쇼핑 센터로 이동하는 흐름 구조에 대한 마케팅 모니터링과 같은 다른 정보도 다른 소비자에게 제공될 수 있습니다. 그리고 이는 BigDat을 사용할 때 추가적인 부가가치의 원천이 됩니다. 현재 수집되고 있는 데이터 세트가 미래 어딘가에서 현재 희귀본 1700의 가치와 유사한 메커니즘에 따라 가치를 가질 가능성이 높습니다. 결국 임시 데이터 세트는 고유하며 향후 반복될 가능성이 거의 없습니다.

3. 소개 부분. 평가 기준

처리 과정에서 다음과 같은 오류 분류가 개발되었습니다.

1. 오류 등급(GOST R 8.736-2011 기준): a) 체계적 오류; b) 무작위 오류; c) 실수.

2. 다중성: a) 모노 왜곡; b) 다중 왜곡.

3. 결과의 중요성에 따라: a) 비판적; b) 중요하지 않습니다.

4. 발생 원인별:

A) 기술적 – 장비 작동 중에 발생하는 오류입니다. IoT 시스템, 통신 품질에 상당한 영향을 미치는 시스템, 장비(하드웨어)에 상당히 관련성이 높은 오류입니다.

B) 운영자 오류 - 입력 중 운영자의 오타부터 데이터베이스 설계 기술 사양의 오류까지 광범위한 오류입니다.

C) 사용자 오류 - 여기에는 "레이아웃 전환을 잊음"부터 미터를 피트로 착각하는 것까지 전체 범위의 사용자 오류가 있습니다.

5. 별도의 클래스로 분리:

a) "구분 기호의 작업", 즉 중복되었을 때 공백과 ":"(우리의 경우)
b) 함께 쓰여진 단어;
c) 서비스 문자 뒤에 공백이 없습니다.
d) 대칭형 다중 기호: (), "", "...".

그림 5에 제시된 데이터베이스 오류의 체계화를 통해 오류 검색 및 이 예의 데이터 정리 알고리즘 개발을 위한 상당히 효과적인 좌표계가 형성되었습니다.

쌀. 5. 데이터베이스의 구조 단위에 해당하는 일반적인 오류(출처: Oreshkov V.I., Paklin N.B. "데이터 통합의 주요 개념").

정확성, 도메인 무결성, 데이터 유형, 일관성, 중복성, 완전성, 복제, 비즈니스 규칙 준수, 구조적 명확성, 데이터 이상, 명확성, 적시, 데이터 무결성 규칙 준수. (페이지 334. IT 전문가를 위한 데이터 웨어하우징 기본 사항/Paulraj Ponniah.—2판)

괄호 안에 영어 문구와 러시아어 기계 번역이 표시됩니다.

정확성. 데이터 요소에 대해 시스템에 저장된 값은 해당 데이터 요소 발생에 대한 올바른 값입니다. 기록에 고객 이름과 주소가 저장되어 있는 경우 해당 주소는 해당 이름을 가진 고객의 올바른 주소입니다. 주문 번호 1000에 대한 기록에서 12345678개로 주문된 수량을 찾은 경우 해당 수량은 해당 주문의 정확한 수량입니다.
[정확성. 데이터 요소에 대해 시스템에 저장된 값은 해당 데이터 요소 발생에 대한 올바른 값입니다. 기록에 고객 이름과 주소가 저장되어 있는 경우 해당 주소는 해당 이름을 가진 고객의 올바른 주소입니다. 주문 번호 1000에 대한 기록에서 12345678개로 주문된 수량을 찾으면 해당 수량은 해당 주문의 정확한 수량입니다.]

도메인 무결성. 속성의 데이터 값은 허용되고 정의된 값 범위에 속합니다. 일반적인 예는 성별 데이터 항목에 허용되는 값이 "남성"과 "여성"인 것입니다.
[도메인 무결성. 속성 데이터 값은 유효하고 정의된 값 범위 내에 속합니다. 일반적인 예는 성별 데이터 요소에 대한 유효한 값 "남성"과 "여성"입니다.]

데이터 형식. 데이터 속성의 값은 실제로 해당 속성에 대해 정의된 데이터 유형으로 저장됩니다. 매장 이름 필드의 데이터 유형이 "텍스트"로 정의된 경우 해당 필드의 모든 인스턴스에는 숫자 코드가 아닌 텍스트 형식으로 표시된 매장 이름이 포함됩니다.
[데이터 형식. 데이터 속성의 값은 실제로 해당 속성에 대해 정의된 데이터 유형으로 저장됩니다. 매장 이름 필드 데이터 유형이 "텍스트"로 정의된 경우 이 필드의 모든 인스턴스에는 숫자 코드가 아닌 텍스트 형식으로 표시된 매장 이름이 포함됩니다.]

일관성. 데이터 필드의 형식과 내용은 여러 소스 시스템에서 동일합니다. 한 시스템에서 제품 ABC의 제품 코드가 1234라면 모든 소스 시스템에서 이 제품의 코드는 1234입니다.
[일관성. 데이터 필드의 형식과 내용은 소스 시스템마다 동일합니다. 한 시스템에서 제품 ABC의 제품 코드가 1234인 경우 각 소스 시스템에서 해당 제품의 코드는 1234입니다.]

중복성. 동일한 데이터가 시스템의 두 위치 이상에 저장되어서는 안 됩니다. 효율성을 이유로 데이터 요소가 의도적으로 시스템의 여러 위치에 저장되는 경우 중복성을 명확하게 식별하고 검증해야 합니다.
[중복성. 동일한 데이터가 시스템의 한 위치 이상에 저장되어서는 안 됩니다. 효율성을 이유로 데이터 요소가 의도적으로 시스템의 여러 위치에 저장되는 경우 중복성을 명확하게 정의하고 검증해야 합니다.]

완전성. 시스템의 특정 속성에 누락된 값이 없습니다. 예를 들어 고객 파일에는 모든 고객의 "상태" 필드에 유효한 값이 있어야 합니다. 주문 세부정보 파일에는 주문에 대한 모든 세부정보 기록이 완전히 입력되어야 합니다.
[완전성. 이 속성에 대한 시스템에는 누락된 값이 없습니다. 예를 들어 클라이언트 파일에는 각 클라이언트의 "상태" 필드에 대한 유효한 값이 있어야 합니다. 주문 세부정보 파일에는 각 주문 세부정보 기록이 완전히 작성되어야 합니다.]

복사. 시스템 내 기록의 중복이 완전히 해결되었습니다. 제품 파일에 중복 기록이 있는 것으로 알려진 경우 각 제품에 대한 모든 중복 기록이 식별되고 상호 참조가 생성됩니다.
[복제하다. 시스템 내 기록 중복이 완전히 제거되었습니다. 제품 파일에 중복 항목이 포함된 것으로 알려진 경우 각 제품의 모든 중복 항목이 식별되고 상호 참조가 생성됩니다.]

비즈니스 규칙 준수. 각 데이터 항목의 값은 규정된 비즈니스 규칙을 따릅니다. 경매 시스템에서는 해머 가격 또는 판매 가격이 예비 가격보다 낮을 수 없습니다. 은행 대출 시스템에서 대출 잔액은 항상 양수이거나 XNUMX이어야 합니다.
[비즈니스 규칙을 준수합니다. 각 데이터 요소의 값은 확립된 비즈니스 규칙을 따릅니다. 경매 시스템에서는 해머 가격 또는 판매 가격이 예비 가격보다 낮을 수 없습니다. 은행 신용 시스템에서 대출 잔액은 항상 양수 또는 XNUMX이어야 합니다.]

구조적 확실성. 데이터 항목이 자연스럽게 개별 구성 요소로 구성될 수 있는 경우 항목에는 잘 정의된 구조가 포함되어야 합니다. 예를 들어, 개인의 이름은 자연스럽게 이름, 중간 이니셜, 성으로 구분됩니다. 개인의 이름 값은 이름, 중간 이니셜, 성으로 저장되어야 합니다. 데이터 품질의 이러한 특성은 표준 시행을 단순화하고 누락된 값을 줄입니다.
[구조적 확실성. 데이터 요소가 개별 구성 요소로 자연스럽게 구성될 수 있는 경우 요소는 잘 정의된 구조를 포함해야 합니다. 예를 들어, 사람의 이름은 자연스럽게 이름, 중간 이니셜, 성으로 구분됩니다. 개인 이름의 값은 이름, 중간 이니셜, 성으로 저장되어야 합니다. 이러한 데이터 품질 특성은 표준 적용을 단순화하고 누락된 값을 줄입니다.]

데이터 이상. 필드는 정의된 목적으로만 사용해야 합니다. 긴 주소에 대해 가능한 세 번째 주소 줄에 대해 Address-3 필드가 정의된 경우 이 필드는 세 번째 주소 줄을 기록하는 데에만 사용해야 합니다. 고객의 전화번호나 팩스번호를 입력하는 데 사용해서는 안 됩니다.
[데이터 이상. 필드는 정의된 목적으로만 사용해야 합니다. 주소-3 필드가 긴 주소에 대해 가능한 세 번째 주소 줄에 대해 정의된 경우 이 필드는 세 번째 주소 줄을 기록하는 데에만 사용됩니다. 고객의 전화번호나 팩스번호를 입력하는 데 사용해서는 안 됩니다.]

명쾌함. 데이터 요소는 품질 데이터의 다른 모든 특성을 가질 수 있지만 사용자가 그 의미를 명확하게 이해하지 못하는 경우 데이터 요소는 사용자에게 아무런 가치가 없습니다. 적절한 명명 규칙은 사용자가 데이터 요소를 잘 이해할 수 있도록 도와줍니다.
[명쾌함. 데이터 요소는 좋은 데이터의 다른 모든 특성을 가질 수 있지만 사용자가 그 의미를 명확하게 이해하지 못하면 데이터 요소는 사용자에게 아무런 가치가 없습니다. 올바른 명명 규칙은 사용자가 데이터 요소를 잘 이해할 수 있도록 도와줍니다.]

시기 적절한. 사용자는 데이터의 적시성을 결정합니다. 사용자가 고객 차원 데이터가 하루보다 오래되지 않기를 기대하는 경우 소스 시스템의 고객 데이터에 대한 변경 사항을 매일 데이터 웨어하우스에 적용해야 합니다.
[적시에. 사용자는 데이터의 적시성을 결정합니다. 사용자가 고객 차원 데이터가 하루도 지나지 않은 것으로 예상하는 경우 소스 시스템의 고객 데이터에 대한 변경 사항을 매일 데이터 웨어하우스에 적용해야 합니다.]

유용성. 데이터 웨어하우스의 모든 데이터 요소는 사용자 컬렉션의 일부 요구 사항을 충족해야 합니다. 데이터 요소는 정확하고 품질이 높을 수 있지만 사용자에게 가치가 없다면 해당 데이터 요소가 데이터 웨어하우스에 있는 것이 전혀 필요하지 않습니다.
[공익사업. 데이터 저장소의 각 데이터 항목은 사용자 컬렉션의 일부 요구 사항을 충족해야 합니다. 데이터 요소는 정확하고 품질이 높을 수 있지만 사용자에게 가치를 제공하지 않으면 해당 데이터 요소가 데이터 웨어하우스에 있을 필요가 없습니다.]

데이터 무결성 규칙 준수. 소스 시스템의 관계형 데이터베이스에 저장된 데이터는 엔터티 무결성 및 참조 무결성 규칙을 준수해야 합니다. 기본 키로 null을 허용하는 테이블에는 엔터티 무결성이 없습니다. 참조 무결성은 상위-하위 관계를 올바르게 설정하도록 합니다. 고객-주문 관계에서 참조 무결성은 데이터베이스의 모든 주문에 대해 고객의 존재를 보장합니다.
[데이터 무결성 규칙을 준수합니다. 소스 시스템의 관계형 데이터베이스에 저장된 데이터는 엔터티 무결성 및 참조 무결성 규칙을 준수해야 합니다. 기본 키로 null을 허용하는 테이블에는 엔터티 무결성이 없습니다. 참조 무결성은 부모와 자식 간의 관계가 올바르게 설정되도록 합니다. 고객-주문 관계에서 참조 무결성은 데이터베이스의 모든 주문에 대해 고객이 존재하도록 보장합니다.]

4. 데이터 정리 품질

빅데이터에서는 데이터 클리닝의 품질이 다소 문제가 되는 문제입니다. 작업을 완료하는 데 어느 정도의 데이터 정리가 필요한지에 대한 질문에 대답하는 것은 모든 데이터 분석가의 기본입니다. 대부분의 현재 문제에서는 각 분석가가 이를 스스로 결정하며 외부의 누구도 자신의 솔루션에서 이러한 측면을 평가할 수 없을 것입니다. 그러나 이 사건의 과제에서는 법적 데이터의 신뢰성이 중요하기 때문에 이 문제는 매우 중요했습니다.

운영 신뢰성을 결정하기 위해 소프트웨어 테스트 기술을 고려합니다. 오늘은 이 모델보다 더 많은 모델이 있습니다 200. 많은 모델이 청구 서비스 모델을 사용합니다.

그림. 6

다음과 같이 생각하십시오. "발견된 오류가 이 모델의 실패 이벤트와 유사한 이벤트인 경우 매개변수 t의 유사점을 찾는 방법은 무엇입니까?" 그리고 나는 다음 모델을 컴파일했습니다. 테스터가 하나의 레코드를 확인하는 데 걸리는 시간이 1분(문제의 데이터베이스에 대해)이고 모든 오류를 찾는 데 365분이 필요하다고 가정해 보겠습니다. 이는 약 494년 3년입니다. 몇 달의 근무 시간. 우리가 알고 있듯이 이는 매우 많은 양의 작업이며 이 데이터베이스의 컴파일러에게는 데이터베이스를 확인하는 비용이 엄청나게 들 것입니다. 이러한 반성에서 비용에 대한 경제적 개념이 나타나고 분석 결과 이것이 상당히 효과적인 도구라는 결론에 도달했습니다. 경제학 법칙에 따르면, “기업의 최대 이윤이 달성되는 생산량(단위)은 새로운 생산량 단위를 생산하는 데 드는 한계 비용과 이 기업이 받을 수 있는 가격을 비교하는 지점에 위치합니다. 새로운 유닛을 위해.” 각각의 후속 오류를 찾으려면 점점 더 많은 기록 확인이 필요하다는 가정에 따르면 이는 비용 요소입니다. 즉, 테스트 모델에 채택된 가정은 다음 패턴의 물리적 의미를 갖습니다. i번째 오류를 찾으려면 n개의 레코드를 확인해야 하고, 다음 (i+3) 오류를 찾으려면 다음이 필요합니다. m개의 레코드를 확인하고 동시에 n개의 레코드를 확인하려면

1. 새로운 오류가 발견되기 전에 확인된 레코드 수가 안정화되면;
2. 다음 오류를 찾기 전에 확인되는 레코드 수가 늘어나면.

임계적 가치를 결정하기 위해 경제적 타당성 개념으로 전환했는데, 이 경우 사회적 비용 개념을 사용하면 다음과 같이 공식화할 수 있습니다. “오류를 수정하는 비용은 경제적 주체가 부담해야 합니다. 최저가로." 우리는 한 명의 에이전트, 즉 하나의 레코드를 확인하는 데 1분을 소비하는 테스터가 있습니다. 금전적으로 하루 6000루블을 벌면 12,2루블이 됩니다. (대략 오늘). 경제법에서 균형의 두 번째 측면을 결정하는 것은 남아 있습니다. 나는 이렇게 추론했다. 기존 오류는 해당 사람, 즉 부동산 소유자가 이를 수정하기 위해 노력을 기울여야 합니다. 이를 위해서는 1일의 조치(신청서 제출, 수정된 문서 수신)가 필요하다고 가정해 보겠습니다. 그러면 사회적 관점에서 그의 비용은 하루 평균 급여와 같을 것입니다. Khanty-Mansi Autonomous Okrug의 평균 미지급 급여 "2019년 XNUMX~XNUMX월 한티-만시스크 자치구-우그라의 사회 경제적 발전 결과" 73285 문지름. 또는 3053,542 루블/일. 따라서 우리는 다음과 같은 임계값을 얻습니다.
3053,542: 12,2 = 250,4 레코드 단위.

즉, 사회적 관점에서 보면 테스터가 251개의 기록을 확인하고 하나의 오류를 발견했다면 이는 사용자가 직접 오류를 수정하는 것과 같습니다. 따라서 테스터가 다음 오류를 찾기 위해 252개의 레코드를 확인하는 것과 동일한 시간을 소비했다면 이 경우 수정 비용을 사용자에게 전가하는 것이 좋습니다.

사회적 관점에서 각 전문가가 생성한 모든 추가 가치, 즉 세금 및 사회적 지불을 포함한 비용을 고려해야 하기 때문에 여기서는 단순화된 접근 방식을 제시하지만 모델은 명확합니다. 이 관계의 결과는 전문가에 대한 다음과 같은 요구 사항입니다. IT 업계의 전문가는 전국 평균보다 더 높은 급여를 받아야 합니다. 그의 급여가 잠재적인 데이터베이스 사용자의 평균 급여보다 적다면 그 자신이 전체 데이터베이스를 직접 확인해야 합니다.

설명된 기준을 사용할 때 데이터베이스 품질에 대한 첫 번째 요구 사항이 형성됩니다.
나(tr). 심각한 오류의 비율은 1/250,4 = 0,39938%를 초과해서는 안 됩니다. 조금 덜 정제 업계의 금. 그리고 물리적인 측면에서 오류가 있는 레코드는 1459개 이하입니다.

경제적 후퇴.

실제로 기록에 이러한 많은 오류를 범함으로써 사회는 다음과 같은 경제적 손실에 동의합니다.

1459*3053,542 = 4 루블.

이 금액은 사회가 이러한 비용을 줄일 수 있는 도구를 갖고 있지 않다는 사실에 따라 결정됩니다. 누군가가 오류가 있는 기록의 수를 예를 들어 259개로 줄일 수 있는 기술을 가지고 있다면 사회는 다음을 절약할 수 있습니다.
1200*3053,542 = 3 루블.

그러나 동시에 그는 자신의 재능과 일을 요청할 수 있습니다. 예를 들어 백만 루블입니다.
즉, 사회적 비용은 다음과 같이 감소됩니다.

3 – 664 = 250 루블.

본질적으로 이 효과는 BigDat 기술 사용으로 인한 부가 가치입니다.

그러나 여기서는 이것이 사회적 효과이고 데이터베이스 소유자는 지방자치단체이며 이 데이터베이스에 기록된 재산 사용으로 인한 수입은 0,3% 비율로 다음과 같다는 점을 고려해야 합니다. 2,778억 4만 루블/ 년도. 그리고 이러한 비용 (455 루블)은 부동산 소유자에게 이전되기 때문에 그를 크게 괴롭히지 않습니다. 그리고 이런 측면에서 빅데이터를 좀 더 정제하는 기술을 개발하는 사람은 이 데이터베이스의 소유자를 설득할 수 있는 능력을 보여줘야 하는데, 그러기 위해서는 상당한 인재가 필요하다.

이 예에서는 신뢰성 테스트 중 소프트웨어 검증의 Schumann 모델 [2]을 기반으로 오류 평가 알고리즘이 선택되었습니다. 인터넷에서의 보급과 필요한 통계 지표를 얻을 수 있는 능력으로 인해. 방법론은 Monakhov Yu.M.에서 따왔습니다. "정보 시스템의 기능적 안정성"은 그림 7의 스포일러 아래를 참조하세요. 9-XNUMX.

쌀. 7 – 9 슈만 모델의 방법론





이 자료의 두 번째 부분에서는 슈만 모델을 사용한 결과를 얻는 데이터 정리의 예를 제시합니다.
얻은 결과를 발표하겠습니다.
추정된 오류 수 N = 3167 n.
매개변수 C, 람다 및 신뢰도 함수:

Pic.17

기본적으로 람다는 각 단계에서 오류가 감지되는 강도를 실제로 나타내는 지표입니다. 두 번째 부분을 보면 이 지표의 추정치는 시간당 42,4 오류로 슈만 지표와 상당히 유사합니다. 위에서는 개발자가 1분당 250,4개의 레코드를 확인할 때 오류를 발견하는 비율이 1 레코드당 XNUMX개 오류 이상이어야 한다고 판단했습니다. 따라서 슈만 모델에 대한 람다의 임계값은 다음과 같습니다.

60 / 250,4 = 0,239617입니다.

즉, 기존 38,964에서 람다가 0,239617로 감소할 때까지 오류검출 절차를 수행해야 한다.

또는 표시기 N(잠재 오류 수)에서 n(수정된 오류 수)을 뺀 값이 허용된 임계값(1459개) 아래로 감소할 때까지입니다.

문학

1. Monakhov, Yu.M. 정보 시스템의 기능적 안정성. 3시간 안에 1부. 소프트웨어 안정성: 교과서. 수당 / Yu.M. Monakhov; 블라딤. 상태 대학 – 블라디미르: Izvo Vladim. 상태 대학, 2011. – 60p. – ISBN 978-5-9984-0189-3.
2. Martin L. Shooman, “소프트웨어 신뢰성 예측을 위한 확률 모델.”
3. IT 전문가를 위한 데이터 웨어하우징 기본 사항 / Paulraj Ponniah.—2nd ed.

두 번째 부분. 이론적 인

출처 : habr.com