[SQLD] 1과목 1장 데이터 모델링 이해

노희진·2021년 9월 2일
SQLD
1

SQLD

목록 보기
1/5
post-thumbnail

1. 1장 1절 데이터 모델링 개요

1) 모델링

① 정의

👉 모형, 축소형의 의미
👉 가설적 또는 일정 양식에 맞춘 표현
👉 사건에 관한 양상이나 관점을 연관된 사람이나 그룹을 위하여 명확하게 하는 것
👉 현실세계의 추상화된 반영

② 특징

✔ 추상화(모형화, 가설적) : 현실세계를 일정한 형식에 맞춰 표현한다. 다양한 현상을 일정한 양식인 표기법에 의해 표현한다.
✔ 단순화 : 복잡한 현실세걔를 약속된 규약에 의해 제한된 표기법이나 언어로 표현하여 쉽게 이해할 수 있도록 하는 개념이다.
✔ 명확화 : 누구나 이해하기 쉽게하기 위해 대상에 대한 애매모호함을 제거하고 정확하게 현상을 기술하는 것이다.

2) 데이터 모델링

① 정의

👉 정보시스템을 구축하기 위해 해당 업무에 어떤 데이터가 존재하는 지 또는 업무가 필요로 하는 정보가 무엇인지 분석하는 방법이다.
👉 현실세계의 데이터에 대해 약속된 표기법에 의해 표현하는 과정이다. -> ERD
👉 데이터베이스를 구축하기 위한 분석/설계의 과정
👉 3요소 : 어떤것(things), 성격(attributes), 관계(relationships)

② 중요성 및 유의점

  • 중복 : 같은 시간 같은 데이터 제공
  • 유연성 : 사소한 업무변화에 데이터 모델이 수시로 변경되면 안됨
  • 일관성 : 신용 상태에 대한 갱신 없이 고객의 납부 이력 정보 갱신 안됨

③ 특징

✔ 현재 또는 원하는 모습으로 가시화하도록 도와준다.
✔ 시스템의 구조와 행동을 명세화할 수 있게 한다.
✔ 시스템을 구축하는 구조화된 툴을 제공한다.
✔ 시스템을 구축하는 과정에서 결정한 것을 문서화한다.
✔ 다양한 영역에 집중하기 위해 다른 영역의 세부사항은 숨기는 다양한 관점인 추상화를 실행한다.
✔ 특정 목표를 따라 구체화된 상세 수준의 표현방법을 제공한다.

④ 데이터 모델링 3단계 (추상적 -> 구체적)

✔ 개념적 데이터 모델링 : 추상화 수준이 높고 업무중심적이고 포괄적인 수준의 모델링 진행, 전사적 데이터모델링, EA수립시 많이 이용
✔ 논리적 데이터 모델링 : 시스템으로 구축하고자 하는 업무에 대해 key, 속성, 관계 등을 정확하게 표현, 재사용성이 높음
✔ 물리적 데이터 모델링 : 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격 고려하여 설계

⑤ 3단계 데이터베이스 구조

  • 스키마 구성
    ✔ 외부스키마(External schema) - 사용자 관점
    : view 단계 여러개의 사용자 관점으로 구성, 개개 사용자 단계로써 개개 사용자가 보는 개인적 DB 스키마,
    DB의 개개 사용자가 보는 개인적 DB 스키마
    ✔ 개념스키마(Conceptual schema) - 통합 관점
    : 개념 단계 하나의 개념적 스키마로 구성하여 모든 사용자 관점을 통합한 조직 전체의 DB를 기술하는 것,
    모든 응용 시스템들이나 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 DB를 기술한 것으로 DB에 저장되는 데이터와 그들간의 관계를 표현하는 스키마
    ✔ 내부스키마(Internal schema) - 물리적 저장구조
    : 내부단계, 내부스키마로 구성됨, DB가 물리적으로 저장된 형식,
    물리적 장치에서 데이터가 실제로 저장되는 방법을 표현하는 스키마

  • 독립성
    ✔ 논리적 독립성
    : 내부스티키마가 변경되어도 외부스키마에는 영향을 미치지 않도록 지원하는 것,
    논리적 구조가 변경되어도 응용프로그램에 영향없음,
    사용자 특성에 맞는 변경이 가능함, 통합 구조 변경이 가능함
    ✔ 물리적 독립성
    : 내부스키마가 변경되어도 외부/개념스키마에 영향을 받지 않도록 지원하는 것,
    저장장치의 구조변경은 응용프로그램과 개념스키마에 영향없음,
    물리구조 영향없이 개념구조 변경이 가능함, 개념구조 영향없이 물리적인 변경이 가능함

  • 사상
    ✔ 외부적/개념적 사상(논리적 사상)
    : 외부적 뷰와 개념적 뷰의 상호 관련성을 정의함,
    사용자가 접근하는 형식에 땨라 다른 타입의 필드를 가질 수 있음, 개념적 뷰의 필드 타입은 변화가 없음
    ✔ 개념적/내부적 사상(물리적 사상)
    : 개념적 뷰와 저장된 데이터베이스의 상호 관련성을 정의함,
    만약 저장된 데이터베이스 구조가 바뀐다면 개념적/내부적 사상이 바뀌어야함, 그래야 개념적스카마가 그대로 남아있게 됨

