[SQLD] 1과목 1장 데이터 모델링의 이해 요약 (엔터티~식별자 / 2024 개정사항 반영)

※ 이전글 : 2023.02.21 - [Cerificate/SQLD] - [SQLD] 1과목 1장 데이터 모델링의 이해 요약 (데이터 모델의 이해 / 2024 개정사항 반영)

 

 

Index

 

  SQLD 시험에 10문제 나오는 1과목에 이 정도 정성을 쏟아야 하는 의문이 들기도 하지만, 기초가 부실하면 나중에 큰 위기가 닥칠 수 있음을 명심하며 더 세심하게 이론 부분을 다루고자 한다. 이전글에서도 설계가 잘못될 경우, 이후 트랜잭션에 막대한 피해를 줄 수 있다는 것을 배웠지 않는가. 배움에 있어선 아무리 고지식해도 모자르다는 것이 필자의 생각이다. 자, 그럼 새로운 챕터로 들어가보도록 하자. 오늘도 역시 Data On Air에 신세를...

  지난 글과 마찬가지로 2024 개정에 따른 이기적 강의 내용을 반영하여 보라색으로 표시하였다.

과목 1. 데이터 모델링의 이해 - 이론

1장 데이터 모델링의 이해

2절 엔터티

1. 엔터티의 개념

• 엔터티 (Entity, 엔티티라고도 함.)는 실체, 객체라고도 표현됨. 본 글에서는 노랭이 문제집에 적힌 대로 엔터티로 통일.
• 전문가들의 정의는 다음과 같다.
  • Peter Chen (1976), "변별할 수 있는 사물"
  • C.J Date (1986), "데이터베이스 내에서 변별 가능한 객체"
  • James Martin (1989), "정보를 저장할 수 있는 어떤 것"
  • Thomas Bruce (1992), "정보가 저장될 수 있는 사람, 장소, 물건, 사건 그리고 개념 등"
• 상기 내용을 요약하면, 엔터티란 "업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것 (Thing)"
• 엔터티: 필요한 정보를 저장 또는 관리하기 위한 집합적인 명사 개념.
• 눈에 보이지 않는 것도 포함됨.

2. 엔터티와 인스턴스의 표기

• 엔터티는 대체로 사각형으로 그려짐.

엔터티와 인스턴스 (Data On Air)

 

엔터티 표기법 (Data On Air)

3. 엔터티의 특징

• 해당 업무에서 필요하고 관리하고자 하는 정보 
• 유일한 식별자 (Unique Identifier)로 식별 가능
• 영속적으로 존재하는 복수의 인스턴스 집합
• 업무 프로세스에 의해 이용되어야 함.
• 반드시 속성이 있어야 함. (2개 이상)
• 다른 엔터티와 최소 한 개 이상의 관계

4. 엔터티의 분류

• 1) 유무형에 따른 분류
  • 유형 엔터티 (Tangible Entity) : 물리적인 형태가 있고 안정적. 지속적으로 활용됨. ex) 사원, 물품, 강사 등
  • 개념 엔터티 (Conceptual Entity) : 물리적인 형태는 존재하지 않고 관리해야 할 개념적 정보로 구분. ex) 조직, 보험상품 등
  • 사건 엔터티 (Event Entity) : 업무를 수행함에 따라 발생되는 엔터티. 비교적 발생량이 많음. 각종 통계자료에 이용됨. ex) 주문, 청구, 미납 등
• 2) 발생 시점에 따른 분류
  • 기본엔터티 : 그 업무에 원래 존재하는 정보. 독립적으로 생성 가능. 타 엔터티의 부모 역할. 다른 엔터티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 지님. ex) 사원, 부서, 고객, 상품, 자재 등
  • 중심엔터티 : 기본엔터티로부터 발생되고 그 업무에 있어서 중심적인 역할. 데이터의 양이 많이 발생되고 다른 엔터티와의 관계를 통해 많은 행위엔터티를 생성. ex) 계약, 사고, 예금원장, 청구, 주문, 매출 등
  • 행위엔터티 : 두 개 이상의 부모엔터티로부터 발생. 자주 내용이 바뀌거나 데이터량이 증가함. 분석초기 단계에서는 잘 나타나지 않고 상세 설계단계나 상관모델링을 진행하며 도출될 수 있음. ex) 주문목록, 사원변경이력 등
• 이외, 엔터티가 스스로 생성될 수 있는지 여부에 따라 독립엔터티 or 의존엔터티 구분

5. 엔터티의 명명

• 현업에서 사용하는 용어 사용
• 약어 사용 금지
• 단수명사 사용
• 모든 엔터티에 고유 이름 부여
• 엔터티 생성 의미대로 이름 부여

