관계형 데이터 모델링 노트 1장

엔터티만 명확하게 정의하면 모델링의 많은 문제는 해결

여러 데이터가 혼합된 형태의 엔터티는 엔터티가 아니라 뷰로 사용

주 식별자가 존재하도록 엔터티 설계

같은 성격의 데이터는 전사적으로 유일하게

하나의 엔터티에 서로 다른 성격의 데이터를 혼용해서는 안됨

엔터티는 보통 다른 엔터티와 관계가 존재하는 것이 일반적이므로 관계가 존재하지 않으면 그 엔터티의 성격을 다시 확인

프로세스에 따라 변하는 상태를 엔터티로 설계하거나, 특정 프로세스를 처리하기 위한 화면에 따라 엔터티를 설계하면 안됨

엔터티와 프로세스는 별개

하나의 화면에 하나의 엔터티를 매핑해서 설계하는 것은 지양할 것

데이터베이스에서 관리하려는 데이터를 엔터티로 설계하며, 설계 했더라도 사용하지 않는다면 삭제

일정한 약속을 정해 준수할 것

구체적(Specific)

일반적(General)

생략해도 의미가 통하는 단어는 생략

중복 의미를 나타내는 단어가 사용되지 않도록 주의

엔터티 명에 '~등록', '~처리' 등과 같이 프로세스(업무)를 표현하는 것은 바람직하지 않음

엔터티 명은 명사형으로 사용하는 것이 일반적

형용사형을 사용하여 설명하는 식의 엔터티명은 함축적이지 않으며 직관적이지 않음

엔터티 명은 가독성에 문제가 되지 않고 성격을 파악할 수 있는 정도 내에서 띄어쓰기를 하지 않고 명명

속성 명을 컬럼 명으로 자동 전환하는 것과 달리 엔터티 명은 테이블 명으로 자동 전환하지 않아야 함

엔터티 정의가 바뀌는 것은 바람직 하지 않지만, 엔터티 명은 생각보다 자주 바뀜

엔터티 명은 빈번하게 변경되지만, 테이블 명은 변경할 이유가 없다는 점을 염두에 두고 원칙을 정의

테이블 명과 마찬가지로 엔터티 명은 전 영역에서 중복돼서는 안됨

엔터티 명에 특수 문자는 사용하지 않는 것이 원칙이지만 '_', '/', '( )', '[ ]' 등은 사용가능

실체 엔터티에 대한 명명법의 핵심은 엔터티 명이 명사로 끝나는 것

명사로 끝나도록 정하는 것은 적합하지 않음

엔터티 명에 '~했음’이나 '~한 데이터’를 붙여보았을 때 자연스러운 문장이 되면 행위 엔터티에 대한 명명으로 적합

교차 엔터티의 명명법은 관계의 명명법과 연관됨

다대다(M:M) 관계의 관계 명은 교차 엔터티 명과 유사

집계 기준은 앞쪽에, 대상(무엇을 집계했는지)은 뒤쪽에 위치하는 것이 좋음

구체화 할것인지 일반화 할것인지 판단

서브타입 엔터티 명은 슈퍼타입 엔터티에 수식어를 붙이는 형식으로 사용

유사한 속성을 분리할 때

덜 사용되는 속성을 분리할 때

프로세스를 표현한 결과를 나타낼 때

논리 모델이 완료된 시점에 검증하는 것이 좋으며, 리더가 일관되게 검증

모델에 표현된 불필요한 엔터티가 있는지?

모델에 표현되지 않은 엔터티가 있는지?

엔터티를 설계할 때 간혹 속성으로 설계해야 하는데, 엔터티로 설계하는 경우가 있으니 주의

한 엔터티에 여러 성격의 데이터가 혼재돼서는 안되며, 엔터티는 동일한 성격의 집합으로 구성되어야 함

유사한 데이터가 여러 엔터티에 존재하는 것은 특별한 이득이 없으므로 엔터티 통합을 기본 원칙으로 검증

유사한 구조가 반복된다면 좀 더 일반화하여 통합

필요한 단어만을 사용해서 구체적으로 붙여야함

엔터티 명을 보고 어떤 데이터를 관리하는 엔터티인지를 알 수 있도록 가능한 구체적이어야 함

반대로 확장할 수 있는 집합인데도 불구하고 구체적으로 붙이는 것은 바람직하지 않음

