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

---

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

---

📌 1장 - 데이터 모델링의 이해

---

📍 발생시점에 따른 엔터티 분류 :

• 기본/키엔터티
  
  • 그 업무에 원래 존재하는 정보.
  • 다른 엔터티와의 관계에 의해 생성되지 않고 독립적으로 생성이 가능.
  • 자신은 타 엔터티의 부모의 역할을 함.
  • 다른 엔터티로부터 주식별자를 상속받지 않고, 자신의 고유한 주식별자를 가지게 됨.
  • EX) 사원, 부서, 고객, 상품, 자재 등등.
• 중심엔터티 
• 행위엔터티

📍 모델링은 현실세계에 대해 표현하는 것.
----> 복잡한 현실세계를 다른 사람들이 봤을 때도 한번에 이해 할 수 있게 표현해줘야 함.




📍 모델링의 특징

• 추상화의 의미
• 시스템 구현만을 위해 수행하는 것이 아니고 !! ❌❌ 시스템 구현을 포함한 업무 및 업무 형상화의 의미
• 단순화의 의미
• 정확화의 의미

📍 데이터모델링?

• 정보시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
• 현실세계의 데이터에 대해 약속된 표기법에 의해 표현하는 과정
• 데이터베이스를 구축하기 위한 분석 / 설계의 과정

📍 데이터 모델링을 하는 이유?

• 정보 시스템 구축의 대상이 되는 업무 내용을 정확하게 분석
  • ---> 업무에 기초가 되는 정보들을 일정한 표기법에 의해 표현함
• 개발 및 데이터 관리에 사용하기 위함
• --------> 데이터모델링 은 --> 단지 데이터베이스만을 구축하기 위한 용도로 쓰이는 것이 아님!! ❌❌
• --------> ⭕⭕ 데이터모델링 자체로서 업무를 설명하고 분석하는 부분에서도 중요한 의미를 가지고 있다.

📍 데이터 모델링 유의점?

• 중복
  • 같은 데이터를 다 같은 사람들이 봐야하는 거니까, 중복이 최소화 되어야 한다는 것.
• 비유연성
  • ❗❗ 데이터 모델을 어떻게 설계했는 지에 따라, 사소한 업무의 변화에도 데이터 모델이 수시로 변경되는 일이 있을 수 있다. --> 유지보수하기 힘들어짐.
  • 데이터의 정의 와 데이터의 사용 프로세스 와 분리!! 
  • ------> 데이터  || 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 가능성을 줄여준다!
• 비일관성
  • 데이터의 중복이 없어도! 비일관성이 존재할 수 있다.
  • EX) 신용 상태에 대한 갱신 없이 고객의 납부 이력 정보를 갱신하는 경우.
  • ------> ✔ 데이터와 데이터 간의 상호 연관 관계에 대해 명확하게 정의해서 비일관성을 사전 예방해야함.
  • ❗❗ 사용자가 처리하는 프로세스 혹은 이와 관련된 프로그램과 테이블의 연계성을 높이는 것은 데이터 모델이 업무 변경에 대해 취약하게 만드는 단점.

📍 데이터 모델링 개념

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

📍 스키마?

• 데이터베이스의 구조와 제약조건에 관한 전반적인 명세를 기술한 것.

📍 데이터 베이스 스키마 구조 3단계 ( ANSI-SPARC 에서 정의한 3단계 구조 )

• 외부 스키마
  • 사용자 || 응용 프로그래머가 각 개인의 입장에서 필요로 하는 데이터베이스의 논리적 구조를 정의한 것.
• 개념 스키마
  • 데이터베이스의 전체적인 논리적 구조.
  • 모든 응용 프로그램이나 사용자들이 필요로 하는 데이터를 종합한 조직 전체의 데이터베이스.
  • 데이터베이스에 저장되는 데이터와 그들간의 관계를 표현하는 스키마.
  • 모든 사용자 관점을 통합한 조직 전체 관점의 통합적 표현.
  • ❗❗ 하나만 존재함.
• 내부 스키마
  • 물리적 저장장치의 입장에서의 데이터베이스 구조
  • 실제로 저장될 레코드의 형식, 저장 데이터 항목의 표현 방법, 내부 레코드의 물리적 순서등을 나타냄.

📍 엔터티의 특징 ?

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 함. 
  • EX) 사원번호, 학번, 이자율 등등
• 유일한 식별자에 의해 식별이 가능해야 함.
• 영속적으로 존재하는 인스턴스의 집합이어야 함. 
  • ❗❗ 두 개 이상 ❗❗
• 업무 프로세스에 의해 이용되야 함. 
  • ---> 해당 업무에 반드시 필요하고 관리 되어야 하는 정보니까, 이용도 되어야 하는 이유.