3) 데이터모델링 표기법

1976년 피터첸이 Entity Relationship Model 개발, ER모델
(chen은 이론상, IE는 협업에서 많이 사용)

  • 작업순서
    1.엔터티 그림
    2.엔터티 배치
    3.엔터티 관계설정
    4.관계명 기술
    5.관계의 참여도 기술
    6.관계필수여부

4) 좋은 데이터 모델의 요소

  1. 완전성 : 업무에 필요한 모든 데이터가 모델에 정의
  2. 중복배제 : 하나의 DB내에 동일한 사실은 한번만
  3. 업무규칙 : 많은 규칙을 사용자가 공유하도록 제공
  4. 데이터 재사용 : 데이터가 독립적으로 설계돼야 함
  5. 의사소통 : 업무규칙은 엔터티,서브타입,속성,관계 등의 형태로 최대한 자세히 표현
  6. 통합성 : 동일한 데이터는 한 번만 정의, 참조활용

2. 1장 2절 엔티티

1) 개요

👉 데이터 모델을 이해할때 가장 명확하게 이해해야 하는 개념이다.
👉 엔티티는 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것(하나의 공통적인 특징을 가진 것들)이다.

2) 정의

  • 다양한 정의
    변화할 수 있는 사물
    데이터베이스 내에서 변별가능한 객체
    정보를 저장할 수 있는 어떤 것
    정보가 저장될 수 있는 사람, 장소, 물건,사건, 개념 등
    업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것

  • 정의의 공통사항
    👉 사람, 장소, 물건, 사건, 개념 등의 명사에 해당한다.
    👉 업무상 관리가 필요한 관심사에 해당한다.
    👉 저장이 되기 위한 어떤 것(thing)이다.

  • 특징
    👉 반드시 해당 업무에서 필요하고 관리하고자하는 정보이어야 한다.
    👉 유일한 식별자에 의해 식별이 가능해야 한다. -> PK
    👉 영속적으로 존재하는 인스턴스의 집합이어야 한다.(한 개가 아니라 두 개이상)
    👉 반드시 속성이 있어야 한다.
    👉 다른 엔티티와 최소 한 개 이상의 관계가 있어야 한다.

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

3) 엔티티 - 인스턴스

👉 엔티티는 인스턴스의 집합이다.
👉 엔티티는 대부분 사각형으로 표현된다.

4) 분류

① 유무형에 따른 분류

  • 유형 : 물리적 형태 ex)사원, 물품, 강사
  • 개념 : 개념적 정보 ex)조직, 보험상품
  • 사건 : 업무 수행시 발생 ex)주문, 청구, 미납

② 발생 시점에 따른 분류

  • 기본 : 그 업무에 원래 존재하는 정보, 타 엔터티의 부모 역할, 자신의 고유한 주식별자 가짐 ex)사원,부서
  • 중심 : 기본 엔터티로부터 발생, 다른 엔터티와의 관계로 많은 행위 엔터티 생성 ex)계약, 사고, 주문
  • 행위 : 2개 이상의 부모엔터티로부터 발생, 자주 바뀌거나 양이 증가 ex)주문목록, 사원변경이력

