속성 하나에 값을 두 개 담는 순간, 그 컬럼은 평생 LIKE 검색으로만 뒤져야 하는 감옥이 됩니다.
풀고 시작
문제 1. 주문 엔터티에 주문수량과 단가가 있고, 여기에 주문금액을 따로 두었습니다. 주문금액은 어떤 속성으로 분류될까요?
다른 속성에서 계산해 만들어진 값이므로 파생 속성입니다. 기본 속성은 업무에서 그대로 들어온 값이고, 설계 속성은 일련번호처럼 관리를 위해 새로 만든 값입니다. 파생 속성은 계산식을 어디에 둘지 반드시 정해 두어야 값이 어긋나지 않습니다.
속성은 더 쪼갤 수 없는 최소 단위입니다
속성(attribute)은 엔터티가 관리하는 항목이며, 업무에서 필요한 최소의 의미 단위입니다. 여기서 최소라는 말이 시험과 실무 양쪽에서 계속 발목을 잡습니다.
주소를 한 컬럼에 통째로 넣은 시스템을 생각해 보죠. "서울특별시 강남구 테헤란로 100"이 한 덩어리로 들어 있으면 강남구에 사는 고객을 세는 일이 문자열 검색이 됩니다. 시도와 시군구와 도로명을 따로 두었다면 그냥 조건 하나였을 일입니다. 반대로 지나치게 쪼개도 문제가 생깁니다. 업무에서 한 번도 따로 쓰지 않는 단위까지 갈라 두면 매번 이어 붙여야 하니까요. 그래서 기준은 "얼마나 잘게"가 아니라 업무가 그 단위로 값을 다루는가입니다.
속성과 인스턴스의 관계는 이렇게 정리됩니다. 엔터티는 두 건 이상의 인스턴스를 갖고, 인스턴스는 각 속성마다 하나의 속성값을 갖습니다. 하나라는 말이 중요합니다. 값이 여러 개 필요하면 그것은 속성이 아니라 별도의 엔터티라는 신호입니다.
기본, 설계, 파생
발생 방식으로 나누면 속성은 셋으로 갈립니다.
종류
어디서 왔나
예
기본 속성
업무에서 그대로 들어온 값
고객명, 주문일자, 상품가격
설계 속성
업무에 없던 것을 관리를 위해 만든 값
주문번호, 상품분류코드
파생 속성
다른 속성에서 계산해 만든 값
주문금액, 총적립포인트
파생 속성은 다루기가 까다롭습니다. 계산해서 저장해 두면 조회가 빨라지지만, 원본이 바뀌었을 때 같이 바뀌지 않으면 그 순간 거짓이 됩니다. 그래서 파생 속성은 개수를 최소로 하고, 어디에서 어떻게 계산되는지를 반드시 정의해 두어야 합니다. 1강에서 본 중복과 비일관성이 실무에서 가장 자주 터지는 자리가 바로 여기입니다.
세분화 정도로 나누면 단일 속성, 복합 속성, 다중값 속성이 됩니다. 단일 속성은 더 나눌 수 없는 값이고, 복합 속성은 주소처럼 여러 의미가 뭉쳐 있는 값이며, 다중값 속성은 전화번호처럼 값이 여러 개 붙을 수 있는 값입니다. 다중값 속성은 별도의 엔터티로 분리하는 것이 원칙입니다. 5강 정규화에서 다시 만나게 됩니다.
엔터티를 구성하는 자리로 보면 또 다른 분류
같은 속성을 엔터티 구성 관점에서 보면 세 가지로 나뉩니다. 인스턴스를 식별하는 PK 속성, 다른 엔터티를 가리키는 FK 속성, 그리고 나머지 일반 속성입니다.
FK 속성이 재밌는 지점입니다. 외래 식별자는 관계에서 상속받아 내려온 속성이라, 모델을 그리는 사람이 직접 만들어 넣는 것이 아니라 관계를 맺는 순간 따라 들어옵니다. 그래서 물리 모델에는 컬럼이 하나 늘어 있는데 논리 모델에는 관계선만 그려져 있는 상황이 생기죠. 4강에서 이 상속을 자세히 봅니다.
도메인, 그리고 이름 짓기
도메인(domain)은 각 속성이 가질 수 있는 값의 범위입니다. 성별이라는 속성이 남과 여만 가질 수 있다면 그 집합이 도메인이고, 나이가 0 이상 150 이하의 정수라면 그것이 도메인입니다. 물리 모델에서는 자료형과 길이, 제약 조건으로 구현됩니다.
도메인을 미리 정해 두면 좋은 점이 분명합니다. 같은 의미의 속성이 테이블마다 다른 길이로 선언되는 사고를 막고, 값의 유효성을 데이터베이스가 직접 지켜 줍니다. 응용 프로그램 열 곳이 각자 검사하는 것보다 한 곳에서 막는 편이 언제나 낫습니다.
속성 이름은 해당 업무에서 쓰는 용어로 짓고, 약어는 가급적 피하며, 서술식 이름을 쓰지 않고, 전체 모델에서 유일하게 둡니다. 특히 서로 다른 엔터티에 같은 이름의 속성이 있으면 뒤에 오는 사람이 둘을 같은 것으로 착각합니다. 접두어를 붙여서라도 구분해 두는 편이 안전합니다.
다음 강에서는 엔터티들을 서로 이어 주는 관계와, 인스턴스를 골라내는 식별자를 봅니다.
인출 문제
문제 1. 다중값 속성을 다루는 방법으로 가장 적절한 것은?
하나의 속성값 자리에 여러 값이 들어가야 한다면 그것은 사실 별개의 집합입니다. 구분자로 이어 붙이면 검색과 정합성 관리가 모두 무너지고, 컬럼을 미리 늘어놓는 방식은 개수가 바뀌는 순간 모델을 다시 고쳐야 합니다.
문제 2. 파생 속성에 대한 설명으로 옳지 않은 것은?
파생 속성이 위험한 이유가 바로 자동으로 맞춰지지 않는다는 점입니다. 저장해 둔 값과 원본이 어긋나는 순간 데이터가 거짓말을 시작하므로, 갱신 시점과 계산 규칙을 설계에서 못 박아 두어야 합니다.
문제 3. 도메인에 대한 설명으로 가장 적절한 것은?
도메인은 값의 범위이고, 물리 모델에서 자료형과 길이, 제약 조건으로 구현됩니다. 첫 번째는 관계, 세 번째는 식별자의 설명이라 층이 다릅니다.
문제 4. 다음 중 설계 속성으로 보기에 가장 적절한 것은?
설계 속성은 업무에 원래 없던 것을 관리 편의를 위해 만들어 넣은 값입니다. 이름과 가격은 업무에서 그대로 들어온 기본 속성이고, 곱해서 만든 금액은 파생 속성입니다.
더 풀기
출제기준의 세세항목을 따라 이 강의 범위에서 새로 낸 문제입니다. 모의고사도 여기에서 뽑습니다.
묶음 1
문제 1. 속성을 가장 정확하게 설명한 것은?
속성은 엔터티가 지닌 성질을 담는 최소 단위입니다. 컬럼은 물리 구현이고, 인스턴스를 구분하는 것은 식별자이며, 엔터티를 잇는 것은 관계입니다.
문제 2. 속성이 더 이상 쪼갤 수 없어야 한다는 원칙을 어긴 예로 가장 알맞은 것은?
시도와 시군구로 조회하거나 집계해야 한다면 그 주소는 여러 뜻이 뭉쳐 있는 것입니다. 다만 업무에서 통째로만 쓴다면 나누지 않는 편이 나을 수도 있어 판단이 필요합니다.
문제 3. 하나의 속성에 여러 값이 들어가는 상황, 예를 들어 취미 속성에 등산과 독서를 쉼표로 이어 붙여 저장하는 설계의 문제로 가장 알맞은 것은?
여러 값이 한 칸에 있으면 특정 취미를 가진 사람을 세는 것조차 문자열 검색으로 해야 합니다. 이런 다중값 속성은 별도 엔터티로 분리하는 것이 원칙입니다.
문제 4. 기본 속성을 가장 잘 설명한 것은?
사원 이름이나 입사일처럼 업무에 이미 있는 항목이 기본 속성입니다. 계산해 만든 것은 파생 속성, 설계자가 만든 것은 설계 속성입니다.
문제 5. 설계 속성의 예로 가장 알맞은 것은?
업무에 원래 없던 것을 관리 편의를 위해 설계자가 만든 것이 설계 속성입니다. 코드나 일련번호가 대표적입니다.
문제 6. 파생 속성을 모델에 두기로 할 때 반드시 함께 결정해야 하는 것은?
파생 속성은 원본이 바뀌면 즉시 어긋납니다. 갱신 시점과 계산 규칙을 정해 두지 않으면 조회는 빨라지지만 값은 믿을 수 없게 됩니다.
문제 7. 파생 속성을 두는 가장 큰 이유는?
파생 속성은 성능을 위해 일관성 관리 부담을 감수하는 선택입니다. 저장 공간은 오히려 늘고 정규화 관점에서는 후퇴입니다.
문제 8. 엔터티를 구성하는 자리로 속성을 나눌 때 기본키 속성을 가장 잘 설명한 것은?
자리에 따른 분류는 기본키 속성과 외래키 속성과 일반 속성으로 나뉩니다. 참조하는 것은 외래키 속성, 나머지는 일반 속성입니다.
문제 9. 외래키 속성이 하는 일로 가장 알맞은 것은?
관계선을 데이터로 옮기면 외래키가 됩니다. 값의 범위를 제한하는 것은 도메인이나 체크 제약의 일입니다.
문제 10. 다음 중 속성으로 두기보다 별도 엔터티로 분리해야 하는 경우로 가장 알맞은 것은?
값이 여러 개이고 각 값이 자체 속성을 가진다면 그것은 이미 집합입니다. 자주 바뀌거나 길다는 이유만으로는 분리 근거가 되지 않습니다.
묶음 2
문제 1. 도메인을 가장 잘 설명한 것은?
도메인은 어떤 값이 허용되는가를 정합니다. 자료형과 길이는 도메인을 물리로 옮긴 결과이고, 기본값은 도메인 안에서 정하는 별개의 항목입니다.
문제 2. 도메인을 정의해 두면 얻는 이점으로 가장 알맞은 것은?
금액이라는 도메인을 정해 두면 어느 테이블의 금액이든 같은 자리수와 같은 단위를 씁니다. 도메인은 표준화의 실질적인 수단입니다.
문제 3. 도메인 정의에 포함되기 어려운 항목은?
도메인은 값에 대한 규칙입니다. 화면 배치는 응용 설계의 영역이라 도메인과 층이 다릅니다.
문제 4. 속성 이름을 지을 때의 원칙으로 보기 어려운 것은?
접두어를 붙일지는 표준의 선택이지 보편 원칙이 아닙니다. 사원 엔터티의 이름 속성을 사원이름이라 부를 필요는 없습니다.
문제 5. 속성 이름에 여부라는 말을 붙일 때 함께 정해야 할 것으로 가장 알맞은 것은?
여부 속성은 값이 두 가지뿐인 대신 표현이 제각각이기 쉽습니다. 와이와 엔인지 일과 영인지를 도메인으로 통일해 두지 않으면 시스템마다 달라집니다.
문제 6. 다음 중 속성의 값이 아니라 엔터티의 상태를 나타내는 속성으로 볼 수 있는 것은?
상태 속성은 인스턴스가 지금 어느 단계에 있는지를 나타냅니다. 값의 목록을 도메인으로 고정해 두어야 상태 전이를 검증할 수 있습니다.
문제 7. 속성 정의서를 작성할 때 가장 중요한 항목은?
이름만으로는 뜻이 갈립니다. 등록일이 신청한 날인지 승인된 날인지는 정의 문장이 있어야 정해집니다.
문제 8. 두 시스템에서 같은 이름의 속성이 서로 다른 뜻으로 쓰이고 있을 때 가장 알맞은 조치는?
같은 이름이 다른 뜻으로 쓰이면 통합이나 집계에서 반드시 사고가 납니다. 이름을 구분하고 정의를 명확히 적어 두는 것이 표준화의 기본입니다.
문제 9. 속성의 값이 NULL을 허용할지 정할 때 고려해야 할 것으로 가장 알맞은 것은?
필수와 선택은 업무 규칙에서 나옵니다. 없을 수 있는 값을 필수로 잡으면 억지 값이 들어가고, 반드시 있어야 할 값을 선택으로 두면 빈칸이 쌓입니다.
문제 10. 필수 속성으로 잡아야 할 값을 선택 속성으로 두었을 때 흔히 생기는 문제는?
비어 있을 수 있는 값은 모든 계산과 비교에서 예외 처리를 요구합니다. 업무상 반드시 있어야 하는 값이라면 처음부터 필수로 잡아야 합니다.
묶음 3
문제 1. 사원 엔터티에 연락처 속성을 하나 두고 휴대전화와 집전화를 섞어 저장하고 있습니다. 가장 알맞은 개선은?
한 속성에 성격이 다른 값이 섞이면 어떤 값이 무엇인지 알 수 없습니다. 종류가 더 늘어날 수 있다면 별도 엔터티가 유연합니다.
문제 2. 다음 중 파생 속성으로 보기 가장 알맞은 것은?
다른 속성으로 계산해 얻을 수 있는 값이 파생 속성입니다. 주문 금액은 단가와 수량이 있으면 언제든 다시 만들 수 있습니다.
문제 3. 파생 속성을 두지 않기로 결정했을 때 감수해야 하는 것은?
계산해 쓰면 값은 항상 정확하지만 매번 비용이 듭니다. 파생 속성은 그 비용과 불일치 위험을 맞바꾸는 선택입니다.
문제 4. 속성 하나가 시간에 따라 값이 바뀌고 그 변화를 모두 남겨야 한다면 가장 알맞은 설계는?
변화를 남기려면 시점이 식별자에 들어가야 합니다. 컬럼을 늘려 채우는 방식은 몇 번까지 바뀔지 모르는 순간 무너집니다.
문제 5. 코드 속성에 값의 뜻을 담아 자릿수마다 의미를 부여하는 이른바 유의미 코드의 위험으로 가장 알맞은 것은?
코드 안에 분류를 넣어 두면 편리하지만 분류가 늘어나는 순간 자리가 모자랍니다. 뜻은 별도 속성으로 두고 코드는 구분만 하게 두는 편이 오래갑니다.
문제 6. 속성의 도메인을 정하지 않고 개발을 시작했을 때 나타나는 대표적인 현상은?
날짜를 어디서는 여덟 자리 문자로, 어디서는 날짜형으로 저장하면 나중에 맞추는 데 큰 비용이 듭니다. 도메인은 이 비용을 미리 막습니다.
문제 7. 다음 중 속성 이름으로 가장 부적절한 것은?
데이터라는 이름은 무엇을 담는지 아무것도 알려 주지 않습니다. 속성 이름은 그 자체로 뜻이 읽혀야 합니다.
문제 8. 같은 도메인을 쓰는 속성끼리 반드시 같아야 하는 것은?
도메인은 값에 대한 약속이므로 형식과 범위가 같아야 합니다. 이름이나 인덱스는 속성마다 다를 수 있습니다.
문제 9. 속성을 정의할 때 업무 담당자에게 반드시 확인해야 할 질문으로 가장 알맞은 것은?
값이 없을 수 있는지는 업무만 아는 사실이고 모델의 필수 여부를 결정합니다. 나머지는 설계자가 판단할 수 있는 사항입니다.
문제 10. 속성 수가 지나치게 많은 엔터티를 발견했을 때 가장 먼저 검토할 것은?
속성이 많다는 것은 여러 집합이 한곳에 뭉쳐 있다는 신호일 때가 많습니다. 함수적 종속을 따라가 보면 분리할 자리가 보입니다.