• 반드시 속성이 있어야 함.
• 다른 엔터티와 최소 한 개 이상의 관계가 있어야 함.
  • 💥 그러나!!  공통코드, 통계성 엔터티의 경우는 관계 생략가능.

📍 속성 ?

• 업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위.
• 엔터티에 대한 자세하고 구체적인 정보를 나타냄.
• 하나의 인스턴스에서 각각의 속성은 한 개의 속성값을 가짐.
• 속성도 집합 이다.
• https://computer-science-student.tistory.com/240
•  
•  

 

 

📍 엔터티, 인스턴스, 속성, 속성값의 관계

• 한 개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 함.
• 한 개의 엔터티는 두 개 이상의 속성을 가짐.
• 한 개의 속성은 한 개의 속성값을 갖음.
•  
• 엔터티 (Entity) (= 테이블)
  • 업무에서 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것.
  • 개념, 사건, 장소 등의 명사(Things) 이다.
• 속성 (Attribute) = 컬럼
  • 업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위.
• 인스턴스 (Instance) = 행
  • 데이터베이스에 저장된 데이터 내용의 전체 집합을 의미.

https://m.blog.naver.com /clsrnclsrn95/222069240916

 

 

📍 속성의 특성에 따른 분류 ?

• 기본 속성
  
  • EX) 원금, 예치기간, 이자율
• 설계 속성
  • EX) 예금 분류
• 파생 속성
  •  데이터를 조회할 때 빠른 성능을 할 수 있도록 하기 위해 원래 속성의 값을 계산해서 저장할 수 있도록 만든 속성.
  • EX) 이자
    • ( 이자는 계산된 값이라서 파생 속성. --> 이자 = 원금 * 이자율 )

📍 도메인 ?

• 각 엔터티(테이블)의 속성에 대해서 어떤 유형의 값이 들어가는 지를 정의한 개념.
• 각 속성들이 가질 수 있는 값의 범위.
• 엔터티 내에서 속성에 대한 데이터타입과 크키, 제약사항을 지정하는 것.
• EX) "주문" 엔터티, "단가" 속성 --> INT(10) 로 정의함.

📍 속성의 명칭 부여 ?

• 해당 업무에서 사용하는 이름 부여.
• 서술식 속성명 사용 하지 않음.
• 약어 사용은 가급적 지양.
• 전체 데이터모델에서 유일성 확보를 지향.
• -----------------------------------------------
• 속성의 명칭은 애매모호하지 않게, 복합 명사를 사용해서 구체적으로 명명.
• 전체 데이터 모델에서 유일성을 확보해야, 반정규화, 통합 등의 작업을 할 때 혼란을 방지할 수 있다.

📍 Q.20 !?  ---> 데이터모델링의 관계

• 관계는 존재에 의한 관계(존재적 관계)와 행위에 의한 관계로 구분될 수 있음.  ➕ 둘을 구분하는 표기법은 없음.
  • ❗❗ 그러나!! , ERD에서는 관계를 연결할 때, 존재와 행위를 구분하지 않고 단일화된 표기법을 사용함.
  • ERD에서는 존재적 관계와 행위에 의한 관계  구분 없음!!! ❌ ❌,
  • 클래스 다이어그램에서는 구분 ⭕️ ⭕️ !!!  연관관계와 의존 관계로 표현함.
• UML에는 클래스다이어그램의 관계 중
  • 연관관계 -> 실선
  • 의존관계 --> 점선  으로 표기.

 

 

 

 

 

📍 관계 ?

• 존재적 관계와 행위에 의한 관계로 나뉨.
• 표기법 : 관계명, 관계차수, 선택성(선택사양)의 개념으로 표현함.
  • 관계명 : 관계의 이름
  • 관계차수 : 1:1, 1:M, M:N
  • 관계선택사양 : 필수관계, 선택관계
• EX) 부서와 사원 엔터티 간의 '소속' 관계는 존재적 관계.
• EX) 주문과 배송 엔터티 간의 '배송 근거' 관계는 행위에 의한 관계.

 

📍 관계 읽기 (엔터티 사이에서 관계를 도출할 때의 체크 사항)?

• 기준 엔터티를 "한 개" 또는 "각" 으로 읽음.
• 대상 엔터티의 관계참여도를 읽음. (개수 ("하나", "하나이상")를 읽음.)
• 관계선택사양과 관계명을 읽음.
• -----------------------------------------------------------------------------
• 두 개의 엔터티 사이에 관심있는 연관규칙이 존재하는가?
• 두 개의 엔터티 사이에 정보의 조합이 발생되는가?
• 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
• 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?
  • 엔터티 => 명사(Noun) !!

 

 

 

 

 