3. 1장 3절 속성

1) 정의

👉 업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위(칼럼)이다.
👉 엔티티는 속성들에의해 설명된다.

한 개의 엔터티는 2개 이상의 인스턴스 집합
한 개의 엔터티는 2개 이상의 속성을 가짐
한 개의 속성은 1개의 속성값을 가짐

2) 표기법

👉 엔티티 내에 이름을 포함하여 표현한다.

  • 속성의 명명
  1. 해당업무에서 사용하는 이름 부여
  2. 서술식 속성명은 사용 금지
  3. 약어 사용 금지
  4. 전체 데이터모델에서 유일성 확보

3) 분류

① 특성에 따른 분류

  • 기본 속성
    👉 업무 분석을 통해 바로 정의한 속성

  • 설계 속성
    👉 원래 업무상 존재하지는 않지만 설계를 하면서 도출해내는 속성

  • 파생속성
    👉 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성

② 엔티티 구성방식에 따른 분류

  • PK(Primary Key) 속성
    👉 엔티티를 식별할 수 있는 속성

  • FK(Foreign Key) 속성
    👉 다른 엔티티와의 관계에서 포함된 속성

  • 일반속성
    👉 엔티티에 포함되어있고 PK, FK에 포함되지 않은 속성

4. 1장 4절 관계

1) 정의

👉 엔티티의 인스턴스 사이의 논리적인 연관성으로써 존재의 형태나 행위로써 서로에게 연관성이 부여된 상태를 의미한다.

👉 패어링 : 각각의엔티티의 인스턴스들은 자신이 관련된 인스턴스들과 관계의 어커런스로 참여하는 형태

👉 분류 : 관계를 연결함에 있어 어떤 목적으로 연결되었느냐에 따라 분류하므로 관계는 존재 또는 행위에 의한 관계로 분류할 수 있다.

https://m.blog.naver.com/icbanq/221781238065
UML에는 연관관계와 의존관계가 있는데, 연관(존재적)관계는 항상 이용하는 관계이고 의존관계는 상대방 행위에 의해 발생하는 관계이다. ERD에서는 존재적 관계와 행위에 의한 관계를 구분하지 않고 표기했지만 UML에서는 이를 구분하여 연관관계는 실선, 의존관계는 점선으로 표현한다.

2) 관계명

👉 관계시작점과 끝점 모두 관계이름을 가져야 한다.
👉 참여자의 관점에 따라 관계이름이 능동적이거나 수동적으로 명명된다.
👉 애매한 동사는 피한다.
👉 현재형으로 표현한다.

3) 관계차수(Degree, Caradinality)

👉 두 개의 엔티티간 관계에서 참여자의 수를 표현하는 것을 관계차수라고 한다. 가장 일반적인 관계차수 표현 방벙은 1:1, 1:M, M:N이다.
👉 관계차수를 표시하는 방법은 여러가지가 있지만 Crow's Foot 모델에서는 선을 이용하여 표시한다. 한개가 참여하는 경우는 실선을 그대로 유지하고 다수가 참여한 경우는 까마귀말과 같은 모양으로 그려준다.

4) 관계 선택사양(관계선택성)

👉 엔티티가 항상 참여하는지 아니면 참여할 수도 있는지 나타내는 방법이다. 필수(Mandatory Membership)와 선택참여(Optional Membership)가 있다.
👉 선택참여관계는 선택참여하는 엔티티 쪽을 원으로 표시한다. 필수참여는 아무런 표시를 하지 않는다.

5) 관계읽기

👉 기준엔티티를 한개 또는 각각 읽는다.
👉 대상 엔티티의 관계참여도(개수 - 하나, 하나 이상)를 읽는다.
👉 관계 선택사양과 관계명을 읽는다.

6) 관계확인사항

  1. 2개의 엔터티 사이에 관심있는 연관 규칙이 있는가?
  2. 2개의 엔터티 사이에 정보의 조합이 발생하는가?
  3. 업무기술서, 장표에 관계연결에 대한 규칙이 서술되었는가?
  4. 업무기술서, 장표에 관계연결을 가능케 하는 동사가 있는가?

5. 1장 5절 식별자

