[DB] Data Modeling : Conceptual

강의자료 : https://drive.google.com/open?id=1GJmHMa2GwkHKNPYEweuPEvY5jZ-_z43t&authuser=delab%40kookmin.ac.kr&usp=dri

Data Modeling

: 데이터 베이스를 설계하는 일련의 과정

아래 두 단계로 나뉘어 수행된다.

• Conceptual Modeling
• Logical Modeling

Database : DB : 데이터 저장소

: 데이터 및 데이터간 관계의 집합

데이터가 많을 때 효율적으로 관리하기 위해서 DB 필요

대용량의 데이터를 많은 사용자들이 동시에 접속할 일이 있을 때 Database를 사용한다

 

Database System

Database System

• DBMS : Database Management Systems
  사용자가 Database에 접근할 수 있도록 지원해주는 프로그램의 집합
• 질의 : Query
  데이터베이스에 정보를 요청
• Database : 데이터 뿐만 아니라 및 데이터간 관계까지 포함된 것

Schemas & Instances

• 데이터베이스 스키마(Schema)
  • 값이 담기기 위한 껍데기 부분 
  • 데이터베이스의 구조, 타입, 제약조건에 대한 명세
  • 지도 같은것. 자주 변경되지 않고 처음 설계할 때 명시함
  • DB design = Data modeling = 스키마를 만드는 것

Schema

• 데이터베이스 인스턴스(Instance)
  • 실제 값이 담기는 부분
  • 특정 시점에 데이터 베이스에 저장된 실제 데이터
  • Database Instance = Occurence(수학에서의 개념) = snapshot

Instance

SQL : Structured Query Language

SQL 종류

• DDL : 데이터 정의어 : Data Definition Language
  • 스키마를 기술하기 위해 사용
  • 주로 설계자가 사용
  • 테이블/열/관계 생성
  • ex) CREATE, ALTER, DROP
• DML : 데이터 조작어 : Data Manipulation Language
  • 데이터 조회, 삽입, 삭제, 갱신 등
  • 인스턴스에 대한 것들
  • ex) SELECT, INSERT, UPATE, DELELE
• DCL : Data Control Language
  • 사용자에 대한 명령어
  • GRANT, REVOKE
• TCL : Transaction Control Language
  • 트랜잭션 관리, 사용자 권한 관리
  • COMMIT, ROLLBACK

유형

• 독립 실행형
  • SQL 쿼리를 DBMS에 직접 입력
• 내장형
  • SQL문을 프로그래밍 언어에 심어둠
  • C, Java 등에 내장됨
  • Host Language + Data sub-language로 구성

Database Design Process

데이터베이스 설계는 4가지 단계로 구성된다.

1. 요구사항 분석
   Miniworld(ex. 학교)에 대한 업무기술서를 만듦
2. 개념적 설계 : Conceptual Design
   보편적으로 개체관계 모형(=Entity-Relationship Model=ERM=ER Model)을 사용해서 만든 산출물로 ERD(ER Diagram)를 만든다.
   즉, ERD는 ER Model을 시각적으로 표현한 다이어그램이다.
3. 논리적 설계 : Logical Design
   Conceptiual Design을 컴퓨터가 알아들을 수 있도록 바꾸는 과정.
   보편적으로 관계형 모델(=Relational Model)로 논리적 설계를 한다. 관계형 모델의 결과가 table이다.
4. 물리적 설계 : Physical Design
   관계형 모델을 직접 등록/구현

ER Model

• Entity : 개체
  • 실세계에 존재하는 의미있는 하나의 정보 단위
  • 물리적(학생, 강의실), 개념적(직업, 프로젝트)인 객체 모두 포함 가능
  • ERD에서 사각형으로 표현
• Relationship : 관계 (!= relation)
  • 개체들 간의 연관성
  • ERD에서 마름모로 표현
•  Relation
  • Table로 나타낸 Database
• Attribute : 속성
  • 개체 또는 관계의 본질적 속성
  • 개체에만 속성이 있는 것이 아니라 관계에도 속성이 있을 수 있음
    ex) 수강이라는 관계에는 평점(A, B, C..)과 이수구분이 포함될 수 있음
    • 학생에게 평점을 물어보면 어떤 교과목이 평점인지 물어봐야하고, 교과목의 평점을 물어본다면 어떤 학생의 평점인지 물어봐야 함
    • 또한, 어떤 학생에게 데이터베이스는 전공이지만 타학과 학생에게는 교양일 수 있다.
  • ERD에서 원

Generalization

: 일반화

: "is a" relationship

 

 

• 비행기, 자동차, 지하철이 가지고 있는 공통적인 속성을 운송수단이라는 부모 개체로 묶고 각자만 가지고 있는 속성들 만을 표기할 수 있다.
• 자식 개체는 각자 키 속성을 가지지 않아도 된다. 왜냐하면 부모 개체인 운송수단에 고유번호라는 키 속성이 있기 때문이다.
• 자식 개체 is a 부모 개체
  • 비행기 is a 운송수단 = 비행기는 운송수단이다
  • 라고 말했을 때 문맥에 맞다.
• 이런 관계에서는 일반화(Generalization)을 해서 ERD를 그리면 편리하다.

 

Relationships

관계(Relationship) 설정

한 개체의 속성이 다른 개체를 참조할 때 relationship이 형성된다
ex) '부서' 개체의 '관리자'속성은 '직원'개체를 참조 -> 관계 형성

 

차수 : Degree

관계에 참여하는 개체의 수

• 1차 : Unary
  자기 자신을 참고하는 관계
• 2차 : Binary
  한 관계가 연관된 entity가 2개이다.
