1. 엔터티 , 릴레이션, 속성, 도메인
데이터베이스(database, DB)는 일정한 규칙, 혹은 규약을 통해 구조화되어 저장되는 데이터의 모음.
해당 데이터베이스를 제어, 관리하는 통합 시스템을 DBMS(Database Management System)이라고 하며 데이터베이스 안에 있는 데이터들은 특정 DBMS마다 정의된 쿼리 언어(query language)를 통해 삽입 삭제 수정 조회 ( CRUD ) 를 수행할 수 있음.
또한 데이터베이스는 실시간 접근과 동시 공유가 가능합니다.
다음 그림처럼 데이터베이스 위에 DBMS가 있고 그 위에 응용프로그램이 있으며, 이러한 구조를 기반으로 데이터를 주고 받습니다.
예를 들어 MySQL 이라는 DBMS가 있고 그 위에 응용프로그램에 속하는 node.js 나 php에서 해당 데이터베이스 안에 있는 데이터를 끄집어내 해당 데이터 관련 로직을 구축할 수 있습니다.
엔터티 ( Entity )
엔터티(Entity)는 사람, 장소, 물건, 사건, 개념 등 여러 개의 속성을 지닌 명사를 의미합니다.
예를 들어서 회원이라는 엔터티가 있다고 가정하면 회원은 이름, 아이디, 주소 , 전화번호 등의 속성을 갖습니다.
물론 이보다 많은 속성이 있지만 서비스의 요구 사항에 맞춰 엔터티의 속성이 정해집니다.
예를 들어 주소라는 속성이 서비스의 요구 사항과 무관한 속성이라면 주소라는 속성은 사라지게 됩니다.
+ 약한 엔터티와 강한 엔터티
A가 혼자서는 존재하지 못하고 B의 존재 여부에 따라 종속적이라면 A는 약한 엔터티이고 B는 강한 엔터티가 됩니다.
예를 들어서 방은 건물 안에만 존재하기 때문에 방은 약한 엔터티라고 할 수 있고 건물은 강한 엔터티라고 할 수 있습니다.
릴레이션 ( Relation )
릴레이션(Relation)은 데이터베이스에서 정보를 구분하여 저장하는 기본 단위입니다.
엔터티에 관한 데이터를 데이터베이스는 릴레이션 하나에 담아서 관리합니다.
다음 그림처럼 회원이라는 엔터티가 데이터베이스에서 관리될 때 릴레이션으로 변화된 것을 볼 수 있습니다.
릴레이션은 관계형 데이터베이스에서는 '테이블'이라고 하며, NoSQL 데이터베이스에서는 '컬렉션'이라고 합니다.
MySQL 의 구조는 레코드 - 테이블 - 데이터베이스
NoSQL 의 구조는 도큐먼트 - 컬렉션 - 데이터베이스
속성
속성(attribute)은 릴레이션에서 관리하는 구체적이며 고유한 이름을 갖는 정보입니다.
예를 들어서 '차'라는 엔터티의 속성을 뽑아보면 '차 번호' , '바퀴 수', '차 색깔', '차종' 등이 있습니다.
이 중에서 서비스의 요구 사항을 기반으로 관리해야 할 필요가 있는 속성들만 엔터티의 속성이 됩니다.
도메인
도메인(domain)이란 릴레이션에 포함된 각각의 속성들이 가질 수 있는 값의 집합을 말합니다.
예를 들어서 성별이라는 속성이 가질 수 있는 값은 남,여 라는 집합이 됩니다.
2. 필드 , 레코드, 타입
필드 타입
필드는 타입을 갖습니다. 예를 들어 이름은 문자열이고 전화번호는 숫자겠죠? 이러한 타입들은 DBMS마다 다르며 이 책에서는 MySQL을 기준으로 설명하겠습니다.
숫자 타입 → TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT 등이 있음
날짜 타입 → DATE , DATETIME , TIMESTAMP 등이 있음
DATE → 날짜 부분은 있지만 시간은 없는 값
DATETIME → 날짜 및 시간 부분을 모두 포함하는 값에 사용 ( 객체 , 8바이트 )
TIMESTAMP → 날짜 및 시간 부분을 모두 포함하는 값에 사용 ( 카운트값, 4바이트 )
문자 타입 → CHAR , VARCHAR 은 모두 그 안에 수를 입력해서 몇 자까지 입력할지 정해야 합니다.
CHAR → ( CHAR(30) 이런 식으로 선언 ) 테이블을 생성할 때 선언한 길이로 고정되며 길이는 0에서 255사이의 값을 가짐. 레코드를 저장할 때 무조건 선언한 길이 값으로 ‘고정'해서 저장됩니다.
VARCHAR → 가변 길이 문자열. 길이는 0에서 65,535 사이의 값으로 지정할 수 있으며, 입력된 데이터에 따라 용량을 가변시켜 저장합니다. 예를 들어 10바이트의 이메일을 저장할 경우 10바이트에 해당하는 바이트 + 길이 기록용 1바이트로 저장하게 됩니다. VARCHAR(10000)으로 선언했음에도 말이죠.
CHAR의 경우 유동적이지 않은 길이를 가진 데이터의 경우 효율적이며
VARCHAR의 경우 유동적인 데이터의 경우 효율
3. 관계 , 키
관계 ( Relation )
관계란 데이터베이스에 테이블은 하나만 있는 것이 아닙니다. 여러 개의 테이블이 있고 이러한 테이블은 서로의 관계가 정의되어 있죠.
이러한 관계를 관계 화살표로 나타냅니다.
1:1 관계 → 예를 들어 유저당 유저 이메일은 한 개씩 있으면 1:1 관계를 가집니다.
1:N 관계 → 예를 들어 쇼핑몰에서 한 유저당 여러 개의 상품을 장바구니에 넣을 수 있다. 이 경우 1:N 관계가 됩니다. 물론 하나도 넣지 않은 경우도 있으니 0도 포함되는 화살표를 통해 표현해야 합니다. 이렇게 한 개체가 다른 많은 개체를 포함하는 관계.
N:M 관계 → 학생과 강의의 관계. 학생도 강의를 많이 들을 수 있고 강의도 여러 명의 학생을 포함할 수 있음.
- 키 → 테이블 간의 관계를 조금 더 명확하게 하고 테이블 자체의 인덱스를 위해 설정된 장치로 기본키, 슈퍼키, 후보키, 대체키, 외래키가 있습니다.
- 슈퍼키 : 유일성
- 후보키 : 유일성 + 최소성
- 후보키 중에서 기본키로 선택받지 못한 키는 대체키가 됩니다.
- 유일성은 중복되는 값은 없으며, 최소성은 필드를 조합하지 않고 최소 필드만 써서 키를 형성할 수 있는 것을 말합니다.
- 기본키(Primart key) : pk 또는 프라이머리키라고 많이 부르며, 유일성과 최소성을 만족하는 키입니다.
- 자연키 : 예를 들어 유저 테이블을 만든다고 가정하면 주민등록번호, 이름, 성별 등의 속성이 있습니다. 이 중 이름, 성별 등은 중복된 값이 들어올 수 있으므로 부적절하고 남는 것은 주민 등록번호입니다. 이런 식으로 중복된 값들을 제외하며 중복되지 않는 것을 ‘자연스럽게' 뽑다가 나오는 키를 자연키라고 합니다. 자연키는 언젠가는 변하는 속성을 가집니다.
- 인조키 : 유저 테이블을 만든다고 했을 때, 회원 테이블을 생성하고 주민등록 번호, 이름, 성별 등의 속성이 있습니다. 여기에 인위적으로 유저 아이디를 부여합니다. 이를 통해 고유 식별자가 생겨납니다. 자연키와는 대조적으로 변하지 않습니다. 따라서 보통 기본키는 인조키로 설정합니다.
- 외래키(Foreign Key) : FK 라고도 하며, 다른 테이블의 기본키를 그대로 참조하는 값으로 개체와의 관계를 식별하는 데 사용합니다. 외래키는 중복되어도 상관없습니다.
- 후보키 ( candidate key ) : 기본키가 될 수 있는 후보키.
- 대체키 (alternate key) : 후보키가 두 개 이상일 경우 어느 하나를 기본키로 지정하고 남은 후보키들을 말합니다
- 슈퍼키(super key) : 슈퍼키는 각 레코드를 유일하게 식별할 수 있는 유일성을 갖춘 키입니다.