간단히 말해서 상황은 "위치"의 계층 구조를 구축하는 데 사용되는 데이터베이스가 있습니다. (예 : 주소> 건물 1> 1 층> 방).
각 위치는 테이블에 저장됩니다. 각 위치는 다른 "유형"일 수 있습니다. 유형은 다른 테이블에 정의되어 있습니다. (위치 유형을 사용하여 위치에 추가 할 수있는 위치를 제한합니다.)
우리가 직면 한 난관은 다음과 같습니다. 다양한 유형의 위치에 대해 서로 다른 유형의 정보를 저장할 수 있어야합니다. 예를 들어, "건물"의 위치 유형은 "방"의 위치 유형이 치수 또는 페인트 색상을 저장해야하는 곳에 주소를 저장해야 할 수 있습니다.
분명히 우리는 특정 위치 유형에 필요한 속성을 보유하기 위해 정의한 각 위치 유형에 대한 테이블을 생성 한 다음 애플리케이션 로직을 사용하여 특정 위치의 추가 정보를 가져 오기 위해 적절한 테이블을 쿼리 할 수 있습니다. 응용 프로그램 논리에 의존하지 않고 데이터베이스에서 관계형으로이를 수행하는 더 우아하거나 실용적인 방법이 있습니까?
감사!
이를 수행하는 관계 적으로 순수한 방법은 초기 제안을 구현하는 것입니다. 즉, 이러한 유형의 위치에만 적용 할 수있는 속성을 보유하는 BUILDING_LOCATIONS와 같은 별도의 테이블이 있습니다. 고유 한 속성이있는 각 위치 유형에 대해 다른 [TYPE] _LOCATIONS 테이블이 생성됩니다. 이러한 방식으로 표준 데이터베이스 제약 기능을 사용하여 이러한 테이블에있는 데이터의 무결성을 보장 할 수 있습니다.
또 다른 방법은 BUILDING_ADDRESS 및 ROOM_DIMENSIONS와 같은 일련의 Null 허용 열을 LOCATIONS 테이블에 추가하는 것입니다. 이것은이 테이블에 널값이 존재할 수 있음을 의미하므로 관계 적으로 순수하지 않습니다. 그러나 데이터의 무결성을 보장하기 위해 표준 데이터베이스 기능을 계속 사용할 수 있습니다. 특정 상황에서 특정 값이 필수 인 경우 좀 더 복잡 할 수 있습니다. 또한 서로 다른 속성이 많은 위치 유형이 많은 경우 테이블의 열 수가 다루기 어려울 수 있습니다.
또 다른 방법은 Entity-Attribute-Value 모델입니다. 일반적으로 가능하면이를 피해야합니다. 이제 열 값이 도메인에 대해 더 이상 정의되지 않기 때문에 관계 적으로 순수하지 않으며 데이터의 무결성을 보장하는 것이 불가능하지는 않지만 매우 어렵습니다. 이렇게하려면 표준 데이터베이스 제약 조건을 사용할 수 없기 때문에 많은 맞춤형 코딩이 필요합니다 (데이터베이스 제약 조건이 무료로 제공하는 동시성 제어와 같은 것을 수용하기 위해 신중하게 구현해야 함). 그러나 정보에 대한 값을 저장하는 데 관심이 있고 그 값으로 아무것도하지 않는 경우이 방법을 사용할 수 있습니다.
EAV 방법은 엔터티에 속성을 추가하기가 매우 쉬워 보이므로 기본 방법이 될 위험이 있습니다. 그런 다음 중요한 처리가 종속 된 속성을 추가하는 데 사용되며,이 방법을 사용하여 데이터의 무결성을 보장 할 수 없기 때문에 사용중인 값이 의미가없고 처리를위한 전체 논리적 기반이 파괴된다는 것을 알게됩니다.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다