📍 식별자 ?

• 엔터티 내에서 대표성을 가지는 가?
  • 주식별자 : 엔터티 내에서 각 어커런스를 구분할 수 있는 구분자 ➕ 타 엔터티와 참조관계를 연결할 수 있는 식별자
    •  유일성  : 주식별자에 의해 엔터티 내의 모든 인스턴스들이 유일하게 구분되야 함.
    •  최소성  : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되야함.
    •  불변성  : 주식별자가 한 번 특정 엔터티에 지정되면 그 식별자의 값은 변하지 않아야 함.(지정된 주식별자의 값은 자주 변하지 않는 것 이어야 함.)
    •  존재성  : 주식별자가 지정이 되면 반드시 데이터 값이 존재해야 함. (NULL 안됨!!)
    • -------------------------------------------------------------------------------------------------------------------
    • 명칭, 내역등과 같이 이름으로 기술되는 것들은 주식별자로 지정하기에 부적절함.
      • EX) 사람의 이름의 경우 -> 동명이인이 있을 수 있기 때문.
    • 해당 업무에서 자주 이용되는 속성을 주식별자로 지정함.
    • 복합으로 주식별자를 구성할 경우 너무 많은 속성이 포함되지 않게 함.
    • -------------------------------------------------------------------------------------------------------------------
  • 보조식별자 : 엔터티 내에서 각 어커런스를 구분할 수 있는 구분자이지만, 대표성은 없음 --> ❗❗ 참조관계 연결 불가.
• 엔터티 내에서 스스로 생성되었는지 여부
  • 내부 식별자 : 엔터티 내부에서 스스로 만들어지는 식별자
  • 외부 식별자 : 타 엔터티와의 관계를 통해 타 엔터티로부터 받아오는 식별자
• 단일 속성으로 식별되는가? (속성의 수)
  • 단일 식별자 : 하나의 속성으로 구성된 식별자
  • 복합 식별자 : 둘 이상의 속성으로 구성된 식별자
• 원래 업무적으로 의미가 있던 식별자 속성을 대체하여 일련번호와 같이 새롭게 만든 식별자인 가? (대체 여부)
  • 본질 식별자 : 업무에 의해 만들어지는 식별자
    • 인스턴스의 탄생과 함께 업무적으로 부여되는 속성.
    • EX) 사번의 경우, "사원" 인스턴스가 생길 때마다 부여되는 본질적인 속성에 해당됨.  --> 사번은 본질 식별자에 해당됨.
  • 인조 식별자 : 업무적으로 만들어지지는 않지만, 원조식별자가 복잡한 구성을 가지고 있기 때문에 인위적으로 만든 식별자.

 

 

 

 

 

 

 

 

 

📍 식별자와 비식별자관계 비교 ?

항목	식별자 관계	비식별자 관계
목적	강한 연결관계 표현	약한 연결관계 표현
자식 주식별자 영향	자식 주식별자의 구성에 포함됨	자식 일반 속성에 포함됨
표기법	실선 표현	점선 표현
연결 고려사항	- 반드시 부모엔터티 종속 - 자식 주식별자구성에 부모 주식별자포함 필요 - 상속받은 주식별자속성을 타 엔터티에 이전 필요	- 약한 종속관계 - 자식 주식별자구성을 독립적으로 구성 (자식테이블에서 독립적인 기본키의 구조를 가지기 원할 때) - 자식 주식별자구성에 부모 주식별자 부분 필요 - 상속받은 주식별자속성을 타 엔터티에 차단 필요 - 부모쪽의 관계 참여가 선택관계​ (부모엔터티의 주식별자를 자식엔터티에서 받아 손자엔터티까지 계속 흘려보내기 위해) - 비식별자관계의 선택이 단순히 SQL 문장의 복잡도를 낮추는 목적에서 고려되는 것은 바람직하지 않음. - 부모엔터티에 참조값이 없어도 자식엔터티의 인스턴스가 생성될 수 있는 경우 - 부모엔터티의 인스턴스가 자식의 엔터티와 관계를 가지고 있었지만 자식만 남겨두고 먼저 소멸될 수 있는 경우 - 여러 개의 엔터티를 하나로 통합하면서 각각의 엔터티가 갖고 있던 여러 개의 개별 관계가 통합되는 경우 - 자식쪽 엔터티의 주식별자를 부모엔터티와는 별도로 생성하는 것이 더 유리하다고 판단하는 경우

 

https://snnchallenge.tistory.com/190

[SQLD : Ⅰ. 데이터 모델링의 이해] 4-2. 식별자관계와 비식별자관계

📍 ?

• ㅇ