중도에서 DB 책을 하나 업어왔다. 05년도에 나온 오래된 책인데 인터넷에서 추천받아서 구매했다. 약간 바이블 서적 같은 느낌인데 절판되어서 구하지도 못한다고
1장에서는 데이터모델링에 필요한 기본적인 개념들을 알아보려한다.
데이터모델링이란, "정보화 시스템을 구축하기 위해 어떤 데이터가 존재하는지 또는 업무에 필요한 정보는 무엇인지 분석하는 방법"을 말한다. 즉, 정보화시스템(대표적인 예시가 DB)에 들어갈 데이터를 분석 및 설계하여 정보화시스템을 구축하는 방법이다.
세상에 있는 모든 것을 분류하기
데이터모델링을 진행할 때 가장 중요한 세 가지 개념이 있는데,
1. 업무가 관여하고 저장하는 것 (Thing)
2. Thing 간의 관계 (Relationships)
3. Thing의 성격 (Attributes)
가 있다. 간단하게 회원저장 DB를 만들어서 "나이가 31살이고, 음악가가 직업인 윤마치" 회원이 새로이 회원가입을 했다고치면, "윤마치"가 Thing에 해당할 것이고, 나이나 직업 같은 것은 성격(Attributes)에 속할 것이다. 만약 "나이가 21살이고, 프로그래머가 직업이자 윤마치를 좋아하는 김철수" 회원이 회원가입을 진행했다면, "좋아하는"이 관계(Relationship)에 해당할 것이다.
즉, 데이터모델링에서 저장하려는 모든 것은 (사물, 사람 등) 어떤 것(Thing), 어떤 것 간의 관계, 어떤 것의 성격으로 분류할 수 있다.
용어정리
DB에 저장되는 원소의 집합을 타입(Type)이나 클래스(Class)라고하며, 각 구성 원소를 하나하나 나타내는 것을 어커런스(Occurance)나 인스턴스(Instance)라고 한다.
위의 데이터모델링 3요소를 타입 / 클래스 관점에서 보면
어떤 것은 엔티티타입
어떤 것 간의 관계는 관계
어떤 것의 성격은 속성 이라고 칭하며,
어커런스 / 인스턴스 관점에서 보면
어떤 것은 엔티티
어떤 것 간의 관계는 패어링
어떤 것의 성격은 속성값이라고 칭한다.
데이터모델링을하다보면 집합의 관계가 필수이므로, 따로 나타낸 것이다.
그리고 1장에서는 이 3요소에 대해서 알아보고, 여러 데이터 모델링에 필요한 사항을 추가적으로 알아볼 것이다.
엔티티타입 (Entity Type)
엔티티타입이란 "업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 것으로 영속적으로 존재하는 단위"라고 칭한다. 그러니까 DB에 저장되는 객체나 요소 한 개를 엔티티라고 칭한다. 그리고 엔티티타입은 그 엔티티들의 집합이다.
엔티티타입은 정보가 저장될 수 있는 사람, 장소, 물건 등에 해당한다. 즉, 회원가입 DB를 짠다고하면 김철수, 김영희 등의 회원객체가 엔티티가 되는 것이고, "회원"이라는 것이 엔티티타입이 되는 것이다.
그래서 엔티티타입이라는 것이 "어떤 정보를 저장할 것인가?"라는 것을 나타내게되므로, 데이터 모델링에서 굉장히 중요한 개념에 속한다. 따라서 몇 가지 성질들을 만족해야하며, 그렇지 못할 경우 부적절한 엔티티 타입일 가능성이 높다.
엔티티타입 성질1 - 반드시 시스템을 구축하고자하는 업무에서 필요하고 관리하고자 해야한다.
"환자"라는 엔티티타입은 의료시스템에서는 매우 중요한 정보지만, 일반적인 회원관리 시스템에서는 필수적인 요소가 아니다. 따라서 시스템 구축 대상인 업무에서 반드시 필요하고, 관리하고자해야하는 것을 잘 알아야한다.
엔티티타입 성질2 - 유일한 식별자 (Unique Identifier)에 의해 식별이 가능해야한다.
동일한 엔티티타입에 속하는 서로 다른 엔티티들은 서로 다른 식별자를 가지고 있어야한다. 만약, 이름을 식별자로 사용하는 회원가입 DB에 "김철수"라는 회원이 두 명 등록되어있다면, 김철수 회원을 불러오려고해도 누구를 불러오는지 알 수 없다. 즉, 각각의 엔티티가 식별자에 의해 한 개씩만 존재하는지 검증해야한다.
엔티티타입 성질3 - 영속적으로 존재하는 엔티티 집합이 되어야한다.
엔티티타입을 엔티티들의 집합이라고 했다. 여기서 조건이 하나 더 붙는데, "두 개 이상"의 엔티티들의 집합이다. 즉, 하나의 엔티티타입이 한 개의 엔티티를 가진다면, 그 엔티티타입은 의미없는 엔티티타입이 된다. 적절한 엔티티타입을 구축하기 위해서는 엔티티가 여러 개인 엔티티타입을 설계해야한다.
엔티티타입 성질4 - 업무 프로세스는 그 엔티티타입을 반드시 이용해야한다.
이것이 당연한 얘기일 수도 있는데, 그냥 두면 문제가 생길 수 있다. (뒷장에서 다룸) 고립된 엔티티타입은 제거하거나 누락된 프로세스가 있는지 검토해야한다.
엔티티타입 성질5 - 엔티티타입에는 반드시 속성(Attributes)이 포함되어야한다.
엔티티의 이름만 있고 속성이 없는 경우에는 관계가 생략되었거나 속성정보가 누락된 경우에 해당한다.
예를들면, 회원이라는 엔티티타입에는 각 회원마다 가질 수 있는 속성인 이름, 아이디, 비밀번호, 나이 등의 속성값이 존재하므로 이 조건을 충족시키지만, 날씨라는 엔티티타입에는 각 날씨마다 가질 수 있는 속성이 없다. 따라서 엔티티의 이름만 나열되게되므로 의미없는 엔티티타입이 된다.
엔티티타입 성질6 - 엔티티타입은 다른 엔티티타입과 최소 한 개 이상의 관계가 있어야한다.
간혹 다른 엔티티타입과 관계가 없는, 고립된 엔티티타입이 있는데, 보통 통계업무에만 사용되는 통계용 엔티티타입이나 과목코드와 같은 코드와 같은 경우에는 다른 엔티티타입들이 코드를 많이 사용하므로 하나의 코드라는 엔티티타입을 만든 후에 관리하는 경우가 생긴다. 그래서 일반적으로 관계가 생략되는 경우가 있다.
위와 같은 특수한 경우를 제외하고는 엔티티타입은 다른 엔티티타입과의 관계가 생긴다.
이처럼 엔티티타입은 여러 성질을 충족시켜야 잘 설계된 엔티티타입이라 칭할 수 있다. 이외에도 약어를 사용하지 않고, 단수 명사를 사용하며, 유일한 이름을 사용해야한다, 엔티티타입이 왜 생성되는 판단하여 그 이름을 붙여주는 명명법이 존재한다.
물론 이것을 체크리스트마냥 매번 판단하기보다는, 프로젝트를 기획하면서 DB설계를 한 후에 참고해가며 관계를 조금씩 수정해가는 용도로 사용할 것이 적절해보인다. 너무 DB에 매몰되다보면 또 프로젝트가 진행이 안되니까
속성 (Attributes)
속성은 "업무에서 필요한 엔티티에서 관리하고자하는, 더 이상 분리되지 않는 최소의 데이터 단위"라고 칭한다. 각각의 엔티티들이 공통적으로 나눠가지는 데이터를 속성이라한다. 회원DB에서 각 회원(엔티티)이 가지는 이름, 나이, 아이디, 비밀번호 등의 더 이상 분리되지 않는 데이터 단위를 속성이라 칭한다.
데이터모델링 분석단계에서 여러 엔티티들이 가지는 동일한 성격이 무엇인지 판단하고, 이에 이름을 부여하여 속성을 만들어낼 수 있다. 일반적으로 하나의 속성에 대한 속성값은 단 한 개만 사용할 수 있다. 또한, 한 개의 엔티티는 두 개 이상의 속성을 가진다.
속성의 분류
기본
위처럼 업무분석을 통해 정의된 속성을 기본속성(Basic Attribute), 업무분석을 통해서 정의되지는 않았으나 설계과정에서 도출되는 속성을 설계속성(Designed Attribute)라고 칭한다. 업무분석과 설계과정의 차이는, 업무분석은 시스템 설계 이전부터 존재하던 나이, 이름고 같은 속성을, 설계속성은 시스템 설계과정에서 업무효율을 위해 만든 회원번호, 비밀번호 등의 인위적인 속성이다. 물론 그런게 있다고만 알고 엄격히 구분하지는 말자
또 다른 속성의 계산으로부터 얻어지는 속성을 파생속성 (Derived Attribute)라고 칭한다. 주문DB에서 최종결제값에 해당하는 것이 파생속성이라할 수 있겠다. 다른 속성의 영향을 받기 때문에 되도록 적게 정의하는 것이 좋다.
엔티티 구성방식
엔티티를 식별할 수 있는 식별자로 사용되는 속성을 PK(Primary Key), 다른 엔티티와의 관계에서 포함된 속성을 FK(Foreign Key), 속성이지만 PK와 FK에도 속하지 않는 속성을 일반속성이라 칭한다.
이러한 속성명은 클라이언트측에게 직접적으로 나타자기 때문에 속성명을 정확히 부여하고 혼란을 줄여야한다.
현업에서 사용하며, 서술식이나 약어는 자제하고, 엔티티타입에서 유일하게 식별가능한 것을 속성명으로 사용해야한다. 물론 유일하지 않아도되지만, 나중에 헷갈린다.
식별자
식별자는 엔티티타입에서 한 개의 엔티티를 구분할 수 있는 것이다. 엔티티타입에서 속성으로 존재하며, 위에서 말한 PK가 식별자의 기능을한다.
중요한 성질로는 반드시 유일해야하며, 변해서는 안된다.
주식별자/보조식별자
주식별자와 보조식별자 모두 식별자의 기능을 수행한다. 주식별자는 각 엔티티를 식별하게해주는 유일한 식별자, 보조식별자는 주식별자를 대신하여 보조적으로 식별의 기능을 수행한다. 보조식별자는 여러 개가 될 수 있다. 실제 테이블에서 주식별자는 PK, 보조식별자는 유니크 인덱스 (Unique Index)로 지정된다.
식별자를 사용할 수 있는 자원이 여러 개이지만, 주식별자가로 DB검색순회를 돌기엔 자원이 너무 많이들거나, 식별자로 사용하기 좋으나 DB가 누출될 경우 문제가 큰 경우 (주민번호 등)에는 보조식별자로 사용하며, 회원번호 같이 누출되어도 큰 문제가 없거나 검색도 단순한 속성을 주식별자로 내세우는 편이다.
내부 식별자/외부 식별자
내부식별자는 회원번호, 사원번호, 주문번호 등과 같이 타 엔티티타입으로부터 식별자를 가져오기 않고 스스로 생성되는 식별자를 뜻한다. 외부식별자는 다른 엔티티타입에서 주식별자 속성을 받아서 생성된다. 즉, 외부에 의해 생성된다. 외부식별자에서 식별자는 PK이나 FK에 해당한다.
단일 식별자/복합 식별자
단일 식별자는 한 개의 속성으로만 식별자를 사용하는 경우고, 복합 식별자는 여러 개의 속성으로 식별자를 구성하는 경우를 뜻한다. 주문목록 엔티티타입 같이 주문번호와 제품번호 속성을 이용해서 식별자 역할을하면 복합 식별자라고 칭한다.
원조 식별자/대리 식별자
주식별자가 복합 식별자일 경우에는 여러 속성을 묶어 하나의 속성으로 사용하는 경우가 있다. 이러한 특성을 대리 식별자라고한다. 예를들면 주문과정에서 사업소코드, 주문일자, 일련번호 세 가지를 복합 식별자인 주식별자로 사용했다면, 이걸 하나의 묶어서 "주문번호"로 설정한 뒤에 주식별자로 삼으면 이것이 대리 식별자가 되는 것이다.
또는 주식별자 속성들을 일반속성으로 내리고, 일련번호 형태를 사용하는 경우도 있는데, 이 경우 일련번호가 대리 식별자가 된다. 프로젝트에서는 위 두 가지 경우가 가장 자주 나온다.
비슷한 예시로는 회원DB를 만질 때 회원아이디, 비밀번호는 일반속성으로 내리고 회원번호를 주식별자로하면 그게 대리식별자가 된다.
관계
관계는 두 엔티티 간의 논리적 관계를 뜻한다. 엔티티와 엔티티가 서로에게 행위 또는 존재로서 서로에게 영향을 주는 경우이다. 각각의 엔티티들은 자신과 관련된 엔티티들과 관계의 어커런스로 참여하는 형태를 관계 페어링이라한다.
여기서 어커런스란 실제 데이터 한 개를 뜻한다. 즉, 엔티티와 엔티티 간 관계가 설정된 실제 데이터(어커런스)를 관계 페어링이라고한다. 내가 맥도날드에서 1955버거를 시킬 때, 내 회원정보와 1955버거의 주문정보가 (행위에 의한) 관계를 생성하게 되는데, 이를 관계 페어링이라고 칭한다.
카디낼리티 (Cardinality)
두 개의 엔티티타입간 관계에서 참여자의 수를 표기하는 것을 뜻한다. 일반적인 방식은 1:M (일대다), 1:1(일대일), M:N (다대다)이다.
1:1 (One To One)
각각의 엔티티는 서로에 대해서 단지 하나의 관계만을 가진다. 국가DB가 있고 국가원수 DB가 있을 때, 국가DB와 국가원수DB는 서로 관계를 형성하고, 이때 각 국가엔티티에는 하나의 국가원수엔티티를 가지므로 1:1 관계. 엔티티타입의 한 엔티티가 다른 엔티티타입의 엔티티에 하나씩 매핑되는 형태다.
카디낼리티는 엔티티 간 실선을 긋고, 각 참여자 앞에 세로로 실선을 짧게 그으면 된다. 위 그림에서 맨 위
1:M (One To Many)
한 엔티티타입의 엔티티는 하나 이상의 다른 엔티티타입의 엔티티와 관계를 형성한다. 하나의 부서에는 여러 사원들이 있는데, 부서 엔티티타입과 사원 엔티티타입이 일대다 관계를 형성한다.
카디낼리티는 엔티티간 실선을 긋고, M에 해당하는 엔티티타입에 삼발이를 그려주면 된다. 위 그림에서 두 번째
M:N (Many To Many)
각각의 엔티티에는 관계를 맺는 다른 엔티티타입의 엔티티에 대해 하나 이상의 수와 관계가 있다. 즉, 여러 엔티티들이 서로 다른 여러 엔티티들과 관계를 형성한다. 주문DB에는 상품이 여러 개 들어올 수 있지만, 반대로 상품DB의 상품들도 여러 주문에 들어갈 수 있다. 다대다 관계.
이 그림을 보면 이해가 더 빠를듯하다.
일대일 관계에서는 하나의 엔티티에 하나의 엔티티만 매핑되고, 일대다 관계에서는 하나의 엔티티에 여러 엔티티가, 다대다 관계에서는 여러 엔티티에 여러 엔티티가 매핑된다.
카디낼리티는 엔티티양쪽에 일대다 관계에서 '다'에 해당하는 삼발이를 그려주면 된다.
관계 참여하기
주문서에는 반드시 주문목록이 있어야한다. 주문목록이 없는 주문서는 무의미하기 때문이다. 이처럼 관계에 참여하는 모든 엔티티 (참여자)들이 반드시 타 엔티티타입의 엔티티(참여자)와 연결되어야하는 경우를 필수참여(Mandatory Membership)이라고한다.
반대로, 수강신청의 경우 수강과 학생의 관계에서, 모든학생이 해당 수업을 수강하지 않을 수 있다. (곧 폐강되겠지만) 이처럼 관계에 참여하는 모든 엔티티가 반드시 타 엔티티와 연결되지 않아도 되는 경우를 선택참여(Optional Membership)이라고한다. ERD에서 선택참여관계는 선택참여하는 쪽을 원으로 표시한다. 위의 예시를 들면 학생이 참여하게되므로 학생이 동글뱅이 표시를 받게된다.
만약 양쪽 엔티티타입에 모두 선택참여가 되어있다면 그 관계는 잘못된 관계일 가능성이 높다.
이쪽이 좀 헷갈려서 좀만 더 생각해보자면,
두 엔티티타입이 관계를 맺을 때, 어떤 엔티티타입의 모든 엔티티들(인스턴스)이 반드시 관계를 맺어야하는 경우를 필수참여,
관계를 맺지 않는 엔티티가 있어도 되는 경우를 선택참여라고한다.
주문-고객 관계에서 주문은 고객이 없다면 일어날 수 없다. 결제 역시 주문이 없다면 일어날 수 없다. 댓글은 게시글 없이는 일어날 수 없다. 이처럼 특정 엔티티타입의 엔티티가 존재하기 위해서는 다른 엔티티타입과 관계를 형성하는 것이 강제되는 경우가 있는데, 이럴 때 주문 / 결제 / 댓글은(관계가 강제되는 엔티티타입) 고객 / 주문 / 게시글에 필수참여를 한다고한다.
반대로, 고객이 주문없이 그냥 가게를 나갈 수 있고, 주문이 굳이 결제까지 도달하지 않는 경우도 있고, 댓글이 없는 게시글도 있을 수 있다. 이처럼 특정 엔티티타입의 엔티티가 관계를 형성하는 다른 엔티티타입의 존재가 없어도 독자적으로 존재할 수 있는 경우가 있는데, 이럴 때 고객 / 주문 / 게시글은 (관계가 강제되지 않는 엔티티타입) 선택참여한다고 한다. ERD를 그릴 때에는 선택참여하는 쪽에 원을 그린다.
ER모델에서 선택참여 중인 엔티티는 DB에서 FK가 NULL일 수 있다. DB에서 "관계"라는 것은 FK를 통해 이루어진다. 주문과 고객이 관계를 형성하면 각 주문에는 누구의 주문인지 확인하기 위해 고객의 FK가, 각 고객은 어떤 주문을 가지고 있는지 확인하기 위해 주문의 FK가 생성되는 것처럼.
여기서 선택참여 중인 엔티티는 관계에 참여 중이지 않을 수 있다. 고객이 주문을 하지 않은 경우처럼. 이럴 경우 FK는 NULL을 나타내게된다. 만약 실수로 선택참여인 관계를 필수참여로 지정하게되면, 데이터 발생 시 FK의 설정까지 한 개의 트랜잭션에서 관리되어야한다. 예를들면, 고객의 생성되면 반드시 주문까지 생성하고 이것을 하나의 트랜잭션으로 관리한다는 소리. 따라서 필수참여와 선택참여의 여부는 반드시 고려되어야한다.
관계의 종류
1. 정상관계 (Normal Relationship)
엔티티타입과 엔티티타입이 독립적으로 분리되고 상호 간 한 가지 관계만 성립한다. 여기서 "독립"은 고유의 PK가 있고, 다른 엔티티가 없어도 개념적정의가 가능한 엔티티로, 위의 필수참여에서 "다른 엔티티타입의 존재가 없어도 독자적으로 존재할 수 없는 경우"의 "독립"과는 다른 개념이다. 따라서 필수참여도 정상관계에 해당한다.
2. 자기참조 (Self relationship, Recursive Relationship)
하나의 엔티티타입 내에서 엔티티와 엔티티가 관계를 맺는 중이다. 대표적인 예시가 부품. 컴퓨터의 부품은 키보드, 마우스, 본체가 있고 키보드의 부품은 기판, 마우스의 부품은 휠, 본체의 부품은 CPU 등이 있다. 이처럼 같은 "부품"이라는 동일한 엔티티타입이지만 서로 계층적인 구조를 가지고 있을 때 자기참조관계로 표현한다.
3. 병렬 (Parallel)
엔티티타입과 엔티티타입이 독립적으로 분리되면서 두 개 이상의 관계가 상호간에 존재한다. 은행업무에서 고객-계약 엔티티타입 간 관계를 생성할 때, 고객이 예금 계약과 대출 계약을 맺으면 두 개의 엔티티타입에서 두 개의 관계를 형성하게된다.
4. 슈퍼타입 서브타입 (Super-Type Sub-Type): 슈퍼타입과 서브타입을 다룬 후에 할 예정. 곧 나온다. 이 글에서는 아님. 끝나고 링크 달 예정
5. 주식별자/비식별자 (Identifying / Non-Identifying)
부모 엔티티타입의 주식별자가 자식 엔티티타입의 주식별자로 상속되는 주식별자 관계, 부모 엔티티타입의 주식별자가 자식 엔티티타입의 일반 속성으로 상속되는 비식별자 관계로 나뉜다.
이외에도 여러 관계들이 있는데, 이것은 2장에서 다룰 예정이다.
또한, 관계를 매번 생각해야하고, 이를 고려하면서 ERD를 짜야하는데, 이 역시도 설계 및 모델링 과정에서 다룰 예정이다.
'CS > 데이터베이스' 카테고리의 다른 글
| [DB] 정규화 (1) | 2026.05.14 |
|---|---|
| [DB] 기초데이터베이스 개념 간단정리 (0) | 2026.05.13 |
| [백엔드] JDBC에서 스프링 JPA까지, 그리고 영속성 (0) | 2026.03.24 |