데이터베이스 기초 (엔티티, 릴레이션, 속성, 도메인, 필드, 레코드, 키, 테이블간의 관계, 트랜잭션과 무결성을 포함)

엔티티 (Entity)

- 데이터의 집합을 의미한다.

- 저장되고 관리되어야하는 데이터이다.

- 개념, 장소, 사건 등을 가리킨다.

- 유형 또는 무형의 대상을 가리킨다.

 

특징

- 식별자 유일한 식별자를 갖고있어야 한다. (ex. 주민번호, id 등)

- 2개 이상의 인스턴스가 있어야 한다.

- 반드시 속성을 가지고 있어야 한다. (ex. 학생에 학번, 이름, 주소 등)
- 다른 엔티티와 최소 한 개 이상 관계가 있어야 한다. (ex. 학생은 이름을 갖고 있음)
- 업무에서 관리되어야 하는 집합이다. (ex. 학생, 성적)

 

 

종류

1. 유형과 무형에 따른 종류

종류	설명
유형 엔티티	지속적으로 사용되는 엔티티 ex ) 학생, 선생님 등..
개념 엔티티	물리적 형태가 없는 엔티티 개념적으로 사용되는 엔티티 ex) 보험 상품,  조직
사건 엔티티	비즈니스 프로세스를 실행하면서 생성되는 엔티티 ex) 주문, 취소, 수수료 등

 

 

2.발생시점에 따른 엔티티 종류

종류	설명
기본 엔티티 (Basic Entity)	키 엔티티라고도 함 다른 엔티티에 영향을 받지 않는 독립적으로 생성되는 엔티티 ex) 고객, 상품 등...
중심 엔티티 (Main Entity)	기본 엔티티와 행위 엔티티 중간에 있는 것 기본 엔티티로부터 발생되고 행위 엔티티를 생성한다. ex) 주문, 취소, 체결 등...
행위 엔티티 (Active Entity)	2개 이상의 엔티티로부터 발생된다 ex) 주문 내용, 취소 내용 등...

 

 

 

릴레이션

릴레이션이란 관계형 데이터베이스에서 정보를 구분하여 저장하는 기본단위 입니다 . 결국 릴레이션은 DB테이블 입니다.
아래 네모칸 하나하나가 릴레이션입니다.

 

릴레이션의 특징

- 한 릴레이션에는 똑같은 튜플이 포함될 수 없으므로 릴레이션에 포함된 튜플들은 모두 상이 합니다.

- 한 릴레이션에 포함된 튜플 사이에는 순서가 없습니다.

- 튜플들의 삽입, 삭제 등의 작읍으로 인해 릴레이션은 시간에 따라 변합니다.

- 릴레이션 스키마를 구성하는 속성들 간의 순서는 중요하지 않습니다.

- 속성의 유일한 식별을 위해 속성의 명칭은 유일해야하지만, 속성을 구성하는 값은 동일한 값이 있을 수 있습니다.

- 릴레이션을 구성하는 튜플을 유일하게 식별하기 위해 속성들의 부분집합 키로 설정합니다.

- 속성의 값은 논리적으로 더 이상 쪼갤 수 없는 원자 값만을 저장합니다.

 

 

속성 (Attribute)

하나의 릴레션은 현실세계의 어떤 개체를 표현하고 저장하는데 사용됩니다. 이때 개체는 사물이 될 수도 추상적인 개념이 될 수 있습니다.

속성은 내가 저장하고 싶은 개체의 항목들입니다.

 

아래와 같이 고객의 번호, 이름, 전화번호, 집 주소등이 속성이되고 아래와 같이 테이블을 만들 수 있습니다.

결국 하나의 열은 하나의 속성 정보를 표시합니다.

속성 또한 고유한 이름을 가지고 있어 동일 릴레이션 내에서는 같은 이름의 속성이 존재할 수 없다.

 

도메인 (domain)

도메인은 릴레이션에 포함된 속성들이 각각 가질 수 있는 값들의 집합이라 할 수 있습니다.

예를 들어 '안경 착용의 유무' 라는 속성이 있을 때 이 속성이 가질 수 있는 값은 '유' 혹은 '무' 일 것이다.

이 집합 즉 도메인의 이름을 'A' 라고 칭하자.

그럼 '안경 착용의 유무' 라는 속성은 A라는 도메인에 있는 값만 가질 수 있다.

도메인의 이름은 속성 이름과 같을 수도 있고 다를 수도 있다. 또 하나의 도메인을 여러 속성에서 공유할 수도 있다.

 

 

 

필드 (domain) / 레코드 (Record)

필드(field)란 데이터베이스에서 세로 방향으로 표시한 컬럼(Column)을 말한다. 열(列)이라고도 한다. 필드는 DB Table에서 가로로 표시한 레코드 (Record)에 대한 개별적인 속성값을 표시한다. DB 필드라고도 한다. 반대말은 레코드(record)이다.

 

 

키 (key)

- 슈퍼 키(Super Key): 유일성을 만족하는 키. 예를 들면, {학번 + 이름}, {주민등록번호 + 학번}

- 복합 키(Composite Key): 2개 이상의 속성(attribute)를 사용한 키.

- 후보 키(Candidate key): 유일성과 최소성을 만족하는 키. 기본키가 될 수 있는 후보이기 때문에 후보키라고 불린다. 예를 들면, 주민등록번호, 학번 등

- 기본 키(Primary key): 후보 키에서 선택된 키. NULL값이 들어갈 수 없으며, 기본키로 선택된 속성(Attribute)은 동일한 값이 들어갈 수가 없다.