엔터티 명에 필요 없는 단어는 생략

서브타입 엔터티 명은 슈퍼타입 엔터티 명을 차용해야 함

엔터티 명은 주 식별자와 한 쌍처럼 잘 어울려야 함

어울리지 않을 경우 단순히 가독성 측면에서만 문제가 되는 것이 아니라 간혹 둘 중의 하나를 잘못 설계했을 수도 있음

엔터티 설명은 반드시 기술하는 것이 원칙

설명이 누락된 엔터티를 뽑아서 설명을 채워야함

모델러는 엔터티 명과 설명만을 보고도 해당 엔터티를 충분히 설명할 수 있어야함

모든 엔터티에 업무 식별자가 존재하는지를 검토

업무 식별자는 CASE 툴에서 관리하지 않기 때문에 표준 형식을 정해서 관리

엔터티 명이 '~이력’으로 끝나는지 검토

하위(자식) 엔터티가 많다면 종료일자 속성을 주 식별자에 포함하지 말 것

일대일(1:1) 관계만을 뽑아서 두 엔터티의 성격이 같은지 확인

성능, 관리 상의 문제가 없다면 합체할 것을 고려

종속 관계인 엔터티는 동일한 주제 영역에 존재해야함

종속 엔터티는 일반적으로 주 식별자를 식별자로서 상속

인스턴스가 하나뿐인 엔터티는 흔치 않으므로, 반드시 잘못된 것은 아니지만 재차 확인해볼 필요가 있음

주 식별자가 없다고 반드시 잘못된 엔터티는 아니지만, 주 식별자가 없는 엔터티를 뽑아서 다시 검토해야함

일대일(1:1) 관계나 슈퍼타입, 서브타입 관계 등을 제외하고, 엔터티의 주 식별자가 같은 엔터티는 주 식별자를 검토해 볼 필요가 있음

모델러는 스스로 설계한 엔터티와 속성을 쉽게 설명할 수 있어야함

외부 엔터티나 복제 엔터티는 원천 엔터티와 엔터티 명과 주 식별자가 동일해야함

데이터 성격에 맞는 정체성이 뚜렷한 엔터티를 설계하는 것은 데이터 모델 설계의 중요한 원칙

유사한 성격의 데이터는 통합하는 것이 데이터 모델링의 주요 원칙

확장하기 수월한 모델으로 데이터를 통합할수록 모델은 유연해짐

데이터에 결점이 없는 상태

가독성이 좋도록 모델을 설계

업무 요건에 맞는 모델을 설계하는 것

업무 식별자를 제대로 도출하여 엔터티를 분명히 설계

업무 프로세스에 맞게 관계선을 표현

성능이 좋도록 모델을 설계하는 것

ERD가 제대로 관리될 수 있도록 설계하는 것

표준화 원칙을 따라 동일한 용어를 사용하도록 설계하는 것

향후에 사용되지 않을 수도 있다는 것을 고려해서 설계하며, 주믄등록번호 같은 암호화 대상 속성을 주 식별자로 사용하면 안됨

엔터티에 존재하는 모든 인스턴스는 고유해야 하며, 널 값을 가지면 안 된다는 것이 엔터티 무결성

한 엔터티에는 동일한 주 식별자 값이 존재할 수 없으며, 주 식별자 속성은 모르는 값인 널 값을 허용할 수 없음

엔터티 무결성을 만족하기 위해선 주 식별자에 PK(Primary Key)를 생성하고, 업무 식별자에 유니크 인덱스(Unique Index)를 생성

연관된 인스턴스 간의 일관성을 유지하기 위한 제약

엔터티의 외래 식별자 속성 값은 참조되는 엔터티의 주 식별자 값과 일치하거나 널 값이어야 한다는 것

참조 무결성은 FK(Foreign Key) 제약으로 지켜짐

도메인 무결성은 속성과 관련된 제약

도메인 무결성은 데이터 타입(Data Type)과 기본 값(Default) 제약, 널(Null) 제약, 체크(Check) 제약 등을 지킬 수 있음

업무 무결성은 기업에서 업무를 수행하는 방법이나 데이터를 처리하는 규칙을 의미

업무 무결성을 지키기 위해 지침을 제시하여 논리적으로 지키게 하는 방법이 있고, 데이터베이스 제약을 사용하여 강제적으로 지키게 하는 방법이 있음