3절 속성

1. 속성의 개념

• 사전적 정의 : 사물(事物)의 성질, 특징 또는 본질적인 성질, 그것이 없다면 실체를 생각할 수 없는 것.
• 데이터 모델링 관점 :  “업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위”

2. 엔터티, 인스턴스&속성, 속성값의 내용과 표기

• 1) 엔터티, 인스턴스, 속성, 속성값의 관계
  • 엔터티에는 두 개 이상의 인스턴스가 존재. 각 엔터티는 고유 성격을 표현하는 속성정보를 두 개 이상 지님.
  • 속성 : 엔터티에 속한 인스턴스들의 성격을 구체적으로 나타내는 항목. 각 인스턴스는 속성의 집합으로 설명됨.
  • 하나의 속성은 하나의 인스턴스에만 존재할 수 있다
  • 속성은 엔터티에 속한 엔터티에 대한 자세하고 구체적인 정보를 표현. 각각의 속성은 구체적인 값 (속성 값)을 가짐.
  • 정리하자면!
  • 한 개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 한다.
  • 한 개의 엔터티는 두 개 이상의 속성을 갖는다.
  • 한 개의 속성은 한 개의 속성값을 갖는다.

속성 표기 (Data On Air)

 

• 2) 속성 표기법 : 엔터티 내에 이름을 포함하여 기술. 

속성 표기법 (Data On Air)

3. 속성의 특징

• 엔터티와 동일하게 반드시 해당 업무에서 필요하고 관리하고자 하는 정보.
• 정규화 이론에 기반하여 정해진 주식별자에 함수적 종속성을 가져야 함.
• 하나의 속성에는 한 개의 값만을 가짐. 하나의 속성에 여러 개의 값이 있는 다중값일 경우 별도의 엔터티로 분리.

4. 속성의 분류

• 1) 특성에 따른 분류
  • 기본 속성 : 업무로부터 추출한 모든 속성. 가장 일반적이고 많음. 업무상 코드로 정의한 속성은 속성값이 원래 속성을 나타내지 못하므로 기본속성이 되지 못함.
  • 설계 속성 : 업무상 필요한 데이터 외에 데이터 모델링을 위해 업무를 규칙화하고자 속성을 새로 만들거나 변형하여 정의하는 속성. 일반적으로 코드성 속성은 원래 속성을 업무상 필요에 의해 변형하여 만든 설계속성. ex) 일련번호
  • 파생 속성 : 다른 속성에 영향을 받아 발생하는 속성. 보통 계산된 값들이 해당됨. 다른 속성에 영향을 받기에 프로세스 설계 시, 데이터 정합성을 유지하기 위해 유의해야 할 점이 많으므로 파생속성을 적게 정의하는 것을 권장.

속성 특성에 따른 분류 (Data On Air)

• 2) 엔터티 구성방식에 따른 분류
  • PK (Primary Key) 속성 : 엔터티를 식별할 수 있는 속성
  • FK (Foreign Key) 속성 : 다른 엔터티와의 관계에서 포함된 속성. 
  • 일반속성 : 엔터티에 포함되어 있으나 PK, FK에 포함되지 않은 속성.

구성방식에 따른 분류 (Data On Air)

• 이외, 세부 의미를 나눌 수 있는지에 따라 단순형 혹은 복합형으로 분류. 또, 동일한 성질의 여러 개의 값이 나타나는지에 따라 단일값과 다중값 속성으로 나눔.

5. 도메인

• 각 속성이 가질 수 있는 값의 정의 및 범위
• 엔터티 내에서 속성에 대한 데이터타입과 크기 그리고 제약사항을 지정하는 것.

6. 속성의 명명

• C/S(Client/Server) 환경, Web 환경에서 속성명이 사용자 인터페이스(User Interface)에 드러나기 때문에 업무와 직결.
• 따라서, 용어의 혼란을 없애기 위해 용어사전이라는 업무사전을 프로젝트에 사용.
• 속성명 부여 원칙
  • 현업에서 사용하는 이름 부여.
  • 서술식의 속성명 사용 금지.
  • 약어 사용 자제.
  • 모든 속성의 이름을 중복되지 않게 작성.

 

4절 관계

1. 관계의 개념

• 1) 관계의 정의
  • 사전적 정의 : 상호 연관성이 있는 상태.
  • 데이터 모델 정의 : “엔터티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태로서나 행위로서 서로에게 연관성이 부여된 상태”
