데이터를 검색하다 보면 테이블 하나만을 이용해서는 원하는 정보를 다 가져오지 못하는 경우가 많습니다. 예를 들어 사원의 급여 정보를 검색하는 경우에 [급여] 테이블에는 사원 번호와 급여 정보만 있는 경우 사원 이름을 같이 검색하고자 한다면 사원 이름을 가지고 있는 [사원] 테이블을 참조해야 합니다. 이렇게 테이블을 서로 연결하여 검색을 할 때 사용되는 것이 JOIN 문 입니다.
JOIN의 종류는 다음과 같이 나눌 수 있습니다.
o INNER JOIN o OUTER JOIN o FULL JOIN o CROSS JOIN
이 중에서 가장 많이 사용되는 것이 INNER JOIN 입니다. 다음 [그림 1]을 기준으로 해서 이들 조인의 기능을 살펴보도록 하겠습니다.
[그림 1]
[그림 1]과 같이 [사원] 테이블과 [급여] 테이블이 있습니다. 실제 업무와 다를 수 있지만 조인의 기능을 확인하기 위하여 가정을 하도록 하겠습니다. [사원] 테이블에는 사원 정보가, [대출] 테이블에는 대출 정보가 기록되어 있습니다.
2. INNER JOIN
INNER JOIN은 양쪽의 행들 중에서 서로 연관된 내용만 검색하는 조인 방법입니다. INNER JOIN을 위해서는 우선 [그림 2]처럼 두 테이블에서 공통되지 못한 부분은 JOIN의 대상에서 제외가 됩니다.
[그림 2]
그리고 남아 있는 양쪽의 행들이 다음 [그림 3]과 같이 서로 연관된 행들끼리 결합을 하게 됩니다.
[그림 3]
결국 다음 [그림 4]와 같은 결과를 얻을 수 있게 됩니다.
[그림 4]
위 내용을 INNER JOIN을 이용한 쿼리문으로 표현한다면 다음과 같습니다.
SELECT A.사번, A.이름, B.도서 FROM 사원 A INNER JOIN 대출 B ON A.사번 = B.사번
o 이 쿼리문에서 A와 B 는 [사원] 테이블과 [대출] 테이블을 가리키는 Alias 입니다. o ON 부분을 보면 두 테이블을 '사번' 을 이용하여 연결하고 있습니다.
위 쿼리문은 다음과 같이 표현 할 수도 있습니다.
SELECT A.사번, A.이름, B.도서 FROM 사원 A JOIN 대출 B ON A.사번 = B.사번
즉 'INNER' 를 생략하고 단순히 'JOIN' 만 사용해도 'INNER JOIN'으로 인식됩니다. 이것은 대부분의 JOIN 이 INNER JOIN 이기 때문에 사용자의 편의를 위한 것입니다.
3. OUTER JOIN
OUTER JOIN은 한쪽 테이블을 기준으로 해서 조인을 형성합니다. 그래서 기준이 되는 테이블은 조인되는 테이블과 연관성이 없다 하여도 검색의 대상이 됩니다. 이러한 이유로 OUTER JOIN에는 다음과 같이 두가지의 방법이 존재하게 됩니다.
o LEFT OUTER JOIN (기본값) o RIGHT OUTER JOIN
만일 [사원] 테이블과 [대출] 테이블을 OUTER JOIN 시킬 때 [사원] 테이블을 기준으로 한다면 다음 [그림 5] 와 같은 결과를 얻게 됩니다.
[그림 5]
위 내용을 쿼리문으로 표현한다면 다음과 같습니다.
SELECT A.사번, A.이름, B.도서 FROM 사원 A LEFT OUTER JOIN 대출 B ON A.사번 = B.사번
하지만 [대출] 테이블을 기준으로 한다면 다음 [그림 6] 과 같은 결과를 얻게 됩니다.
[그림 6]
위 내용을 쿼리문으로 표현한다면 다음과 같습니다.
SELECT A.사번, A.이름, B.도서 FROM 사원 A RIGHT OUTER JOIN 대출 B ON A.사번 = B.사번
4. FULL JOIN
FULL JOIN은 [그림 5]와 [그림 6]의 결합이라고 생각하시면 됩니다. 결합이 되는 양쪽 테이블에서 연관성이 없는 행도 조인의 결과에 포함되기 때문입니다. [사원] 테이블과 [대출] 테이블의 FULL JOIN의 결과는 다음 [그림 7]과 같습니다.
[그림 7]
위 내용을 쿼리문으로 표현한다면 다음과 같습니다.
SELECT A.사번, A.이름, B.도서 FROM 사원 A FULL JOIN 대출 B ON A.사번 = B.사번
5. CROSS JOIN
CROSS JOIN은 한쪽 테이블의 모든 행들에 대하여 다른 쪽 행들이 전부 대입이 되는 형태의 조인입니다. 만일 [사원] 테이블과 [대출] 테이블을 CROSS JOIN 시킨다면 [그림 8] 과 같은 각각 대입되어 [그림 9]와 같은 결과를 얻게 됩니다. 단, [그림 8]은 첫번째 행에 대한 대입만을 보여주고 있는데 이러한 대입이 [사원] 테이블의 모든 행에 대하여 이루어지게 됩니다.
[그림 8]
[그림 9]
결국 [사원] 테이블의 행의 갯수 X [대출] 테이블의 행의 갯수 만큼의 행이 CROSS JOIN의 결과를 얻어지게 됩니다.
위 내용을 쿼리문으로 표현한다면 다음과 같습니다.
SELECT A.사번, A.이름, B.도서 FROM 사원 A CROSS JOIN 대출 B
즉, 두 테이블의 연관성이 전혀 필요없게 되므로 ON 절이 포함되지 않습니다.
6. 정리
SELECT 문을 사용 할 때 가장 이해하기 힘든 부분이 JOIN 이 아닌가 싶습니다. JOIN 기능을 잘 익혀 두면 좀더 효율적인 검색을 할 수 있습니다. OUTER JOIN이나 FULL JOIN, CROSS JOIN은 잘 사용이 되지 않습니다. 그 이유는 많은 사람들이 INNER JOIN 까지만 배우고 더이상은 JOIN에 대하여 배우지 않고 무작정 SELECT 문을 사용하기 때문이 아닌가 싶습니다.
다음 강좌에서는 실제로 JOIN을 사용하는 예제를 보면서 다시한번 JOIN에 대하여 살펴볼 예정입니다. 온라인 설명서(Books Online)을 보시면 JOIN에 대한 방대한 량의 설명이 있습니다. 그 내용을 꼭 참고하여 주시기 바랍니다.
[a] InnoDB support for geospatial indexing is available in MySQL 5.7.5 and higher.
[b] InnoDB utilizes hash indexes internally for its Adaptive Hash Index feature.
[c] InnoDB support for FULLTEXT indexes is available in MySQL 5.6.4 and higher.
[d] Compressed MyISAM tables are supported only when using the compressed row format. Tables using the compressed row format with MyISAM are read only.
[e] Compressed InnoDB tables require the InnoDB Barracuda file format.
[f] Implemented in the server (via encryption functions), rather than in the storage engine.
[g] Implemented in the server, rather than in the storage engine.
[h] Implemented in the server, rather than in the storage engine.
쿼리캐시(Query cache)는 타 DBMS에는 없는 MySql의 독특한 기능중 하나입니다.
여러가지 복잡한 처리와 꽤 큰 비용을 들여 실행된 결과를 쿼리 캐시에 담아두고, 동일한 쿼리 요청이 왔을때 간단하게 쿼리 캐시에서 찾아서 바로 결과를 내려줄수 있습니다. 즉, 빈번한 SELECT 쿼리의 성능 향상을 위해 사용합니다. 쿼리 캐시는 단어의 의미와는 달리 SQL문장을 캐시하는 것이 아니라 쿼리의 결과를 메모리에 캐시해두는 기능으로 아래와 같은 특징이 있습니다.
테이블에 변화(INSERT,UPDATE,DELETE)가 일어나게 되면 해당테이블과 관련된 쿼리 캐시내의 쿼리는 초기화
Query_cache_size 환경 변수를 통해서 조절(기본은 비활성화)
SHOW STATUS LIKE 'Qcache_%' 커맨드로 쿼리 캐시 관련 항목 모니터링
RESET QUERY CACHE 커맨드를 통해 수동으로 캐시 삭제 가능
그 밖에 Query_cache_limit(저장 쿼리 사이즈제한) 나 Query_cache_min_res_unit(쿼리 개시 조각화 사이즈) 등과 같은 옵션을 통해 성능 조절이 가능합니다.
아래는 쿼리 캐시를 내려주기 전 확인 과정입니다.
요청된 쿼리문장이 쿼리 캐시에 존재하는가?
해당사용자가 그 결과를 볼수 있는 권한을 가지고 있는가?
트랜젝션 내에서 실행된 쿼리인경우 가시범위 내의 트랜잭션에서 만들어진 결과인가?
쿼리에 사용된 기능(내장 함수나 저장함수등)이 캐시돼도 동일한 결과를 보장할 수 있는가?
CURRENT_DATE(), SYSDATE(), RAND()등과 같이 호출시점에 따라 결과가 달라지는 요소가 있는가?
원자성(Atomicity) - 트래잭션과 관련된 작업들이 모두 수행되었는지 아니면 모두 실행이 안되었는지를 보장하는 능력이다. 자금 이체는 성공할 수도 실패할 수도 있지만 원자성은 중간 단계까지 실행되고 실패하는 일은 없도록 하는 것이다.
일관성(Consistency) - 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것을 의미한다. 무결성 제약이 모든 계좌는 잔고가 있어야 한다면 이를 위반하는 트랜잭션은 중단된다.
격리성(Isolation) - 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것을 의미한다. 이것은 트랜잭션 밖에 있는 어떤 연산도 중간 단계의 데이터를 볼 수 없음을 의미한다. 은행 관리자는 이체 작업을 하는 도중에 쿼리를 실행하더라도 특정 계좌간 이체하는 양 쪽을 볼 수 없다. 공식적으로 고립성은 트랜잭션 실행내역은 연속적이어야 함을 의미한다. 성능관련 이유로 인해 이 특성은 가장 유연성 있는 제약 조건이다.
지속성(Durability) - 성공적으로 수행된 트랜잭션은 영원히 반영되야 함을 의미한다. 시스템 문제, DB 일관성 체크 등을 하더라도 유지되야 함을 의미한다. 전형적으로 모드 트랜잭션은 로그로 남고 시스템 장애 발생 전 상태로 되돌릴 수 있다. 트랜잭션은 로그에 모든 것이 저장된 후에만 commit 상태로 간주될 수 있다.
일관성과 격리성은 쉽게 정의하기 힘들지만, 이 두 가지 속성은 서로 다른 두 개의 트랜잭션에서 동일 데이터를 조회하고 변경하는 경우에도 상호 간섭이 없어야 한다는 것을 의미한다.
InnoDB의 모든 테이블은 기본적으로 Primary Key를 기준으로 클러스터링되어 저장된다. 즉,Primary Key 값의 순서대로 디스크에 저장된다는 뜻이며, 이로 인해 Primary Key에 의한 Range Scan은 상당히 빨리 처리될수 있다. (오라클 DBMS의 IOT(Index Organized Table)와 동일한 구조)
일반적으로 어플리케이션에서는 INSERT나 UPDATE 그리고 DELETE와 같이 데이터를 변경하는 쿼리는 데이터 파일의 이곳저고에 위치한 레코드를 변경하기 때문에 Random I/O 를 발생시킨다. 하지만 버퍼풀이 이러한 변경된 데이터를 모아서 처리하게 되면 Random I/O 작업의 횟수를 줄일수 있다.
MyISAM 키 캐시가 인덱스의 캐시만을 처리하는데 비해, InnoDB의 버퍼 풀은 데이터와 인덱스 모두 캐시 하고 쓰기 버퍼링의 역할 까지 모두 처리한다. 그밖에도 InnoDB의 버퍼 풀은 많은 백그라운드 작업의 기반이 되는 메모리 공간이다. 따라서 버퍼 풀의 크기를 설정하는 파라미터 (innodb_buffer_pool_size) 는 신중하게 설정해야 한다. 일반적으로 전체 장착된 물리 메모리의 50~80% 수준에서 버버풀의 메모리 크기를 결정한다.
언두 영역은 UPDATE문장이나 DELETE와 같은 문장으로 데이터를 변경했을 때 변경되지 전의 데이터(이전 데이터)를 보관하는 곳이다. 특정한 데이터를 변경하였다면 사용자가 커밋시에 현재 상태가 그대로 유지되고 롤백하게 되면 언두 영역의 백업데이터를 다시 데이터 파일로 복구하게 된다. 언두의 데이터는 크게 두가지 용도로 사용되는데, 첫번째 용도가 트랜젝션의 롤백 대비용이다. 두번째 용도는 트랜젝션의 격리 수준을 유지 하면서 높은 동시성을 제공하는데 사용된다.
레코드가 INSERT되거나 UPDATE될때 데이터 파일을 변경하는 작업뿐 아니라 인덱스를 업데이트 하는 작업도 필요하다. 그런데 인덱스를 업데이트 하는 작업은 랜덤 하게 디스크를 읽는 작업을 필요로 하므로 테이블에 인덱스가 많다면 이 작업은 상당히 많은 자원을 소모 하게 된다. 그래서 InnoDB는 변경해야 할 인덱스 페이지가 버퍼 풀에 있으면 바로 업데이트를 수행하지만, 디스크로 부터 읽어 와야 한다면 임시공간에 저장해 두고 바로 사용자에게 결과를 반환하는 형태로 성능을 향상 시키는데, 이때 사용 하는 임시 메모리 공간을 인서트 버퍼(Insert Buffer)라고 한다.
데이터를 변경하고 커밋하면 DBMS는 데이터의 ACID를 보장하기 위해 즉시 변경된 내용을 데이터 파일로 기록해야 한다. 하지만 이러한 데이터 파일 변경작업은 랜덤 하게 디스크에 기록해야 하기 때문에 상당한 자원이 소모된다. 그래서 이러한 부하를 줄이기 위해 대부분의 DBMS에는 변경된 데이터를 버퍼링 해두기 위해 InnoDb 버퍼 풀 과 같은 장치가 포함되어 있다. 하지만 이장치 만으로는 ACID를 보장 할수 없는데 이를 위해 변경된 내용을 순차적으로 디스크에 기록하는 로그 파일을 가지고 있다. 일반적으로 DBMS에서 로그라 하면 이 리두 로그를 지칭하는 경우가 많다.
MVCC의 가장 큰 목적은 잠금을 사용하지 않는 일관된 읽기를 제공하는데 있다. 멀티 버전이라는 것은 하나의 레코드에 대해 여러 개의 버전이 동시에 관리된다는 의미이다. 만약 격리수준이 READ_UNCOMMITED 인 경우 에는 InnoDb 버퍼 풀 이나 데이터 파일로 부터 변경되지 않은 데이터를 읽어서 반환한다. 즉, 데이터가 커밋됐든 아니든 변경된 상태의 데이터를 반환한다. 그렇지 않고 READ_COMMITTED나 그 이상의 격리 수준인 경우에는 아직 커밋되지 않았기 때문에 InnoDB의 버퍼 풀이나 데이터 파일에 있는 내용 대신 변경되기 전의 내용을 보관하고 있는 언두 영역 의 데이터를 반환한다. 이러한 과정을 MVCC라고 표현한다.
트랜젝션이 길어지면 언두에서 관리하는 예전 데이터가 삭제되지 못하고 오랫동안 관리 되어야 하며, 자연히 언두 영역이 저장되는 시스템 테이블 스페이스의 공간이 많이 늘어나야 하는 상황이 발생할수도 있다. 커밋이 된다고 언두 영역의 백업 데이터가 항상 바로 삭제되는것은 아니다. 언두 영역을 필요로 하는 트랜젝션이 더이상 없을때 비로소 삭제된다.
InnoDb에서 격리수준이 SERIALIZABLE이 아닌 경우 순수한 SELECT작업은 다름 트랜젝션의 변경 작업과 관계없이 항상 잠금을 대기 하지 않고 바로 실행 된다. 특정 사용자가 레코드를 변경하고 커밋을 수행하지 않았다 하더라도 이 변경 트랜젝션이 다른 사용자의 SELECT 작업을 방해 하지 않는다. 이를 잠금없는 일관된 읽기 라고 포현하며, 변경되기 전의 데이터를 읽기위해 언두(UnDo)로그를 사용한다. 오랜시간 동안 활성상태인 트랜젝션에 위해 MySql서버가 느려지거나 문제가 발생할때가 잇는데, 바로 이러한 일관된 읽기를 위해 언두 로그를 삭제하지 못하고 계속 유지 하기 때문에 발생하는 문제다. 트랜젝션이 시작 됐다면 가능한 빨리 롤백이나 커밋을 통해 트랜젝션을 완료 하는것이 좋다.
InnoDB의 버퍼풀의 비슷한 역활을 하는 것으로 MyISAM의 키캐시(Key cahe, 키버퍼)가 있다. MyISAM 테이블의 인덱스는 키캐시를 이용해 디스크를 검색하지 않고 검색할 수 있으나 MyISAM 테이블의 데이터는 디스크로부터의 I/O를 해결해 줄만한 어떠한 캐시나 버퍼링 기능이 존재하지 않는다. 따라서 MyISAM 테이블의 데이터 읽기나 쓰기 작업은 항상 운영체제의 디스크로부터 읽고 쓰는 파일에 대한 캐시나 버퍼링 메커니즘을 가지고 있다. 운영체제가 사용할 메모리가 어느정도 보장이 되어야 가능함 MyISAM의 주로 사용되는 키캐시는 물리 메모리의 40% 이상을 넘지 않게 설정하는것이 좋다고한다.
NDB는 Network Database 의 줄미말로 네트워크를 통해 데이터 분산을 지원하는 스토리지 엔진입니다. 부하분산을 하기 위한 방법중 Replication보다는 비교적 최근에 나온 기능입니다. NDB Cluster Storage Engine은 MySQL과는 별도의 프로세스로 동작해 클러스터링을 처리합니다. 결과적으로는 데이터 저장부분만 HA 형태로 운영이 가능한 아키텍처입니다.
MySQL 서버의 바이너리 로그만 클러스터간의 복제를 할수 없고 NDB 클러스터에는 2개 이상의 MySQL 서버가 동시에 쓰기와 읽기용 쿼리를 처리하게된다.
2개 이상의 MySQL 서버로부터 발생한 바이너리 로그를 동시에 발생시점순으로 하나의 슬레이브 MY-SQL 서버로 보낼수 없기 때문에 NDB 클러스터의 데이터 노드는 자기 자신에게 발생한 변경 내용을 SQL 노드로 피드백을 주며 자신의 바이너리 로그를 수정하고 이때 NDB Binlog injector 라는 스레드가 활성화 되는데 이 스레드가 바이너리 로그에 병합하는 역할을 담당한다.
트랜잭션 : 프로젝트 설계자 입장에서 보면 데이터베이스 내에서 하나의 그룹으로 처리해야 하는 명령문들을 모아놓은 작업 단위
트랜잭션 특징
- ACID ■ Atomicity (원자성) : 트랜잭션의 수행은 원자적이다.(All-OR-Nothing 방식) : 트랜잭션의 모든 연산들은 데이터베이스에 정상적으로 수행이 완전히 완료되거나 아니면, 어떠한 연산도 수행되지 않아야한다.
■ Consistency (일관성) : 트랜잭션 실행을 성공적으로 완료하면, 언제나 일관성 있는 데이터베이스 상태로 유지되어야 한다.
■ Isolation (격리성/고립성) : 트랜잭션들이 서로 독립성을 보장받으며 수행될 수 있도록 도와준다. : 다수의 트랜잭션이 동시에 병행 수행되고 있는 경우, 수행 중인 트랜잭션이 완전히 완료될 때까지 다른 트랜잭션에서 현재 수행 중인 트랜잭션의 중간 수행 결과를 참조 할 수 없도록 막아주는 것이다.
■ Durability (영속성/지속성) : 트랜잭션이 모든 작업을 성공적으로 수행 완료하여 데이터베이스 내에 반영했다면, 트랜잭션의 결과는 영구적이어야 한다.
SQL? : Structured Query Language : 사용자와 데이터베이스 시스템 간에 의사소통을 하기 위한 언어
SQL 유형별 종류
- DDL(Data Definition Language) 1. 테이블 이름과 칼럼은 A~Z까지의 문자, 0~9까지의 숫자, 그리고 $,#,_(Under Bar)를 사용할 수 있다. 그러나 공백은 사용할 수 없다. 2. 테이블의 칼럼은 30자를 초과할 수 없고, 예약어를 사용할 수 없다. 3. 한 테이블 안에서 칼럼 이름은 같을 수 없으며 다른 테이블에서의 칼럼 이름과는 같을 수 있다.
NOT NULL: NULL을 허용하지 않음 UNIQUE: 중복된 값을 허용하지 않고, 항상 유일한 값을 갖도록 함 PRIMARY KEY : NULL을 허용하지 않음. 중복된 값을 허용하지 않음, NOT NULL 조건과 UNIQUE 조건을 결합한 형태 UNIQUE: 조건을 결합한 형태 FOREIGN KEY: 참조되는 테이블의 칼럼의 값이 존재하면 허용 CHECK: 저장 가능한 데이터 값의 범위나 조건을 지정해 설정한 값만을 허용 ■ ALTER
정규화(Normalization) 1. 어떤 관계라도 데이터베이스 내에서 표현이 가능하도록 만드는 것 2. 관계에서 바람직하지 않은 삽입, 삭제, 갱신 이상이 발생하지 않도록 한다. 3. 새로운 형태의 데이터가 삽입될 때 관계를 재구성할 필요성을 줄일 수 있다. 4. 보다 간단한 관계 연산에 기초하여 검색을 보다 효율적으로 할 수 있다.
- 이상(anomaly) 현상 : 속성 간에 존재하는 여러 종속 관계를 하나의 릴레이션에 표현함으로써 데이터의 중복으로 인해 발생하는 여러가지 현상 ■ 삭제 이상 : 연쇄삭제에 의한 정보의 손실 ■ 삽입 이상 : 원하지 않는 정보의 강제 삽입
■ 갱신 이상 : 중복 데이터의 일부 갱신으로 정보의 모순성 발생 - 함수 종속 : X가 Y를 결정한다, Y가 X에 의해 결정된다, X는 Y의 결정자이다 : X(determinant)를 결정자, Y를 종속자 : {학번, 과목번호} -> {성적}은 완전 함수 종속(FFD: Full Functional Dependency), {학번} -> {학년}은 부분 함수 종속(PFD: Partial Functional Dependency)
- 정규화 과정 : 일반적으로 데이터베이스를 설계할 때에는 BCNF까지만 고려 : 정규화 과정을 거칠 수록 join 연산으로 인한 성능저하를 가져올 수 있기 때문에 데이터의 정합성과 데이터의 무결성을 우선으로 할지 데이터베이스 구성의 단순화와 성능을 우선으로 할지를 결정 : 반대 개념으로 역정규화
■ 제1정규화(1NF) : 어떤 릴레이션 R에 속한 모든 도메인이 원잣값(atomic value)만으로 되어 있다.
■ 제2정규화(2NF) : 어떤 릴레이션 R이 제1정규형이고, 키에 속하지 않은 속성 모두가 키에 완전 함수 종속 : 무손실 분해
■ 제3정규화(3NF) : 어떤 릴레이션 R이 2NF이고, 모든 속성들이 기본키에 이행적 함수 종석(transitive FD)이 아니면 제3정규형에 속한다. : 이행적 함수 종속성은 A -> B 와 B-> C의 함수 종속성이 존재하면(A->B∧B->C) 속성 C가 이행적으로 A에 종속 (A->C)
관계형 데이터베이스 (Relational Database) - 릴레이션 (Relation)
: 속성, 튜플의 순서는 중요하지 않다. : 속성은 더 이상 쪼갤 수 없는 원자값(atomic value)만을 저장 : 한 릴레이션에 포함된 튜플들은 모두 달라야 한다.
- 차수(degree) : 한 릴레이션을 구성하는 애트리뷰트의 개수 : 릴레이션의 최소 차수는 1 : 자주 바뀌지 않음
- 카디날리티(Cardinality) : 한 릴레이션 내의 튜플의 수 : 릴레이션의 최소 카디날리티의 수는 0 : 시간이 지남에 따라 계속해서 변함
- 도메인(Domain) : 릴레이션에 포함된 각각의 속성들이 취할 수 있는 같은 타입의 원자(atomic) 값들의 집합 - 키(Key) : 한 릴레이션에서 각 튜플을 유일하게 식별하기 위해 사용하는 하나 혹은 그 이상의 속성들의 집합 ■유일성 : 하나의 키 값으로 하나의 튜플만을 유일하게 식별할 수 있는 성격 ■최소성 : 모든 레코드들을 유일하게 식별하는데 꼭 필요한 속성으로만 구성되어야 하는 성격
- 외래키(Foreign key) : 관계를 맺고 있는 릴레이션 R1, R2에서 릴레이션 R1이 참조하고 있는 릴레이션 R2의 기본키와 같은 R1 릴레이션의 속성 : 외래키로 지정되면 참조 테이블의 기본키에 없는 값은 입력할 수 없음.
- 개체 무결성 : 릴레이션에서 기본키를 구성하는 속성은 널(NULL) 값이나 중복 값을 가질 수 없음.
- 참조 무결성 : 외래키 값은 NULL이거나 참조 릴레이션의 기본키 값과 동일해야 함 : 즉, 릴레이션은 참조할 수 없는 외래키 값을 가질 수 없음.
- 엔티티(Entity) : 데이터베이스에 자료로 표현하려는 것 : 개념이나 정보단위 같은 현실 세계의 대상체 : 유형, 무형의 정보 : 서로 연관된 하나 이상의 속성으로 구성 - 속성(Attribute) : 데이터의 가장 작은 논리적 단위 : 각 속성은 엔티티의 특성, 상태 등을 기술
- 관계(Relation) : 데이터의 가장 작은 논리적 단위 : 각 속성은 엔티티의 특성, 상태 등을 기술
데이터베이스 : 여러 사용자가 원하는 정보를 얻기 위해서 모아둔 자료의 집합, 관련있는 데이터들의 집합
데이터베이스 관리 시스템(DBMS) : 데이터를 편리하게 저장하고 효율적으로 관리하고 검색할 수 있는 환경을 제공해주는 소프트웨어 : 데이터베이스의 생성과 관리를 담당하는 소프트웨어 패키지 : 정의, 조작, 제어 기능
데이터베이스 시스템(DBS) : 데이터베이스를 통해 데이터를 저장하고 관리하기 위한 목적으로 사용되는 일체의 시스템 : 데이터베이스와 그를 관리하는 소프트웨어(DBMS, 응용 프로그램) 모두를 칭하는 용어
스키마(Schema) : 데이터 구조와 제약조건에 대한 명세(specification)를 기술하는 것 : 개체(entity), 속성(attribute), 관계(relationship)에 대한 정의와 이들이 유지해야 될 제약 조건(constraints)을 포함 : 3단계 데이터베이스 구조
데이터베이스 시스템의 구성요소
데이터베이스 언어
- 데이터 정의어(DDL) : 스키마를 정의하거나 수정할 목적으로 사용 : CREATE, ALTER, DROP
- 데이터 조작어(DML) : 데이터베이스 내의 데이터 연산을 위한 언어 : INSERT, UPDATE, DELETE
- 데이터 제어어(DCL) : 데이터베이스 내의 데이터를 올바르고 정확하게 유지 : 보안, 무결성, 데이터 회복, 병행수행
