[DB설계] 28. 식별자(키)의 검토

표준 SQL 및 데이터베이스 입문

Mar 1. 2025

계(relationship)이 정리되면 테이블은 만들 수 있습니다. 그런데 몇 가지 확인해두어야 할 사항이 있습니다. 우선은 식별자 즉 키에 관한 것입니다.

ER모델에서는 식별자에 표시를 붙여 다른 속성과 구분했었습니다. 식별자는 정말 중요합니다. 엔티티가 모두 구성되면, 각 엔티티의 속성을 다시 한번 체크해 봅시다. 그 중 한가지 핵심 포인트는 바로 식별자입ㅂ니다.

⑴ 사용되지 않는 식별자는 존재하지 않는가?

식별자는 '무언가를 식별할 수 있는 것'이 엔티티 내에 묻혀 있지 않은지 확인해야 합니다. 식별자여야 할 항목이 다른 속성으로 다뤄지고 있다면, 이는 데이터베이스 설계에서 문제가 있다는 것을 의미합니다. 외부키로 들어가 있다면 괜찮지만 데이터베이스에서 등록할 수 없다는 뜻이 아니라, 설계상 문제가 없는지 확인할 수 있는 힌트를 제공하는 것입니다. 이유를 알 수 있다면 그것만으로도 충분합니다. 즉 ER다이어그램에서 그런 문제점을 추출할 수 있습니다.

식별자(identifier)는 그 이름 그대로, 무엇인가를 식별할 수 있는 항목으로 보통 'XX 코드', 'XX 번호'와 같은 이름이 붙여 있습니다. 따라서 이러한 이름의 항목임에도 불구하고 식별자로 사용되지 않는다면, 본래는 별도로 관리해야 하는 대상이 하나의 엔티티에 포함되어 있거나, 관리되어야 할 것이 제대로 관리되지 않고 있다는 문제를 시사할 수 있습니다.

채워진 식별자(키)가 없는지 확인

예를 들어, '출하처의 주소에 따라 대응을 변경한다'와 같이 현장의 관행에 묻혀 보여지지 않는 처리 방식이 존재할 가능성도 있습니다. 이런 경우, 주소뿐만 아니라 새롭게 '지역코드'가 필요할 수도 있습니다.

⑵ 식별자에 복합키가 숨겨져 있지 않는가?

이제는 식별자의 구체적인 값에 주목해 봅시다.여기서 주의해야 할 점은 복합키가 숨어있지 않은지 확인하는 것입니다. 즉, 식별자가 여러 코드의 조합으로 구성되어 있는지, 즉, 식별자 안에 다른 식별자가 포함되어 있는 경우가 있는지를 살펴봐야 합니다. 예를들어, 'XXX-XXX'와 같이 하이픈("-")이 붙여 있는 경우는 특히 의심스러워집니다.

우편번호나 전화번호가 바로 생각나겠지만, 전체를 하나의 식별자로 사용하고 있다면 문제가 되지 않습니다.우리가 우편번호 그 자체를 관리하는 것이 아니기 때문입니다. 그러나, 전체를 식별자로 사용하면서 '만약 몇 번째 자리가 무엇이면 ~'라는 추가적인 식별규칙을 적용하고 있다면, 이에 대해 신중히 고려해야 합니다. 이는 정규형의 문제와 비슷하게 복합키의 사례가 될 수 있습니다.

즉, 이러한 경우는 데이터 불일치의 원인이 될 수 있습니다. 예를 들어, '상품코드의 첫자리가 A이면 특정처리를 수행한다', '거래처 코드의 끝자리가 01이면 특정의미를 가진다'와 같이 식별자 일부에 특별한 의미가 부여되어 있다면, 이는 매우 복잡한 처리를 야기할 가능성이 큽니다. 설렁 겉보기에는 하나의 식별자처럼 보여도, 실제로는 복합키로 취급해야 할 수 있습니다.

또한, 단순히 사람이 이해하기 쉽도록 이름의 첫글자를 코드 앞에 붙이는 경우에도, 나중에 이름을 변경하면 키를 어떻게 처리할 것인지에 대한 업데이트 불일치 문제가 발생할 수 있습니다. 따라서, 식별자에는 데이터를 특정하는 역할 이상의 정보를 포함시키지 않는 것이 좋습니다. 만약, 현장에서 이름이나 창고코드등이 필요하다면, 이를 식별자에 혼합싴ㅋㅋ키는 대신 별도로 출력하는 것이 바람직합니다. 참고로, SELECT문에서는 여러 항목을 연결하여 하나의 열로 표시할 수도 있습니다.

⑶ 존재하지 않는 식별자를 사용하고 있지 않는가?

반대로 기존에 존재하지 않는 식별자를 사용하고 있는지는 않은지 확인해야 합니다. 왜냐하면, 식별한 단서가 없다면 지금까지의 업무에도 지장이 생겼을 것입니다. 그럼에도 불구하고 식별자를 새로 설정해야 한다는 것은 설계상의 문제로 인해 식별자가 제대로 마련되지 않았다는 의미일수도 있습니다. 즉, 엔티티에 식별자가 없어서 곤란한 상황이 발생한 결과 '그러면 만들어 보자'는 결론에 이르게 되는 것입니다.

만약, 지금까지 식별에 어려움을 겪어왔던 상황이라면, 오히려 새로 식별자를 도입하는 것이 정답일수도 있습니다. 하지만, 여기서는 어쨌든 현장에서 실제로 어떻게 관리되고 있는지, 즉 현실이 어떠한지를 반드시 확인해야 합니다.

데이터 모델링 과정에서 새로운 식별자가 필요해진다면, 그것이 정말로 필요한지 신중하게 판단해야 합니다. 기존 사업에 대해 데이터 모델링을 수행할 때는 우선 지금까지의 상황을 정확하게 파악하는 것이 선행되어야 합니다. 사업개혁을 위해 코드체제를 재검토하겠다는 논의가 있더라도 우선은 현황분석이 우선입니다.

시스템 관리자의 관점에서는 관리되어야 할 대상, 즉, 식별자가 필요한 대상일지라도 현장에서는 그 관리의 의미가 없을수도 있습니다. 관리할 필요없는 항목까지 관리하면 불필요한 처리부담이 증가해 업무가 지연될 수 있습니다. 반대로, 제대로 관리함으로써 업무효율화나 새로운 비즈니스 기회가 창출될 가능성도 있습니다.