• 2) 관계의 패어링
  • 패어링 (paring) : 엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것. (패어링? 페어링?)
  • 개별 인스턴스가 다른 종류의 관계를 맺고 있다면 두 엔터티 사이에 두 개 이상의 관계가 형성될 수 있음.
  • 엔터티는 인스턴스의 집합을 논리적으로 표현 | 관계는 관계 패어링의 집합을 논리적으로 표현.

관계 패어링 (Data On Air)

2. 관계의 분류

• 존재에 의한 관계 ex) 소속
• 행위에 의한 관계 ex) 주문한다.
• UML (Unified Modeling Language)
  • 연관관계 (Association) : 항상 이용하는 관계. 존재적 관계. 실선으로 표현. 소스코드에서 멤버변수로 선언.
  • 의존관계 (Dependency) : 상대방 클래스의 행위에 의해 관계가 형성. 점선으로 표현. 행위를 나타내는 코드인 Operation (Method)에서 파라미터 등으로 이용.

3. 관계의 표기법

• 관계명 (Membership) 
  • 관계의 이름. 엔터티가 관계에 참여하는 형태를 지칭.
  • 각각의 관계는 두 개의 관계명을 가지고, 각 관계명에 의해 두 가지의 관점으로 표현될 수 있음.
  • 명명규칙
    • 모호한 동사 자제.
    • 현재형 동사.

관계명 (Data On Air)

• 관계차수 (Cardinality) 
  • 정의 : 두 엔터티 사이의 관계에서 참여자 (인스턴스)의 수를 나타낸 것.
  • 1:1, 1:M, M:N이 있음. (M:N의 경우, 1:M, N:1로 엔터티를 나눠야 함.)
  • Crow’s Foot 모델 : 한 개 참여 - 실선 | 다수 참여 (Many) - 까마귀발 형태.

1:1 관계 (Data On Air)

1:M (Data On Air)

M:N (Data On Air)

• 관계선택사양 (Optionality)
  • 필수관계 : ex) 반드시 지하철의 문이 닫혀야만 지하철은 출발.
  • 선택관계 : ex) 출발을 알리는 안내방송은 지하철의 출발과 상관없음. | 물리속성에서 Foreign Key로 연결될 경우 Null을 허용할 수 있는 항목이 됨 | ERD에서 관계를 나타내는 선에서 선택참여하는 엔터티 쪽을 원으로 표시. | 양쪽 엔터티에 모두 선택참여가 표시 ▷ 즉 0:0(Zero to Zero)의 관계라면, 그 관계는 잘못될 확률이 높음.

선택참여 (Data On Air)

4. 관계의 정의 및 읽기

• 1) 관계 체크사항
  • 두 개의 엔터티 사이에 관심있는 연관규칙이 존재?
  • 두 개의 엔터티 사이에 정보의 조합이 발생?
  • 업무기술서, 장표에 관계연결에 대한 규칙이 서술?
  • 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 존재?
• 2) 관계 읽기
  • 기준(Source) 엔터티를 한 개(One) 또는 각(Each)으로 읽는다.
  • 대상(Target) 엔터티의 관계참여도 즉 개수(하나, 하나 이상)를 읽는다.
  • 관계선택사양과 관계명을 읽는다.

관계 읽기 (Data On Air)

 

반응형

5절 식별자

1. 식별자 개념

• 엔터티 : 인스턴스들의 집합.
• 식별자
  • 하나의 엔터티에 구성되어 있는 여러 개의 속성 중에 엔터티를 대표할 수 있는 속성. (Data On Air)
  • 엔터티 내 유일한 인스턴스를 식별할 수 있는 속성의 집합 (이기적)
• 하나의 엔터티는 반드시 하나의 유일한 식별자가 존재.
• 식별자와 키의 구분
  • 식별자 : 업무적으로 구분이 되는 정보 ▷ 논리 데이터 모델링 단계에서 사용
  • 키 : 데이터베이스 테이블에 접근을 위한 매개체 ▷ 물리 데이터 모델링 단계에서 사용

2. 식별자의 특징

• 유일성 : 주식별자에 의해 엔터티 내에 인스턴스들이 유일하게 구분.
• 최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수.
• 불변성 : 지정된 주식별자의 값은 자주 변하지 않아야 함.
• 존재성 : 주식별자가 지정이 되면 반드시 값이 들어와야 함.

3. 식별자 분류 및 표기법

식별자 분류 (Data On Air)

• 1) 식별자 분류
  • 대표성 여부
  • 자생 여부
  • 단일 속성 여부
  • 대체 여부

• 2) 식별자 표기법

식별자 표기 (Data On Air)

 

4. 주식별자 도출 기준