1) 개념

👉 여러개의 집합체를 담고 있는 하나의 통에서 각각을 구분할 수 있는 논리적인 이름이다.
👉 엔티티 내에서 인스턴스들을 구분할 수 있는 구분자이다.

(식별자는 논리 데이터 모델링 단계에 사용, Key는 물리 데이터 모델링 단계에 사용)

① 특징

  • 유일성 : 주식별자에 의해 엔티티내에 모든 인스턴스들을 유일하게 구분한다.
  • 최소성 : 주식별자르 ㄹ구성하는 속성의 수는 유일성을 만족하는 최소릐 수가 되어야 한다.
  • 불변성 : 주식별자가 한번 특정 엔티티에 지정되면 그 식별자으 값은 변하지 말아야 한다.
  • 존재성 : 주식별자가 지정되면 반드시 데이터 값이 존재해야 한다.(NULL 안됨)

② 식별자 분류

  • 대표성 여부
    👉 주식별자 : 엔티티 내에서 각 어커런스를 구분할 수 있는 구분자이며, 타 엔티티와 참조관계를 연결할 수 있는 식별자이다.
    👉 보조식별자 : 엔티티 내에서 각 어커런스를 구분할 수 있는 구분자이지만 대표성을 가지지 못해 참조관계를 연결하지 못한다.

  • 스스로 생성 여부
    👉 내부식별자 : 엔티티 내부에서 스스로 만들어지는 식별자이다.
    👉 외부식별자 : 타 엔티티와의 관계를 통해 타 엔티티로 부터 받아오는 식별자이다.

  • 속성의 수
    👉 단일식별자 : 하나의 속성으로 구성된 식별자이다.
    👉 복합식별자 : 2개 이상의 속성으로 구성된 식별자이다.

  • 대체 여부
    👉 본질식별자 : 업무에 의해 만들어지는 식별자이다.
    👉 인조식별자 : 업무적으로 만들어지지는 않지만, 원조식별자가 복잡한 구성을 가지고 있기 때문에 인위적으로 만든 식별자이다.

2) 식별자 관계

👉 자식의 주식별자로 부모의 주식별자가 상속이 되는 경우이다.

① 주식별자 (er모델-실선)

👉 부모로부터 받은 식별자를 자식엔터티의 주식별자로 이용하는 경우 강한 연결관계 표현하며 ER모델에서 실선으로 표기한다.

  • 주식별자 도출 기준
  1. 해당 업무에서 자주 이용되는 속성
  2. 명칭, 내역 등과 같이 이름으로 기술되는 것들은 안됨
  3. 복합으로 주식별자로 구성할 경우 너무 많은 속성안됨

② 비식별자 (er모델-점선)

👉 부모 속성을 자식의 일반 속성으로 이용하는 경우 약한 연결관계 표현하며 ER모델에서 점선으로 표기한다.
👉 SQL 문장이 길어져 복잡성 증가되는 것 방지한다.

  • 비식별자 도출 기준
  1. 부모 없는 자식이 생성될 수 있는 경우
  2. 부모와 자식의 생명주기가 다른 경우
  3. 여러개의 엔터티가 하나의 엔터티로 통합되어 표현되었는데 각각의 엔터티가 별도의 관계를 가진 경우
  4. 자식엔터티에 별도의 주식별자를 생성하는 것이 더 유리한 경우

3) 식별자와 비식별자 관계에 따른 SQL 비교

  • 식별자 관계가 불편한 경우
    👉 식별자 관계를 연결한 데이터 모델의 PK 속성의 수는 데이터 모델의 흐름이 길어질수록 증가하는 구조를 가진다.

select a.event_id, a.trans_time, a.hst_del_flag, a.status_promot, a.status_old, a.status_new
from eqpevtstshst a, eqp_item b, eqp_worker c
where a.equipment_id = b.equipment_id 
and a.status_seq = b.status_seq
and a.event_id = b.event_id 
and a.trans_time = b.trans_time
and b.item_cd = 'A001'
and a.plant = c.plant
and a.equipment_id = c.equipment_id
and a.status_seq = c.status_seq
and a.event_id = c.event_id
and a.trans_time = c.trans_time
and c.worker_sid = 'A012008001'