- 대체 키(Surrogate key): 후보 키 중에 기본 키로 선택되지 않은 키.

- 외래 키(Foreign Key): 어떤 테이블(Relation) 간의 기본 키(Primary key)를 참조하는 속성이다. 테이블(Relation)들 간의 관계를 나타내기 위해서 사용된다.

 

 

 

테이블 간의 관계

 

https://nuri-story.tistory.com/171

테이블 간의 관계 (1:1 / 1:M / N:M)

 

 

 

 

 

트랜잭션 , 무결성

- 데이터베이스에서 하나의 논리적 기능을 수행하기 위한 작업의 단위를 말합니다.

- 즉, 여러 개의 쿼리들을 하나로 묶는 단위를 말합니다.

- 특징으로는 원자성, 일관성, 독립성, 지속성이 있습니다.

- 이러한 특징을 ACID 특징이라고 말합니다.

 

 

트랜잭션의 성질

 

 

특징 (ACID)

• 무결성 보장을 위한 트랜잭션이 가져야 할 특성
• Atomicity(원자성) 
  • 트랜잭션 관련 일의 수행 여부를 보장한다.
  • 트랜잭션 수행을 정상적으로 완료시 DB에 모두 반영되도록 커밋한다.
  • 트랜잭션에 하나라도 오류가 발생해 문제가 생길 경우 롤백을 통해 세이브포인트까지 전부 취소한다.
• Consistency(일관성)
  • 시스템의 고정 요소는 트랜잭션 수행 전/후가 같아야 한다.
• Isolation(독립성, 격리성, 순차성)
  • 복수의 트랜잭션 병행 실행시 각각 격리되어 하나만 실행되고 다른건 대기한다(참조 불가 상태).
  • 순차적으로 실행시 성능이 좋지 않으므로 격라 수준을 나누어 격리성을 보장한다.

여러 개의 격리 수준

• Durability(영속성, 지속성)
  • 트랜잭션 완료 후에는 시스템 고장시에도 영구적 반영(및 회복)이 되어야 한다.

 

 

 

무결성

• DB에 저장된 데이터와 현실 값의 일치 정확성

• 개체 무결성: 기본키는 유일성, not null을 만족시켜야 한다.
• 참조 무결성: 외래키는 not null, 참조할 수 없는 외래키 값 x.
  참조한 기본키의 값과 같거나 null이어야 한다.
  그 외의 것은 안된다.
• 도메인 무결성: 값이 정의된 도메인에 속해야 함.
• 그 외에도 사용자 정의 무결성, null 무결성 (not null), 고유 무결성 (튜플 중복x), 키 무결성 (키 반드시 존재), 관계 무결성 등이 있다.

 

 

정규화가 필요한 이유

삽입 이상 (Insertion Anomaly)

새 데이터를 삽입하기 위해 불필요한 데이터도 함께 삽입해야 하는 문제를 삽입이상 이라고 합니다.

예를들어 Key로 지정된 Attribute는 NULL이 될 수 없습니다. 하지만 NULL인 하는 데이터가 있다면 그 데이터는 테이블에 추가될 수 없습니다. 그 데이터를 추가하려면 굳이 'NULL' 용 속성을 따로 만들어서 삽입해야 합니다.

갱신 이상 (Update Anomaly)

중복된 튜플 중 일부만 변경하여 데이터가 불일치하게 되는 모순의 문제를 갱신이상 이라고 합니다.

예를들어 기본키에 종속되어 있는 Attribute가 변경된다면 모두 변경되어야 합니다. 여기서 모두 변경되지 않는 경우 데이터의 모순성이 발생하게 됩니다.

삭제 이상 (Deletion Anomaly)

튜플을 삭제할때 꼭 필요한 데이터 까지 함께 삭제되는 데이터 손실의 문제를 삭제이상 이라고 합니다.

예를들어, 튜플에서 특정 Attribute를 삭제하려고 할 때 그 Attribute가 기본키라면 해당 테이블에 반영하기 위해 모든 행을 삭제해야 합니다.

왜 이런 문제가 발생할까요?

위와 같은 이상현상들이 발생하는 이유는 정규화가 되어 있지 않은 테이블 설계 때문입니다. 코딩할 때에도 관심사를 분리하면 코드의 재사용성과 유지보수의 편의성이 높아지는 것처럼 데이터베이스 설계에서도 비슷한 원칙이 적용됩니다. 데이터베이스 설계의 경우 관심사를 분리하지 않아 생기는 문제는 코드에서의 문제보다 훨씬 치명적입니다.

이론적으로는 정규화를 수행하려면 속성들간의 관련성을 파악해야 하는데, 이 속성들간의 관련성을 함수적 종속성(Functional Dependency) 이라고 합니다. 일반적으로 하나의 릴렝션에는 하나의 함수적 종속성만이 존재하도록 정규화를 하게 됩니다.

 

 

 

 

참고

https://rh-cp.tistory.com/78

[DataBase]엔티티[Entity]란 무엇일까?

 

https://hoyeonkim795.github.io/posts/db-%EC%9A%A9%EC%96%B4/

[Database] 데이터베이스 용어 - 릴레이션, 어트리뷰트, 튜플, 도메인, 차수, 카디널리티, 스키마

 

https://inpa.tistory.com/entry/DB-%F0%9F%93%9A-%ED%82%A4KEY-%EC%A2%85%EB%A5%98-%F0%9F%95%B5%EF%B8%8F-%EC%A0%95%EB%A6%AC

[DB] 📚 데이터베이스 키(KEY) 종류 🕵️ 정리

 

https://korean-otter.tistory.com/215

트랜잭션과 무결성