• 해당 업무에서 자주 이용되는 속성을 주식별자로 지정.
• 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정 자제.
• 복합으로 주식별자로 구성할 경우, 너무 많은 속성이 포함되지 않도록 함. ▷ 인조식별자를 생성하여 간략히!

5. 식별자관계와 비식별자관계에 따른 식별자

• 1) 식별자관계와 비식별자 관계의 결정
  • 외부식별자 (Foreign Identifier) : 다른 엔터티와의 관계를 통해 자식 쪽에 엔터티에 생성되는 속성. | 데이터베이스 생성 시에 Foreign Key역할.

식별자/비식별자 관계 조정 (Data On Air)

• 2) 식별자 관계
  • 부모로부터 받은 식별자를 자식엔터티의 주식별자로 이용하는 경우 ▷ Null값이 오면 안되므로 반드시 부모엔터티가 생성되어야 자신의 엔터티가 만들어짐. | 1:1 or 1:M 관계.
  • 식별자 관계 (Identifying Relationship) : 자식엔터티의 주식별자로 부모의 주식별자가 상속이 되는 경우.

외부식별자의 주식별자 역할 (Data On Air)

• 3) 비식별자 관계
  • 부모엔터티로부터 속성을 받았으나 자식엔터티의 주식별자로 사용하지 않고, 일반적인 속성으로만 사용하는 경우.
  • 아래의 경우, 비식별자 관계에 의한 외부속성을 생성.
    • (1) 자식엔터티에서 받은 속성이 필수가 아니어도 되므로 부모 없는 자식이 생성될 수 있는 경우이다.
    • (2) 엔터티별로 데이터의 생명주기 (Life Cycle)를 다르게 관리할 경우이다. ex) 부모엔터티에 인스턴스가 자식의 엔터티와 관계를 가지고 있었지만 자식만 남겨두고 먼저 소멸될 수 있는 경우. ▷ 이에 대한 방안으로 물리 데이터베이스 생성 시, Foreign Key를 연결하지 않는 임시적인 방법을 사용. But! 데이터 모델상에서 관계를 비식별자관계로 조정하는 것이 가장 좋음.
    • (3) 여러 개의 엔터티가 하나의 엔터티로 통합되어 표현되었는데 각각의 엔터티가 별도의 관계를 가질 때.
    • (4) 자식엔터티에 주식별자로 사용하여도 되지만 자식엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단될 때 비식별자 관계에 의한 외부식별자로 표현.
• 4) 식별자 관계로만 설정할 경우의 문제점 : 주식별자 속성이 지속적으로 증가할 수 밖에 없는 구조로서 개발자 복잡성과 오류가능성을 유발시킬 수 있는 요인이 됨.
• 5) 비식별자 관계로만 설정할 경우의 문제점 : 불필요한 조인이 다량으로 발생하면서 SQL구문이 길어지고 성능이 저하.

비식별자관계 설정 고려사항 (Data On Air)

• 6) 식별자관계와 비식별자관계 모델링
  • 비식별자관계 선택 프로세스 (위 이미지) : 독립적으로 주식별자를 구성한다는 의미 ▷ 업무적 필요성과 성능상 필요여부를 모두 반영.
  • 식별자와 비식별자관계 비교 

식별자 vs 비식별자 (Data On Air)

 

참고

• Data On Air
• 1장 - PDF 다운로드 (링크)

SQL 자격검정 실전문제 오답

• 엔터티의 특징
  • 1. 해당 업무에서 필요하고 관리하고자 하는 정보.
  • 2. 유일한 식별자로 식별 가능
  • 3. 영구적으로 존재하는 복수의 인스턴스 집합.
  • 4. 업무 프로세스 상 이용돼야 함.
  • 5. 반드시 속성이 필요.
  • 6. 타 엔터티와 최소 한 개 이상의 관계 필요.
• 기본 엔터티 : 다른 엔터티로부터 주시별자를 상속받지 않고 자신의 고유한 주식별자를 가짐.
• 도메인 : 각 속성이 가질 수 있는 값의 범위
• 관계
  • 데이터모델링 ☞ (ERD) 존재, 행위에 의한 관계별 표기법 X
  • UML ☞ (클래스다이어그램) 연관, 의존관계별 다른 표기법 O
• 관계 표기 : 관계명, 관계차수, 선택성(선택사양)의 개념으로 표현.
• 식별자 이론 (링크)

---

• 23.02.22 작성 시작
• 23.02.24 이론 작성 완료 및 PDF 추가
• 23.03.06 오타 수정 및 오답노트 작성
• 24.02.20 이기적 강의 내용 반영