고작 3개 정도의 엔티티를 조인했을 뿐인데 SQL구문의 where절이 매우 길어진 사실을 알 수 있다.

  • 식별자 관계가 편한 경우

4) 실습

모델링 실습

  • 모델링 순서
  1. 엔터티 식별
  2. 엔터티별 속성 식별
  3. 엔터티의 키 구분
  4. 속성 및 관계 규정 (식별, 비식별 구분)
  5. 논리 모델링 ( 논리erd 작성)
  6. 물리 모델링 ( 물리erd 변환)

📌 예제1)

  • 인터뷰 내용
    우리 회사는 여러 사원들이 있다.
    우리회사는 사원들의 이름, 직무, 상급자, 채용일, 월급, 보너스, 소속부서로 관리하고 싶다.
    이때 각사원별로 관리할 수 있는 사원번호를 만들었으면 좋겠다.
    우리 회사는 지역별로 부서들이 있다.
    이러한 부서 정보를 부서번호를 통해 관리하고 싶다.
    사원들은 최소 하나 이상의 부서에 소속될 수 있다.

  • 주요 엔티티 및 속성
    사원
    사원번호, 이름,직무, 상급자(FK), 채용일, 월급, 보너스, 소속부서(FK)
    부서
    부서번호, 부서이름, 지역

📌 예제2)
우리 회사는 150명의 직원을 둔 SI업체로, 50명의 마케팅, 경영 관리 및 연구 개발 직원을 제외하면 100명의 개발자가 월 평균 10개 정도의 프로젝트를 수행하고 있다. 개발자들은 프로젝트에 초기부터 종료 시까지 투입되기도 하고, 프로젝트 중간에 일정 기간 동안만 투입되기도 한다. 프로젝트에 투입되는 개발자들은 경력과 기술 등급에 따라서 PM, PL, 분석자, 설계자, 프로그래머, 테스터 등 다양한 직무를 맡는다.

우리 회사가 수행하는 프로젝트에 대해 프로젝트번호, 프로젝트명, 프로젝트 착수 일자/종료 일자, 발주처 등을 관리하고, 직원들에 대해서는 직원번호, 직원명, 주민등록번호, 최종 학력을 관리하며, 특히 프로젝트 투입 직원들에 대해서는 경험 기술들을 관리하고자 한다.

경영진은 현재 우리 회사가 몇 개의 프로젝트를 수행하고 있고, 직원들이 현재 어느 프로젝트에 몇 명이나 투입되어 있으며, 그들이 각각 어떤 직무를 수행하고 있고, 투입기간이 어떻게 되는지 등을 체계적으로 관리하길 원하고 있다. 이를 통해서 과거 특정 시점에 어떤 직원이 어느 프로젝트에 어떤 직무로 참여했었는지도 알 수 있고, 개인별 경력 관리는 물론 인센티브 지급을 위한 기초 자료까지 추출할 수 있다.

직원들이 참여한 각 프로젝트에서는 프로젝트 종료 시점에 평가를 실시한다. 평가에는 고객 평가, PM 평가, 동료 평가 등이 존재한다. 각 평가는 평가자와 피 평가자가 존재하고 평가 항목으로는 업무 수행 평가, 커뮤니케이션 능력 평가가 있다. 각 평가 항목당 평점과 평가 내용을 관리한다. 고객 평가는 고객이 프로젝트에 참여한 참여사 직원들에 대해서 평가하는 것을 말한다. 프로젝트를 종료하는 시점에 PM이 주관하여 고객사의 담당자로부터 평가서를 의뢰하고 결과를 회사에 보고해야 한다. 동료 평가는 프로젝트에 참여한 각 멤버들이 자기 이외의 프로젝트 참여자에 대해서 평가하는 것이다. 이 중에서 PM 평가는 PM이 프로젝트 팀원을 평가하는 것을 말한다. 이러한 평가의 결과는 회사 내부에서 인사 고과와 인사 평가의 근거 자료로 활용된다.

📄출처 : 덕성여대 wiset SQLD 자격증 특강 강의자료

profile
노희진
코린이
다음 포스트

[SQLD] 1과목 2장 데이터 모델과 성능

0개의 댓글

관련 채용 정보