모델링 예/아니오 데이터베이스의 속성

Question

나는 사용자가 속성 집합에서 선택할 수있는 매우 일반적인 시나리오가 있습니다. UI의 속성은 확인란으로 표시됩니다. 예를 들어

:

구성 : 하드 드라이브 (예/아니오), CPU (Y/N), 모니터 (Y/N), 키보드 (Y/N) 등 ....

과거에 나는 일반적으로 다음과 같이이 시나리오를 모델링 한 :

"PCs" 1:M "PC Components" M:1 "Components" 

또 다른 옵션은 "PC를"테이블에 Y/N 필드로 "속성"을 확인하는 것입니다.

PCs (table) 
----------- 
PCId(PK) 
Harddrive(y/n) 
CPU(y/n) 
etc... 

과거에는 하나 대 다른 것에 대한 나의 근거는 사용자가 새로운 속성을 입력 할 수 있는지 여부에 따라 달라집니다. 대답이 '예'인 경우 첫 번째 옵션을 선택하고 대답이 '아니오'인 경우 일반적으로 y/n 속성을 사용합니다.

그러나 지금은 약 20 개의 속성이 여러 범주로 나뉘어있는 시나리오가 있습니다. ERD를 생성 한 후에는 "잘못된 것"으로 보이고 테이블에는 불합리한 수의 열이 있습니다.

제 질문은 이것을 모델링하는 표준/올바른 방법이 있습니까? 그렇다면 이름이 있습니까?

Answer 1

특성에 호환 가능한 데이터 형식 (모두 y/n)이 있으므로 좀 더 "압축 된"데이터 모델 (특성 당 열 이외의 다른 것)을 설계하려고합니다.

각 속성에 서로 다른 데이터 유형이있는 경우 (예 : 고유 한 찾아보기 테이블을 사용하여 값 집합으로 제한된 경우) 속성 당 열을 사용해야한다는 점을 생각해보십시오.

Domain-Key Normal Form을 참조하십시오. y/n 속성을 행으로 모델링한다는 것은 필수 속성을 나타내는 방법이 없음을 의미합니다 (은에 Y 또는 N 값이 있어야 함). 따라서 N 개의 속성에 대해 N 개의 행이 있어야한다는 제약이 있습니다. 최소 행 수에 대한 제한 조건은 도메인 제한 조건이나 키 제한 조건이 아니므로 DKNF 테스트가 실패합니다.

모든 테이블이 DKNF를 준수해야 할 필요는 없지만 속성 별 열 디자인을 설명하는 용어를 묻는 경우 "도메인/키 표준 양식"이 적합 할 것을 제안합니다.

Answer 2

다음과 같은 간단한 규칙을 따릅니다. 열당 데이터 한 조각. 데이터베이스가 스토리지 구조를 최적화하도록하십시오.

그러므로 SQL Server에서는 BIT 데이터 유형과 이에 대한 별도의 열을 사용합니다. 다른 데이터베이스는 확실합니다. 해당 유형이 있습니다.