• 3차 : Ternary (3차 이상은 N-ary)라고 부른다
  • 1개의 ternary를 3개의 binary로 변환해서 사용할 수 있다.
  • 관계를 entity로 바꾸고 이에 key를 주는 것이 일반적으로 좋다.

대응수 : Cardinality

실무에서는 대응수를 차수라고도 부른다
해당 개체가 관계에서 참여할 수 있는 관계 인스턴스의 최대 수

• 1:1
  하나의 학생이 하나의 과대표에 연결
• 1:N
  하나의 학생 -> N개의 전공과 연결
  
  
  
• N:M (Many to many)
  N명의 학생이 M개의 과목을 수강
  한 개체의 대응수를 정할 때 나머지 entity를 고정시키고 생각하기

<참고 : Cardinality의 다른 의미>
데이터베이스 컬럼에 있는 고유한 값의 개수로 "행의 수"를 의미하기도 한다.

(↔degree : 속성의 수 : 열의 수)

 

대응수에 따른 관계의 분류

대응수에 따라 관계에 속한 attribute이 어느 쪽 entity에 속해야 할지 알아보자

1:N (일대다 관계)

• 근무라는 관계에 근무 시작일 attribute이 있다.
• 일대다 관계에서는 1의 의 반대쪽 entity에 해당 속성이 속하게 하는 것이 맞다.
• 직원이 속해있는 부서는 하나이기 때문에 근무시작일을 물어보았을 때 한 가지 답을 도출할 수 있다.

1:1 (일대일 관계)

• 어디로는 속하게 해도 된다. 서로 1의 반대쪽이기 때문이다. 설계자의 선택 나름이다.

M:N (다대다 관계)

프로젝트 하나에 직원 여러 명, 직원이 참여하는 프로젝트가 여러 개 일 수 있는 관계이다.

여기에서 "주당 근무시간"은 어느 쪽으로 속해져야 할까? 

답은 직원 테이블과 프로젝트 테이블 두 쪽 모두로 옮길 수 없고 참여 관계도 테이블로 만들어 참여의 속성으로 남아야 한다.

 

Attribute

Attribute 종류

• 값의 갯수에 따라
  • Single-valued : 하나만 존재하는 속성
  • Multivalued : 여러 개 존재하는 속성
    ex) 수강 과목 : 미적분, 이산수학 ...
• 원자성에 따라
  • simple: 더 이상 쪼개지지 않음
  • composite : 쪼개짐
    ex) 주소 ->시, 군, 구 로 쪼개진다
    ERD에서 속성 명 밑에 밑줄을 그어 표시
    composite을 쪼개면 여러개의 simple attribute가 생긴다.
• 유도 가능한지에 따라
  • Stored : 일반적인 속성
  • Derived : 저장된 다른 데이터로부터 유도할 수 있는 속성
    그래서 DB에 저장할 필요가 없음. 하지만 너무 많은 쿼리가 생기면 Stored로 저장하기도 함
    ex) 나이는 주민등록번호로부터 뽑아낼 수 있다
    • 점선으로 표시

그래서 한 개의 속성은 3가지의 종류의 속성으로 표현할 수 있다. 예를 들어, 나이는 single-valued, simple, derived attribute 이다.

 

키 속성 : Key Attributes

: 어떤 개체에 대해 항상 유일한(unique)한 값을 갖는 속성

• 복합 키 : Composite Key
  속성들의 집합도 가능
  composite attribute가 키 속성이 되는 경우
  ex) 선수명과 포지션이라는 두 속성을 조합해서 키 속성으로 사용한다
  • 하지만 최소성을 지켜야 한다
    선수명 + 포지션으로 하는 것보다 선수명 + 포지션 + 등번호 로 복합키를 구성하는 것이 더 안전할 수는 있지만 이미 선수명 + 포지션으로 유일함을 구분할 수 있기 때문에 속성을 최소로 사용하도록 한다
• 어떤 개체는 키를 하나 이상 가질 수도 있고 갖지 않을 수도 있음
  • 없는 경우 : Weak Entity(약성 개체)라고 한다.
  • 1개 이상인 경우 : Strong Entity : 일반적인 경우
    2개 이상일 수도 있음 ex)학생이라는 개체에 학번과 주민번호 둘 다 키 속성이 될 수 있다
• 명칭
  • conceptual design에서는 attribute를 Identifier라고 부른다
  • logical design에서는 Primary key라고 부른다
    이 때는 반드시 1개만 있고, 없으면 안 됨

DB를 모델링 순서

할 때 Entity → Relationship → Attribute 순서대로 한다

1. Entity : 주요 개체 도출
2. Relationship : 개체 간 관계 도출
   관계, 대응수 도출
3. 개체 및 관계의 속성 도출
   최대한 weak entity가 만들지 않게끔 
   1. 키 속성 도출
   2. 일반 속성 도출

Weak Entity : 약성 개체

↔ Strong Entity

 

 

약성 개체의 식별자를 만드는 방법은 두 가지가 있다.

1. 약성 개체의 식별자 = 약성개체의 부분 키 + 식별개체의 키 속성
   • 약성개체는 키 속성을 갖지 않고, 부분 키(Partial Key)만을 가진다
   • 그래서 약성 개체는 다른 개체와의 삭별관계(Identifying relationship)으로 맺어져야 한다
2. 일련번호와 같은 식별자 역할을 할 수 있는 속성을 추가한다. 
   • 주민번호, ID 와 같은 속성을 추가하여 식별자 역할을 할 수 있게 한다.

일반적으로 2번의 조치가 더 낫다. weak entity를 굳이 안 만드는 것이 좋다.

 

Notation