강의 링크 : https://youtu.be/u0z_lNd3bjg?feature=shared
Query는 질문이다!
- 쿼리를 통해 데이터를 조회, 갱신, 삽입, 삭제 할 수 있음
데이터베이스 스키마(schema)
- 데이터베이스 구조, 데이터 타입, 제약조건에 대한 명세
- 데이터베이스 설계 단계에서 명시되며, 자주 변경되지 않음
- 스키마를 생성하는 것을 데이터베이스 설계(DB design), 데이터 모델링 이라고 함
- 참고로 DB design과 data modeling은 약간 다르지만 해당 강의에서는 둘이 뭉뚱그려 설명하기로 함
- 참고로 DB design과 data modeling은 약간 다르지만 해당 강의에서는 둘이 뭉뚱그려 설명하기로 함
데이터베이스 인스턴스(instance)
- 특정 시점에 데이터베이스에 실제로 저장되어 있는 데이터
- Database instance = Occurrence = Snapshot
빨간색 네모가 인스턴스
SQL(Structured Query Language)
- DML / DDL
- 데이터 정의어 (DDL : Data Definition Language)
- 스키마를 기술하기 위해 사용되며, 주로 DB 설계자가 사용함 (스키마에 사용)
- 데이터 조작어 (DML : Data Manipulation Language)
- 데이터의 조회(Retrieval), 삽입(Insertion), 삭제(Deletion), 갱신(Update)에 사용됨 (인스턴스에 사용)
- cf) DCL(Data Control Language-사용자 권한), TCL(Transaction Control Language)
- 데이터 정의어 (DDL : Data Definition Language)
- SQL에는 DML, DDL, DCL, TCL이 있는데 이 각각은 서로 용도가 다름(그냥 다른 언어라는 것이 아님)
- 독립 실행형 / 내장형
- 독립 실행형
- SQL 인터페이스를 이용하여 SQL 쿼리를 직접 DBMS에 입력
- 내장형
- C, C++, Java 등의 프로그래밍 언어에 내장됨
- Host language + Data sublanguage로 구성됨
- 독립 실행형
DB 설계의 과정
DB 설계는 크게 4 단계로 구분됨 (학교적 구분)
- pre) miniworld 설정 (ex. 학적사항, 성적 등)
- 요구사항 분석
- 업무기술서 작성
- 개념적 설계
- 작성한 업무기술서 도식화
- 대표적 도식화 기법 : Entity-Relationship Model(개체 관계도, ERM)
- 작성한 업무기술서 도식화
- 논리적 설계
- 도식을 컴퓨터에 집어넣는 과정
- 대표적 논리적 설계 기법 : Relational Model(관계형 모델, 테이블화하는 것)
- 도식을 컴퓨터에 집어넣는 과정
- 물리적 설계
- 관계형 모델을 실제로 구현하는 과정
※ 참고로 DB에서는 'relationship'과 'relation'은 서로 다른 용어임
Relationship : ER model에서의 마름모, 네모 등 (강의에서는 이걸 '관계'라고 일컬음)
Relation : Relational model의 테이블
ER Model(개체 관계 모델) Concepts (3가지)
-
개체(Entity)
- 실세계에 존재하는 의미있는 하나의 정보 단위
- 물리적 객체 뿐만 아니라 개념적 객체도 퐇
ex. (학생, 자동차, 강의실, ...) / (프로젝트, 직업, 교과목, ...) - 레코드(해당 개체의 하위 항목 종류)가 최소한 두 개 이상이어야 함
ex. 경북대학교의 학생 DB를 구축할 때 '학교'를 엔티티로 설정할 수 없음. 학교는 경북대 하나 뿐이니까
-
관계(Relationship)
- 개체들 사이의 연관성
ex. |학생|과 |교과목| 사이의 |수강| 관계
개체는 네모로, 관계는 마름모로 그리고 선을 그어 도식화함
※ 어떤 것들은 개체이며 관계인 경우도 있음(예, 결혼). 한편 ER model에서는 애매하지만 Relational DB로 가면 같아짐(고민할 필요 없어짐)
- 개체들 사이의 연관성
-
속성(Attribute)
- 개체 또는 관계의 본질적 성질
- Relational model의 컬럼들 (예, 학번, 나이, 성별 등)
- 인스턴스는 속성값들의 집합으로도 표현됨
학생=개체(entity), 학번 및 혈액형=속성(attribute)
Q) 다음 개체 및 관계에서 주어진 속성의 주인(Owner)은?
해당 속성은 개체뿐만 아니라 관계의 속성이 될 수도 있음
-
'속성'의 종류 (3가지 기준으로 분류)
-
Single-valued vs Multivalued
- 나이 vs 취미
sigle-valued는 동그라미 하나, multivalued는 이중 동그라미로 표현
- 나이 vs 취미
-
Simple vs Composite
- simple attribute : 더 이상 쪼개지지 않는 원자값을 갖는 속성 (예, 나이, 학번, ...)
- composite attribute : 몇 개의 요소로 분해될 수 있는 속성 (예, 주소 - 시, 군, 구, ...)
- simple과 composite attribute는 데이터 사용자의 의도에 따라 달라질 수 있음
- 주소에서 시군구만 사용하면 된다 -> 시군구 데이터는 simple attribute
- 주소에서 시군구는 다시 동면읍으로 쪼개야 한다 -> 시군구 데이터는 composite attribute
simple attribute는 1층 가지, composite attribute는 가지가 뻗어나감
- 위의 그림에서 multivalued이면서 single attribute인 것은 'color'
-
-
Stored vs Derived
- derived attribute : 저장된 다른 데이터로부터 유도 가능한 속성 (예, 각 과목의 성적 -> 총점 및 평균, 주민등록번호 -> 나이, ...)
derived attribute는 점선 동그라미로 표현할 수 있음(그림에 없음)
- 데이터 사용자가 메모리를 아끼고 싶어서 derived attribute를 stored attribute로 사용할 수도 있음 (예, 주민등록번호에서 나이를 계산하기 싫어서 주민등로번호뿐만 아니라 나이라는 속성을 db에 따로 만들어 놓음)
- 실제 실무에서는 derived attribute를 stored attribute로 표현하는 경우가 많고, 학계에서는 store attribute 대신 derived attribute로 표현하는 경우가 많음
- derived attribute : 저장된 다른 데이터로부터 유도 가능한 속성 (예, 각 과목의 성적 -> 총점 및 평균, 주민등록번호 -> 나이, ...)
- 개체 또는 관계의 본질적 성질
-
키 속성(Key Attributes) -> 유일성, 최소성
- 키를 '식별자'라고 부르기도 함
- 어떤 개체에 대해서 항상 유일한 값을 갖는 속성(또는 속성들의 집합)
- 학생의 학번, 책의 ISBN, 자동차의 차량번호 등
- 특정 snapshot이 아닌, 해당 개체의 모든 가능한 snapshot의 집합을 고려하여 파악되어야 함
- 이름은 key attribute일 수도 있고 아닐 수도 있음 (한 집단 내에 동명이인의 유무) -> 이름은 key attribute가 아님
- ER model에서 밑줄로 표현됨
- Conceptual design에서는 키 속성을 'Identifier', logical design에서는 'Key'라고 부름
- 참고로 identifier과 key는 약간 다름(identifier를 갖고 key를 만듦)
- identifier은 개체 당 여러 개 존재할 수 있는데, key는 하나만 존재해야 함(없어도 안 됨)
Q) 다음의 SSN, 이름, 혈액형 중 키 속성을 찾으시오
A : SSN
- 복합 키(Composite Key)
- composite attribute가 키 속성이 되는 경우
- 복합 키는 최소성을 가져야 함
- (팀명, 등번호) vs (팀명, 등번호, 선수명)
- 각 개체는 하나 이상의 키를 가질 수 있음
- 어떤 개체는 키를 갖지 않을 수도 있음 (대부분의 엔티티는 키 속성을 갖고 있음)
- 약성 개체(Weak Entity)
- ER diagram에서 이중 네모로 표현함
- 최대한 줄여야 함
- 키 속성을 임의로 만들어야 함
A : '팀명'과 '등번호'의 조합
- 약성 개체(Weak Entity)
EX) Company DB 설계 예시
요구사항 분석(업무 기술서)을 통해 ER diagram을 도출해야 함
-
지금의 예시와 다른 형태의 DB를 구축할 수도 있음
그 다음 이 ER diagram을 통해 테이블을 만들고, 그 테이블로 실제 DB를 구축하는 것이 DB 설계
-
방법 1 : 엔티티를 먼저 찾은 후, 그 엔티티 간 관계를 찾고, 각 엔티티와 각 관계의 속성을 찾기
-
방법 2(더 쉬움 하지만 추천 X) : 엔티티를 먼저 찾은 후, 각 엔티티의 속성을 먼저 찾고, 거기서 힌트를 얻어 관계를 찾기 ->오늘 해볼 것
- 요구 사항 정리
- Entity 1) 부서 : 부서명, 부서번호, 관리자, 관리시작일, 직원수, 지역
- Entity 2) 프로젝트 : 프로젝트명, 프로젝트번호, 지역, 부서
- Entity 3) 직원 : 이름, 주민번호, 성별, 주소, 급여, 생년월일, 부서, 감독자, (프로젝트, 주당근무시간)
- Entity 4) 부양가족 : 직원, 이름, 성별, 생년월일, 관계
- 정리한 엔티티를 갖고 Initial Schema(초안) 그리기
- 이걸 보고 다른 곳에서 엔티티(상위 개념)으로 존재하는 것들을 속성(하위 개념)으로 낮춰서 도식화한 것을 확인해야 함
계속 수정해 최종 스키마를 만들어야 함
- 빨간 점선 네모 : 쌍으로 같이 다녀야 하는 개념들
- 여기서 힌트) 동일한 개념이 여러 다이어그램에서 등장하면 이걸 '관계'라고 추정해볼 수 있음 (예, 부서가 여러 번 등장하니 '직원'과 '부서'는 관계를 갖지 않을까? 그 외로 관리자-직원, 감독자-직원 등 )
'차수'는 실무에서, '대응수'는 학계에서 사용하는 용어
- 이걸 보고 다른 곳에서 엔티티(상위 개념)으로 존재하는 것들을 속성(하위 개념)으로 낮춰서 도식화한 것을 확인해야 함
관계의 대응수(cardinality)에 대한 설명
실무에서는 관계가 '속성'을 갖는 것을 허용하지 않음
- 실무에서는 관계가 '속성'을 갖는 걸 허용하지 않아서, 관계의 속성인 '근무 시작일'을 다른 엔티티의 속성으로 옮겨야 함
- 1의 대응수 반대편으로 옮겨야 함. 위의 예시에서는 '근무 시작일'을 '직원' 아래로 옮겨야 함. (1:N)
- 양쪽 엔티티가 모두 대응수가 1이면 속성은 어느 엔티티로 옮겨가도 상관 없음 (1:1)
- 양쪽 엔티티의 대응수가 둘 다 1이 아닐 경우, 해당 속성도 엔티티화함 (M:N)
- 테이블화할 때 각 엔티티 당 하나의 테이블이 나옴 (관계는 테이블 x)
- 관계 파악 후 수정된 스키마
각 개체와 관계, cardinality 파악해보기
- 요구 사항 정리
- 실제 DB 설계(ER modeling) 과정
각 개체와 관계, cardinality 파악해보기
※ ER diagram notation 정리
- identifying relationship : weak entity와 의지하는 entity 사이의 관계 (위 refined shcema의 '부양'과 '부양가족' 사이)
※ Weak Entity (보충 설명)
- 약성 개체(weak entity) (<-> strong entity)
- 키 속성을 갖고 있지 않은 개체 -> 부분키(Partial Key)만을 가짐
- 위 그림에서 '이름'(점선 밑줄)이 부분키임
- 약성 개체는 개체를 식별할 수 있는 다른 개체와 식별 관계(identifying relationship)으로 맺어져야 함
- 약성 개체의 식별자는 다음 속성의 조합으로 굿어됨
- 약성 개체의 부분키 속성 + 식별 개체(identifying entity)의 키 속성
ex. B_name + Room_ID -> 경영관 413호
- 약성 개체의 부분키 속성 + 식별 개체(identifying entity)의 키 속성
- 키 속성을 갖고 있지 않은 개체 -> 부분키(Partial Key)만을 가짐
※ N-ary relationships (n > 2) (보충 설명)
하나의 supplier가 하나의 part를 몇 개의 project에 납품할 수 있는가? N
하나의 project에 사용되는 하나의 part는 몇 개의 supplier로부터 공급받을 수 있는가? M
하나의 supplier가 하나의 project를 위해 몇 개의 part를 납품할 수 있는가? P
Ternary relationship의 cardinality의 생성/해석이 어려울 경우(&관계에 속성이 있을 경우), binary relationship으로 변경해 weak entity를 최대한 없애면 좋다. (아래 그림의 아래 diagram)
- Generalization - ERD
여러 엔티티가 있는데 이를 표현하자니 공통된 속성이 많고, 다 합치자니 공통되지 않은 속성도 많다. (예, 대학원생, 대학생, 고등학생의 생년월일, 이름, 성별 등) -> 일반화
- ISA : 역삼각형으로 표시하고 위에서 아래로 읽음. (엔지니어는(ISA) 사람이다)
- 공통 속성을 위(부모)에 두고 고유 속성을 아래(자식)에 둠
- 부모 엔티티의 속성에 키 속성이 있을 경우, 자식 엔티티의 속성에 키 속성이 없어도 괜찮음 (부모 엔티티의 키 속성이 자식 엔티티를 설명할 수 있어서)
