검수요청.png검수요청.png

"테이블 (데이터베이스)"의 두 판 사이의 차이

위키원
이동: 둘러보기, 검색
잔글
(테이블 생성)
 
(사용자 2명의 중간 판 20개는 보이지 않습니다)
1번째 줄: 1번째 줄:
'''테이블'''(table)은 [[데이터베이스]]에서 [[행]](가로, row, record)과 [[열]](세로, column, field)로 짜여진 표에 기록된 [[데이터]]의 집합이다.
+
'''테이블'''(table)은 [[데이터베이스]]에서 [[행]](가로, row, record)과 [[열]](세로, column, field)로 짜여진 표에 기록된 [[데이터]]의 집합이다. '''디비 테이블'''(DB table)이라고도 한다.
  
 
== 개요 ==
 
== 개요 ==
테이블이란 데이터베이스에서 단일 주제에 관해 행과 열로 구성되는 정보 모음을 가리킨다. 예를 들면, 업무용 데이터베이스는 대개 고객 정보에 관한 테이블을 가지고 있는데, 고객의 계정 번호, 주소, 전화번호 등을 저장할 수 있는 여러 개의 행으로 구성된다. 테이블 내에서 계정 번호 등과 같은 낱낱의 데이터 각각을 필드라고 부른다. 하나의 행은 모든 고객들의 전화 번호 등과 같은 어떤 한 필드 내의 모든 데이터로 구성된다. 필드는 완전한 정보 셋인 레코드로 조직화되며, 각각은 하나의 열을 이룬다. 표준화 과정을 통해 데이터를 가장 효과적인 방법으로 테이블로 구성할 수 있는 방법을 결정한다.
+
테이블이란 데이터베이스에서 단일 주제에 관해 행과 열로 구성되는 정보 모음을 가리킨다. 예를 들면, 업무용 데이터베이스는 대개 고객 정보에 관한 테이블을 가지고 있는데, 고객의 계정 번호, 주소, 전화번호 등을 저장할 수 있는 여러 개의 행으로 구성된다. 테이블 내에서 계정 번호 등과 같은 낱낱의 데이터 각각을 [[필드 (데이터베이스)|필드]](field)라고 부른다. 하나의 행은 모든 고객들의 전화 번호 등과 같은 어떤 한 필드 내의 모든 데이터로 구성된다. 필드는 완전한 정보 셋인 레코드로 조직화되며, 각각은 하나의 열을 이룬다. 표준화 과정을 통해 데이터를 가장 효과적인 방법으로 테이블로 구성할 수 있는 방법을 결정한다.
  
 
컴퓨터로 만들어지거나 또는 종이 위에 손쉽게 그릴 수 있는 진리표에는 기반이 되는 결정이나 기준 목록을 포함한다. 진리표에는 가능한 모든 결정 상황이 목록화되며, 각 상황에서 취해져야 할 행위가 정의된다. 기본적인 예로는, 도로 교차점의 교통 상황에 대하여 "예" 또는 "아니오"와 같은 결정들과 빨간색 신호나, 녹색 신호 등과 같이 기준들이 표현될 수 있다. 진리표는 여러 가지 상황에서 내려지는 결정에 따라 처리 기준을 지시하기 위한 컴퓨터 프로그램에도 삽입될 수 있다. 진리표가 변경되면 프로그램에도 반영된다.<ref name='table_info'>김동근, 〈[http://www.terms.co.kr/table.htm table 테이블]〉, 《김동근의 텀즈, 컴퓨터 용어사전》, 2002-06-17</ref>
 
컴퓨터로 만들어지거나 또는 종이 위에 손쉽게 그릴 수 있는 진리표에는 기반이 되는 결정이나 기준 목록을 포함한다. 진리표에는 가능한 모든 결정 상황이 목록화되며, 각 상황에서 취해져야 할 행위가 정의된다. 기본적인 예로는, 도로 교차점의 교통 상황에 대하여 "예" 또는 "아니오"와 같은 결정들과 빨간색 신호나, 녹색 신호 등과 같이 기준들이 표현될 수 있다. 진리표는 여러 가지 상황에서 내려지는 결정에 따라 처리 기준을 지시하기 위한 컴퓨터 프로그램에도 삽입될 수 있다. 진리표가 변경되면 프로그램에도 반영된다.<ref name='table_info'>김동근, 〈[http://www.terms.co.kr/table.htm table 테이블]〉, 《김동근의 텀즈, 컴퓨터 용어사전》, 2002-06-17</ref>
11번째 줄: 11번째 줄:
 
=== 행(row) ===
 
=== 행(row) ===
 
* '''레코드'''(record), '''튜플'''(tuple) : 릴레이션이 나타내는 [[엔티티]](entity)의 특정 인스턴스에 관한 사실(값)들의 모임이다. 튜플로 통용된다.
 
* '''레코드'''(record), '''튜플'''(tuple) : 릴레이션이 나타내는 [[엔티티]](entity)의 특정 인스턴스에 관한 사실(값)들의 모임이다. 튜플로 통용된다.
* '''카디날리티'''(cardinality) : 릴레이션 튜플의 개수<ref name='rdb_info'>돌딱, 〈[https://blog.naver.com/96wjdduf/221860693470 관계형 데이터베이스의 구조]〉, 2020-03-18일</ref>
+
* '''카디날리티'''(cardinality) : 릴레이션 튜플의 개수<ref name='rdb_info'>돌딱, 〈[https://blog.naver.com/96wjdduf/221860693470 관계형 데이터베이스의 구조]〉, 2020-03-18</ref>
  
 
=== 열(column) ===
 
=== 열(column) ===
 
* '''[[속성]]'''(attribute) : 하나의 릴레이션은 현실세계의 어떤 개체(entity)를 표현하고 저장되는 데 사용된다. 이때 개체는 사물이 될 수도, 추상적인 개념이 될 수도 있다.
 
* '''[[속성]]'''(attribute) : 하나의 릴레이션은 현실세계의 어떤 개체(entity)를 표현하고 저장되는 데 사용된다. 이때 개체는 사물이 될 수도, 추상적인 개념이 될 수도 있다.
* '''[[필드]]'''(field) : 종종 컬럼의 대용으로 동일한 의미로 사용되지만, 필드와 필드값은 한 열이나 한 컬럼 사이의 교차로 존재하는 단일 항목을 특정할 때 언급하는 것이다.
+
* '''[[필드 (데이터베이스)|필드]]'''(field) : 종종 컬럼의 대용으로 동일한 의미로 사용되지만, 필드와 필드값은 한 열이나 한 컬럼 사이의 교차로 존재하는 단일 항목을 특정할 때 언급하는 것이다.
 
* '''[[차수]]'''(degree) : 한 릴레이션에 들어 있는 속성의 수<ref name='rdb_info'></ref>
 
* '''[[차수]]'''(degree) : 한 릴레이션에 들어 있는 속성의 수<ref name='rdb_info'></ref>
  
22번째 줄: 22번째 줄:
  
 
=== 릴레이션 인스턴스 ===
 
=== 릴레이션 인스턴스 ===
[[릴레이션 인스턴스]](relation instance)란 데이터 개체를 구성하고 있는 속성들에 데이터 타입이 정의되어 구체적인 데이터 값을 갖고 있는 것을 말한다.<ref>개발자, 〈[https://blog.naver.com/kookh1/120184872122 릴레이션의 특징과 용어]〉, 2013년3월16일</ref>
+
[[릴레이션 인스턴스]](relation instance)란 데이터 개체를 구성하고 있는 속성들에 데이터 타입이 정의되어 구체적인 데이터 값을 갖고 있는 것을 말한다.<ref>개발자, 〈[https://blog.naver.com/kookh1/120184872122 릴레이션의 특징과 용어]〉, 2013-03-16</ref>
  
 
=== 관계형 데이터베이스 구조 ===
 
=== 관계형 데이터베이스 구조 ===
 
[[파일:릴레이션_구조.png|image]]<ref name='rdb_info'></ref>
 
[[파일:릴레이션_구조.png|image]]<ref name='rdb_info'></ref>
  
== 세부항목 ==
+
== SQL에서 테이블 활용 ==
=== 엔티티 ===
+
=== 테이블 생성===
[[엔티티]](entity)는 데이터베이스에 표현하려고 하는 유형, 무형의 객체로서 서로 구별되는 것을 뜻한다. 이 개체는 현실 세계에 대해 사람이 생각하는 개념이나 정보의 단위로서 의미를 가지고 있다. 이것은 컴퓨터가 취급하는 파일의 레코드(record)에 대응한다. 이 개체는 그 단독으로 존재할 수 있으며, 정보로서의 역할을 한다. 하나의 개체는 하나 이상의 속성, 즉 [[속성]](attribute)으로 구성되고 각 속성은 그 개체의 특성이나 상태를 기술해 준다. 예를 들어, 학생이라는 개체는 학번, 이름, 학과라는 3개의 속성들로 구성되어 있다. 이 때 학번, 이름, 학과는 학생이라는 개체가 가지고 있는 특성, 즉 값을 나타내고 있는 것이다. 이와 같이 속성, 즉 속성이라고 하는 것은 이름을 가진, 데이터의 가장 작은 논리적 단위가 된다. 보통 파일 구조에서는 데이터 항목(data item) 또는 필드(field)라고도 한다. 정보의 측면에서 볼 때 이 속성은 그 자체만으로는 중요한 의미를 표현하지 못하기 때문에 단독으로 존재하지는 못한다. 앞의 예에서 각 속성들 즉, 학번, 이름, 학과는 개별적으로는 우리에게 어떤 정보를 제공해 주지 못하지만 이것들이 모여 학생이라는 개체를 구성해서 표현할 때는 큰 의미를 제공하고 있다. 물론 각 속성이 갖는 값은 시간에 따라 변할 수도 있다. 일반적으로, 한 속성이 취할 수 있는 모든 값을 총칭해서 도메인(domain)이라 한다.<ref>환, 〈[http://blog.naver.com/PostView.nhn?blogId=jjhstr&logNo=60097939589&proxyReferer=https:%2F%2Fwww.google.com%2F DB에서 entity란?]〉, 2009-12-24</ref>
 
  
==== 엔티티의 특징 ====
+
  CREATE TABLE 테이블 이름 (
* 반드시 엔티티가 사용되는 곳의 업무에서 필요하며 관리하고자 하는 정보 엔티티가 포함하는 인스턴스에 대해 유일한 식별자로 식별이 가능해야 한다.
+
        컬럼명1 DATATYPE [DEFAULT 형식],
* 엔티티는 지속적으로 존재하는 두개 이상의 인스턴스들의 조합이어야 한다.
+
        컬럼명2 DATATYPE [DEFAULT 형식],
* 엔티티는 반드시 속성을 지녀야 한다.
+
        컬럼명3 DATATYPE [DEFAULT 형식]
* 엔티티는 업무 프로세스에 의해서 이용되어야 한다.
+
  );
* 엔티티는 다른 엔티티와 최소 한 개 이상의 관계가 있어야 한다.<ref name='entity_info2'>Tigercow, 〈[https://doorbw.tistory.com/227 엔터티(ENTITY)와 속성(ATTRIBUTE)]〉, 2020-01-13</ref>
 
  
==== 엔티티의 분류 ====
+
:테이블 생성시 대/소문자 구분은 하지 않는다. (기본적으로 테이블이나 컬럼명은 대문자로 만들어진다.)
; 실체유형(유무형)에 따른 분류
+
:DATE 유형은 별도로 크기를 지정하지 않는다.
* 유형 엔티티(Tangible Entity)
+
:문자 데이터 유형은 반드시 가질 수 있는 최대 길이를 표시해야 한다.
:물리적인 형태가 존재하는 엔티티이며 안정적이고 지속적으로 활용되는 엔티티이다.
+
:컬럼과 컬럼의 구분은 콤마로 하되, 마지막 컬럼은 콤마를 찍지 않는다.
* 개념 엔티티(Conceptual Entity)
+
:컬럼에 대한 제약조건이 있으면 CONSTRAINT를 이용하여 추가할 수 있다.<ref name='constraint'>개발이 하고 싶어요, 〈[https://hyeonstorage.tistory.com/291 CREATE TABLE 테이블 생성, 제약조건(CONSTRAINT), 확인(DESC)]〉, 2014-05-29</ref>
:물리적인 형태는 존재하지 않고 관리해야 할 개념적인 정보로 구분이 되는 엔티티이다.
 
*사건 엔티티(Event Entity)
 
:업무를 수행함에 따라 발생되는 엔티티이다.<ref name='entity_info2'></ref>
 
  
; 발생시점에 따른 분류
+
=== 테이블 수정 ===
* 기본/키 엔티티(Fundamental/Key Entity)
 
:해당 업무에 원래 존재하는 정보로 다른 엔티티와의 관계에 의해 발생 또는 생성되지 않고 독립적으로 존재하는 엔티티이다. 이는 독립적으로 생성이 가능하며 다른 엔티티의 부모역할을 한다.
 
* 중심 엔티티(Main Entity)
 
:기본 엔티티로부터 발생되며 업무에 있어서 중심적인 역할을 한다. 일반적으로 데이터 양이 많으며 다른 엔티티와의 관계를 통해 행위 엔티티를 생성한다.
 
*행위 엔티티(Active Entity)
 
:두 개이상의 부모 엔티티로 부터 주로 발생되고, 자주 엔티티의 내용이 바뀌거나 데이터양이 증감한다. 분석초기 단계보다는 상세 설계단계나 프로세스와 상관모델링을 진행하면서 도출될 수 있다.<ref name='entity_info2'></ref>
 
  
; 엔티티의 명명
+
  ALTER TABLE 테이블명;
엔티티의 이름을 정하는 데에 있어서는 다음과 같은 원칙을 지켜야 한다.
 
:가능하면 현업 업무에서 사용하는 용어를 사용한다.
 
:가능하면 약어를 사용하지 않는다.
 
:단수 명사를 사용한다.
 
:모든 엔티티를 통틀어서 유일한 이름을 가져야 한다.
 
:엔티티의 생성 의미대로 이름을 부여한다.<ref name='entity_info2'></ref>
 
  
=== 릴레이션 ===
+
=== 테이블 삭제 ===
[[릴레이션]](relation)은 주로 테이블(Table)과 같은 의미로 사용되며, 데이터의 집합을 의미한다. [[튜플]](tuple)과 [[속성]](attribute)로 구성되어 있다.<ref name='relation_info'>글그리,〈[https://eastroot1590.tistory.com/entry/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%9A%A9%EC%96%B4-%EB%A6%B4%EB%A0%88%EC%9D%B4%EC%85%98Relation 데이터베이스 - 릴레이션(Relation)]〉, 2017년3월9일</ref>
+
  DROP TABLE 테이블명 [CASCADE CONSTRAINT];
  
==== 릴레이션의 특징 ====
+
:DROP TABLE 명령어를 사용하면 테이블의 모든 데이터 및 구조를 삭제한다.
* 릴레이션에 포함된 튜플들은 모두 다르다.
+
:CASCADE CONSTRAINT 옵션은 해당 테이블과 관계가 있었던 참조되는 제약조건에 대해서도 삭제한다는 것을 의미한다.
* 릴레이션에 포함된 튜플 사이에는 순서가 없다.
+
:(SQL Server에서는 CASCADE 옵션이 존재하지 않는다. 테이블 삭제 전에 참조하는 FOREIGN KEY 제약 등을 먼저 삭제해야 한다.)<ref name='constraint'></ref>
* 튜플들의 삽입, 삭제등의 작업으로 인해 릴레이션은 시간에 따라 변한다.
 
* 릴레이션 스키마를 구성하는 속성들 간의 순서는 중요하지 않다.
 
* 속성의 유일한 식별을 위해 속성의 명칭은 유일해야 하지만, 속성을 구성하는 값은 동일한 값이 나올 수 있다.
 
* 릴레이션을 구성하는 튜플을 유일하게 식별하기 위해 속성들의 부분집합을 키로 설정한다.
 
* 속성은 더 이상 쪼갤 수 없는 원자 값만을 저장한다.<ref name='relation_info'></ref>
 
  
==== 릴레이션 스키마 ====
+
=== 테이블 목록 조회 ===
릴레이션 스키마는 릴레이션에 어떤 정보가 담길지를 정의한다. 도서 릴레이션은 도서번호, 도서이름, 출판사, 가격이라는 정보를 정의하고 있는데, 각 열을 속성(attribute)이라고 한다. 속성에는 각각의 이름이 있으며 우리는 그 이름을 보고 어떤 정보가 담기는 알 수 있다. 하지만 컴퓨터는 속성만으로 어떤 타입의 데이터인지 알 수 없다. 따라서 각 속성들이 어떤 값을 가질 수 있는지를 도메인(domain)이라는 용어를 사용하여 정의한다. 또한 릴레이션이 몇 개의 속성을 가지는가를 나타내기 위해 차수(degree)라는 용어를 사용한다.<ref name='relation_info2'>무니봇, 〈[https://moonibot.tistory.com/37 릴레이션 스키마(Relation Schema), 릴레이션 인스턴스(Relation Instance), 속성(Attribute), 튜플(Tuple)]〉, 2019-12-17</ref>
+
  SHOW TABLES;
  
[[파일:릴레이션 스키마 인스턴스.png|썸네일|700픽셀|릴레이션 스키마와 인스턴스]]<ref name='relation_info2'></ref>
+
=== 테이블 조회 ===
 +
  SELECT * FROM 테이블명;
  
==== 릴레이션 인스턴스 ====
+
=== 컬럼 추가 (ADD COLUMN) ===
릴레이션 인스턴스는 릴레이션 스키마에 실제로 저장된 데이터의 집합이다. 도서 릴레이션을 보면 도서번호가 1부터 5까지 총 다섯 권의 데이터가 저장된 것을 알 수 있다. 릴레이션에서 행을 튜플(tuple)이라고 한다. 튜플은 릴레이션 인스턴스의 각각의 행을 나타낸다. 각 튜플의 속성 값은 스키마에서 정의한 도메인 값으로 구성되며 튜플이 가지는 속성의 개수는 스키마의 차수와 동일하다. 또한 릴레이션 내의 모든 튜플들은 서로 중복되지 않아야 한다. 릴레이션에 저장된 튜플의 수를 카디날리티라고 한다. 카디날리티는 튜플의 삽입, 삭제, 수정 등에 따라 수시로 변한다.<ref name='relation_info2'></ref>
 
  
=== 뷰 ===
+
  ALTER TABLE 테이블명
[[뷰]](view)는 사용자에게 접근이 허용된 자료만을 제한적으로 보여주기 위해 하나 이상의 기본 테이블로부터 유도된, 이름을 가지는 가상 테이블이며 저장장치 내에 물리적으로 존재하지 않지만 사용자에게 있는 것처럼 간주되고 데이터 보정작업, 처리과정 시험 등 임시적인 작업을 위한 용도로 활용된다. 뷰는 조인문의 사용 최소화로 사용상의 편의성을 최대화한다.<ref name='view_info'>코딩팩토리, 〈[https://coding-factory.tistory.com/224 뷰(View)란 무엇인가? + 간단한 예제]〉, 2018-08-18</ref>
+
  ADD 추가할 컬럼명  데이터 유형; <ref name='constraint'></ref>
  
; 뷰의 특징
+
=== 컬럼 수정 (MODIFY COLUMN) ===
* 기본 테이블로부터 유도된 테이블이기 때문에 기본 테이블과 같은 형태의 구조를 사용하며, 조작도 기본 테이블과 거의 같다.
 
* 가상 테이블이기 때문에 물리적으로 구현되어 있지 않다.
 
* 데이터의 논리적 독립성을 제공할 수 있다.
 
* 필요한 데이터만 뷰로 정의해서 처리할 수 있기 때문에 관리가 용이하고 명령문이 간단해진다.
 
* 뷰를 통해서만 데이터에 접근하게 하면 뷰에 나타나지 않는 데이터를 안전하게 보호하는 효율적인 기법으로 사용할 수 있다.
 
* 기본 테이블의 기본키를 포함한 속성() 집합으로 뷰를 구성해야지만 삽입, 삭제, 갱신, 연산이 가능하다.
 
* 일단 정의된 뷰는 다른 뷰의 정의에 기초가 될 수 있다.
 
* 뷰가 정의된 기본 테이블이나 뷰를 삭제하면 그 테이블이나 뷰를 기초로 정의된 다른 뷰도 자동으로 삭제된다.<ref name='view_info'></ref>
 
  
; 뷰의 장·단점
+
  ALTER TABLE 테이블명
* 장점
+
  MODIFY COLUMN 수정할 컬럼명;
:논리적 데이터 독립성을 제공한다.
 
:동일 데이터에 대해 동시에 여러사용자의 상이한 응용이나 요구를 지원해 준다.
 
:사용자의 데이터 관리를 간단하게 해준다.
 
:접근 제어를 통한 자동 보안이 제공된다.
 
  
* 단점
+
:MODIFY COLUMN 사용 시 주의사항
:독립적인 인덱스를 가질 없다.
+
::해당 컬럼의 크기를 늘릴 수는 있지만 줄이지는 못한다. 이는 기존의 데이터가 훼손될 있기 때문이다.
:ALTER VIEW 문을 사용할 없다. 즉 뷰의 정의를 변경할 수 없다.
+
::해당 컬럼이 NULL 값만 가지고 있거나 테이블에 아무 행도 없으면 컬럼의 폭을 줄일 있다.
:뷰로 구성된 내용에 대한 삽입, 삭제, 갱신, 연산에 제약이 따른다.<ref name='view_info'></ref>
+
::해당 컬럼이 NULL 값만을 가지고 있으면 데이터 유형을 변경할 수 있다.
 +
::해당 컬럼의 DEFAULT 값을 바꾸면 변경 작업 이후 발생하는 행 삽입에만 영향을 미치게 된다.
 +
::해당 컬럼에 NULL 값이 없을 경우에만 NOT NULL 제약조건을 추가할 수 있다.<ref name='constraint'></ref>
  
=== 인덱스 ===
+
=== 컬럼명 수정 (RENAME COLUMN) ===
[[인덱스]](index)는 키 값으로 행 데이터의 위치를 식별하는데 사용하는 기능이다. 그러기 위해서는 원본 테이블을 기준으로 잘 정렬된 별도의 테이블, 즉 인덱스 테이블을 생성해야 하고, 이로 인해 데이터 엑세스 성능을 높일 수 있다. 인덱스의 존재 유무에 따라 쿼리의 결과는 달라지지 않는다. 정규화가 되어 있지 않은 테이블은 컬럼이 많으며, 이에 따라 조합할 수 있는 인덱스가 많아지게 된다. 인덱스가 많으면 갱신 성능이 나빠지고 디스크 공간도 많아지므로 인덱스를 효과적으로 사용하려면 정규화가 잘 되어 있어야 한다.<ref name='index_info'>victolee, 〈[https://victorydntmd.tistory.com/319 인덱스(Index)]〉, 2019-05-18</ref>
+
테이블을 생성하면서 만들어졌던 컬럼명을 변경해야 할 경우에 사용한다.
  
인덱스 테이블은데이터베이스를 검색하기 위해 사용할 수 있는 특별한 테이블로서, 데이터베이스 검색의 속도를 빠르게 도와주는 역할을 한다. 즉, 데이터베이스를 사용하는데 있어 성능에 대한 문제 또는 개선을 위해 가장 먼저 확인하는 부분이다. 이는 저절로 생성되지 않으며 관리자 또는 사용자에 의해 별도로 생성하거나 삭제할 수 있다.
+
  ALTER TABLE 테이블명
 +
  RENAME COLUMN 변경해야할 컬럼명 TO 새로운 컬럼명; <ref name='constraint'></ref>
  
=== 연산 ===
+
=== 컬럼 삭제 (DROP COLUMN) ===
==== 단항연산 ====
 
===== SELECT =====
 
* '''SELECT''' : 릴레이션에서 주어진 조건을 만족하는 튜플을 선택하는 연산자
 
:결과 릴레이션의 차수 = 입력 릴레이션의 차수
 
:결과 릴레이션의 Cardinality <= 원래 릴레이션의 Cardinality
 
<ref name='db_re'>jhkang-dev, 〈[https://jhkang-tech.tistory.com/51 DB 관계 대수]〉, 2018-10-16</ref>
 
  
===== PROJECT =====
+
  ALTER TABLE 테이블명
* '''PROJECT''' : 릴레이션에서 Attribute 리스트에 제시된 Attribute만을 추출하는 연산자
+
  DROP COLUMN 삭제할 컬럼명; <ref name='constraint'></ref>
:한 릴레이션의 Attribute들의 부분집합
 
:하나의 입력 릴레이션에 적용되므로 단항 연산자
 
:PROJECT 연산을 하면 중복이 제거된다 --> PROJECT 연산의 결과는 중복이 제거된 distinctive한 튜플이다.<ref name='db_re'></ref>
 
  
==== 집합연산 ====
+
== 제약조건 ==
===== UNION =====
+
제약조건(constraint)은 사용자가 원하는 조건의 데이터만 유지하기 위한 특정 컬럼에 설정하는 제약이다. 테이블을 생성할 제약조건을 반드시 기술할 필요는 없다.<ref name='constraint'></ref>
* '''합집합(union)''' : 이항 연산으로 관계성이 있는 두개의 릴레이션을 합집합하여 하나의 릴레이션을 만들어내는 연산이다. 즉, 테이블을 합해서 추출한다.<ref name='db_re'></ref>
 
===== INTERSECT =====
 
* '''교집합(intersect)''' : 이항 연산으로 관계성이 있는 두개의 릴레이션에서 중복되어 있는 내용을 선택하여 새로운 릴레이션을 만들어 내는 연산이다. 즉, 겹치는 부분을 추출한다.<ref name='db_re'></ref>
 
===== DIFFERENCE =====
 
* '''차집합(difference)''' : 이항 연산으로 관계성이 있는 두개의 릴레이션이 있을 그 중 하나의 릴레이션에서 또 다른 릴레이션의 내용과 겹치는 내용을 제거해서 새로운 릴레이션을 생성하는 연산이다. 즉, 중복된 값을 제거하고 결과값을 추출한다.<ref name='db_re'></ref>
 
===== CARTESIAN PRODUCT =====
 
* '''카디션 프로덕트(cartesian product) : 이항 연산으로 두 릴레이션의 현재 튜플로 구성 가능한 모든 조합을 만든다.
 
:결과 릴레이션의 차수 = R의 차수 + S의 차수
 
:결과 릴레이션의 카디널리티 = R의 카디널리티 * S의 카디널리티<ref name='db_re'></ref>
 
  
=== ===
+
=== PRIMARY KEY(P.K) ===
:데이터베이스에서 조건에 만족하는 튜플을 찾거나 순서대로 정렬할 때 다른 튜플들과 구별할 있는 유일한 기준이 되는 Attribute(속성)이다.<ref name='db_key'>Lim-Ky, 〈[https://limkydev.tistory.com/108 키(Key)의 개념 및 종류]〉, 2017-10-23</ref>
+
* 테이블에 저장된 행 데이터를 고유하게 식별하기 위한 기본키 정의
 +
* 하나의 테이블에 하나의 기본키 제약만 정의할 수 있다.
 +
* 기본키 제약을 정의하면 DBMS는 자동으로 UNIQUE 인덱스를 생성하며, 기본키를 구성하는 컬럼에는 NULL을 입력할 없다.<ref name='constraint'></ref>
  
==== 기본키 ====
+
=== UNIQUE KEY ===
* 후보키 중에서 선택한 주키(Main Key)
+
* 테이블에 저장된 행 데이터를 고유하게 식별하기 위한 고유키를 정의한다.
* 한 릴레이션에서 특정 튜플을 유일하게 구별할 수 있는 속성
+
* 단, NULL은 고유키 제약의 대상이 아니므로, NULL 값을 가진 행이 여러 개가 있더라도 고유키 제약 위반이 되지 않는다.<ref name='constraint'></ref>
* Null 값을 가질 수 없다.
 
* 기본키로 정의된 속성에는 동일한 값이 중복되어 저장될 수 없다.<ref name='db_key'></ref>
 
  
==== 후보키 ====
+
=== NOT NULL ===
* 릴레이션을 구성하는 속성들 중에서 튜플을 유일하게 식별할 수 있는 속성들의 부분집합을 의미한다.
+
* NULL 값의 입력을 금지한다.
* 모든 릴레이션은 반드시 하나 이상의 후보키를 가져야 한다.
+
* 디폴트 상태에서는 모든 컬럼에서 NULL을 허가하고 있지만, 이 제약을 지정함으로써 해당 컬럼은 입력 필수가 된다.<ref name='constraint'></ref>
* 릴레이션에 있는 모든 튜플에 대해서 유일성과 최소성을 만족시켜야 한다.<ref name='db_key'></ref>
 
  
==== 대체키 ====
+
=== CHECK ===
* 후보키가 둘 이상일 때 기본키를 제외한 나머지 후보키들을 말한다.
+
* 입력할 수 있는 값의 범위 등을 제한한다. CHECK 제약으로는 TRUE or FALSE로 평가할 수 있는 논리식을 지정한다.<ref name='constraint'></ref>
* 보조키라고도 한다.<ref name='db_key'></ref>
 
  
==== 슈퍼키 ====
+
=== FOREIGN KEY(F.K) ===
* 슈퍼키는 한 릴레이션 내에 있는 속성들의 집합으로 구성된 키로서 릴레이션을 구성하는 모든 튜플 중 슈퍼키로 구성된 속성의 집합과 동일한 값은 나타내지 않는다.
+
* 관계형 데이터베이스에서 테이블 간의 관계를 정의하기 위해 기본키를 다른 테이블의 외래키로 복사하는 경우 외래키가 생성된다.
* 릴레이션을 구성하는 모든 튜플에 대해 유일성은 만족하지만, 최소성은 만족시키지 못한다.<ref name='db_key'></ref>
+
* 외래키 지정시 참조 무결성 제약 옵션을 선택할 있다.<ref name='constraint'></ref>
 
 
==== 외래키 ====
 
* 외래키는 참조되는 릴레이션의 기본키와 대응되어 릴레이션 간에 참조 관계를 표현하는데 중요한 도구로 사용된다.
 
* 관계(Relation)를 맺고 있는 릴레이션 R1, R2에서 릴레이션 R1이 참조하고 있는 릴레이션 R2의 기본키와 같은 R1 릴레이션의 속성이다.
 
* 외래키로 지정되면 참조 테이블의 기본키에 없는 값은 입력할 없다.<ref name='db_key'></ref>
 
  
 
{{각주}}
 
{{각주}}
170번째 줄: 114번째 줄:
 
== 참고자료 ==
 
== 참고자료 ==
 
* 김동근, 〈[http://www.terms.co.kr/table.htm table 테이블]〉, 《김동근의 텀즈, 컴퓨터 용어사전》, 2002-06-17
 
* 김동근, 〈[http://www.terms.co.kr/table.htm table 테이블]〉, 《김동근의 텀즈, 컴퓨터 용어사전》, 2002-06-17
* 돌딱, 〈[https://blog.naver.com/96wjdduf/221860693470 관계형 데이터베이스의 구조]〉, 2020-03-18
+
* , 〈[http://blog.naver.com/PostView.nhn?blogId=jjhstr&logNo=60097939589&proxyReferer=https:%2F%2Fwww.google.com%2F DB에서 entityty란?]〉, 2009-12-24
 
* 개발자, 〈[https://blog.naver.com/kookh1/120184872122 릴레이션의 특징과 용어]〉, 2013-03-16
 
* 개발자, 〈[https://blog.naver.com/kookh1/120184872122 릴레이션의 특징과 용어]〉, 2013-03-16
* 환, 〈[http://blog.naver.com/PostView.nhn?blogId=jjhstr&logNo=60097939589&proxyReferer=https:%2F%2Fwww.google.com%2F DB에서 entityty란?]〉, 2009년12월24일
+
* 개발이 하고 싶어요, 〈[https://hyeonstorage.tistory.com/291 CREATE TABLE 테이블 생성, 제약조건(CONSTRAINT), 확인(DESC)]〉, 2014-05-29
* Tigercow, 〈[https://doorbw.tistory.com/227 엔터티(ENTITY)와 속성(ATTRIBUTE)]〉, 2020-01-13
 
 
* 글그리, 〈[https://eastroot1590.tistory.com/entry/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%9A%A9%EC%96%B4-%EB%A6%B4%EB%A0%88%EC%9D%B4%EC%85%98Relation 데이터베이스 - 릴레이션(Relation)]〉, 2017-03-09
 
* 글그리, 〈[https://eastroot1590.tistory.com/entry/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%9A%A9%EC%96%B4-%EB%A6%B4%EB%A0%88%EC%9D%B4%EC%85%98Relation 데이터베이스 - 릴레이션(Relation)]〉, 2017-03-09
 +
* victolee, 〈[https://victorydntmd.tistory.com/319 인덱스(Index)]〉, 2019-05-18
 
* 무니봇, 〈[https://moonibot.tistory.com/37 릴레이션 스키마(Relation Schema), 릴레이션 인스턴스(Relation Instance), 속성(Attribute), 튜플(Tuple)]〉, 2019-12-17
 
* 무니봇, 〈[https://moonibot.tistory.com/37 릴레이션 스키마(Relation Schema), 릴레이션 인스턴스(Relation Instance), 속성(Attribute), 튜플(Tuple)]〉, 2019-12-17
* victolee, 〈[https://victorydntmd.tistory.com/319 인덱스(Index)]〉, 2019-05-18
+
* Tigercow, 〈[https://doorbw.tistory.com/227 엔터티(ENTITY)와 속성(ATTRIBUTE)]〉, 2020-01-13
 +
* 돌딱, 〈[https://blog.naver.com/96wjdduf/221860693470 관계형 데이터베이스의 구조]〉, 2020-03-18
  
 
== 같이 보기 ==
 
== 같이 보기 ==
184번째 줄: 129번째 줄:
 
* [[DBMS]]
 
* [[DBMS]]
 
* [[키]]
 
* [[키]]
* [[제약조건]]
 
 
* [[SQL]]
 
* [[SQL]]
 +
* [[정규화]]
 +
* [[역정규화]]
 
* [[HTML]]
 
* [[HTML]]
 
* [[엔티티]]
 
* [[엔티티]]
 
* [[태그]]
 
* [[태그]]
 +
* [[테이블 (HTML)]]
 +
* [[테이블]]
  
 
{{데이터|검토 필요}}
 
{{데이터|검토 필요}}

2022년 6월 9일 (목) 16:56 기준 최신판

테이블(table)은 데이터베이스에서 (가로, row, record)과 (세로, column, field)로 짜여진 표에 기록된 데이터의 집합이다. 디비 테이블(DB table)이라고도 한다.

개요[편집]

테이블이란 데이터베이스에서 단일 주제에 관해 행과 열로 구성되는 정보 모음을 가리킨다. 예를 들면, 업무용 데이터베이스는 대개 고객 정보에 관한 테이블을 가지고 있는데, 고객의 계정 번호, 주소, 전화번호 등을 저장할 수 있는 여러 개의 행으로 구성된다. 테이블 내에서 계정 번호 등과 같은 낱낱의 데이터 각각을 필드(field)라고 부른다. 하나의 행은 모든 고객들의 전화 번호 등과 같은 어떤 한 필드 내의 모든 데이터로 구성된다. 필드는 완전한 정보 셋인 레코드로 조직화되며, 각각은 하나의 열을 이룬다. 표준화 과정을 통해 데이터를 가장 효과적인 방법으로 테이블로 구성할 수 있는 방법을 결정한다.

컴퓨터로 만들어지거나 또는 종이 위에 손쉽게 그릴 수 있는 진리표에는 기반이 되는 결정이나 기준 목록을 포함한다. 진리표에는 가능한 모든 결정 상황이 목록화되며, 각 상황에서 취해져야 할 행위가 정의된다. 기본적인 예로는, 도로 교차점의 교통 상황에 대하여 "예" 또는 "아니오"와 같은 결정들과 빨간색 신호나, 녹색 신호 등과 같이 기준들이 표현될 수 있다. 진리표는 여러 가지 상황에서 내려지는 결정에 따라 처리 기준을 지시하기 위한 컴퓨터 프로그램에도 삽입될 수 있다. 진리표가 변경되면 프로그램에도 반영된다.[1]

구조[편집]

테이블은 기본적으로 (row)과 (column)으로 구성되어 있다.

행(row)[편집]

  • 레코드(record), 튜플(tuple) : 릴레이션이 나타내는 엔티티(entity)의 특정 인스턴스에 관한 사실(값)들의 모임이다. 튜플로 통용된다.
  • 카디날리티(cardinality) : 릴레이션 튜플의 개수[2]

열(column)[편집]

  • 속성(attribute) : 하나의 릴레이션은 현실세계의 어떤 개체(entity)를 표현하고 저장되는 데 사용된다. 이때 개체는 사물이 될 수도, 추상적인 개념이 될 수도 있다.
  • 필드(field) : 종종 컬럼의 대용으로 동일한 의미로 사용되지만, 필드와 필드값은 한 열이나 한 컬럼 사이의 교차로 존재하는 단일 항목을 특정할 때 언급하는 것이다.
  • 차수(degree) : 한 릴레이션에 들어 있는 속성의 수[2]

도메인[편집]

하나의 속성이 취할 수 있는 같은 타입의 원자값들의 집합이다. 도메인(domain)은 실제 속성 값이 나타날 때 그 값의 합법 여부를 시스템이 검사하는데 이용된다.[2]

릴레이션 인스턴스[편집]

릴레이션 인스턴스(relation instance)란 데이터 개체를 구성하고 있는 속성들에 데이터 타입이 정의되어 구체적인 데이터 값을 갖고 있는 것을 말한다.[3]

관계형 데이터베이스 구조[편집]

image[2]

SQL에서 테이블 활용[편집]

테이블 생성[편집]

 CREATE TABLE 테이블 이름 (
       컬럼명1 DATATYPE [DEFAULT 형식],
       컬럼명2 DATATYPE [DEFAULT 형식],
       컬럼명3 DATATYPE [DEFAULT 형식]
 );
테이블 생성시 대/소문자 구분은 하지 않는다. (기본적으로 테이블이나 컬럼명은 대문자로 만들어진다.)
DATE 유형은 별도로 크기를 지정하지 않는다.
문자 데이터 유형은 반드시 가질 수 있는 최대 길이를 표시해야 한다.
컬럼과 컬럼의 구분은 콤마로 하되, 마지막 컬럼은 콤마를 찍지 않는다.
컬럼에 대한 제약조건이 있으면 CONSTRAINT를 이용하여 추가할 수 있다.[4]

테이블 수정[편집]

 ALTER TABLE 테이블명;

테이블 삭제[편집]

 DROP TABLE 테이블명 [CASCADE CONSTRAINT];
DROP TABLE 명령어를 사용하면 테이블의 모든 데이터 및 구조를 삭제한다.
CASCADE CONSTRAINT 옵션은 해당 테이블과 관계가 있었던 참조되는 제약조건에 대해서도 삭제한다는 것을 의미한다.
(SQL Server에서는 CASCADE 옵션이 존재하지 않는다. 테이블 삭제 전에 참조하는 FOREIGN KEY 제약 등을 먼저 삭제해야 한다.)[4]

테이블 목록 조회[편집]

 SHOW TABLES;

테이블 조회[편집]

 SELECT * FROM 테이블명;

컬럼 추가 (ADD COLUMN)[편집]

 ALTER TABLE 테이블명
 ADD 추가할 컬럼명  데이터 유형; [4]

컬럼 수정 (MODIFY COLUMN)[편집]

 ALTER TABLE 테이블명
 MODIFY COLUMN 수정할 컬럼명;
MODIFY COLUMN 사용 시 주의사항
해당 컬럼의 크기를 늘릴 수는 있지만 줄이지는 못한다. 이는 기존의 데이터가 훼손될 수 있기 때문이다.
해당 컬럼이 NULL 값만 가지고 있거나 테이블에 아무 행도 없으면 컬럼의 폭을 줄일 수 있다.
해당 컬럼이 NULL 값만을 가지고 있으면 데이터 유형을 변경할 수 있다.
해당 컬럼의 DEFAULT 값을 바꾸면 변경 작업 이후 발생하는 행 삽입에만 영향을 미치게 된다.
해당 컬럼에 NULL 값이 없을 경우에만 NOT NULL 제약조건을 추가할 수 있다.[4]

컬럼명 수정 (RENAME COLUMN)[편집]

테이블을 생성하면서 만들어졌던 컬럼명을 변경해야 할 경우에 사용한다.

 ALTER TABLE 테이블명
 RENAME COLUMN 변경해야할 컬럼명 TO 새로운 컬럼명; [4]

컬럼 삭제 (DROP COLUMN)[편집]

 ALTER TABLE 테이블명
 DROP COLUMN 삭제할 컬럼명; [4]

제약조건[편집]

제약조건(constraint)은 사용자가 원하는 조건의 데이터만 유지하기 위한 특정 컬럼에 설정하는 제약이다. 테이블을 생성할 때 제약조건을 반드시 기술할 필요는 없다.[4]

PRIMARY KEY(P.K)[편집]

  • 테이블에 저장된 행 데이터를 고유하게 식별하기 위한 기본키 정의
  • 하나의 테이블에 하나의 기본키 제약만 정의할 수 있다.
  • 기본키 제약을 정의하면 DBMS는 자동으로 UNIQUE 인덱스를 생성하며, 기본키를 구성하는 컬럼에는 NULL을 입력할 수 없다.[4]

UNIQUE KEY[편집]

  • 테이블에 저장된 행 데이터를 고유하게 식별하기 위한 고유키를 정의한다.
  • 단, NULL은 고유키 제약의 대상이 아니므로, NULL 값을 가진 행이 여러 개가 있더라도 고유키 제약 위반이 되지 않는다.[4]

NOT NULL[편집]

  • NULL 값의 입력을 금지한다.
  • 디폴트 상태에서는 모든 컬럼에서 NULL을 허가하고 있지만, 이 제약을 지정함으로써 해당 컬럼은 입력 필수가 된다.[4]

CHECK[편집]

  • 입력할 수 있는 값의 범위 등을 제한한다. CHECK 제약으로는 TRUE or FALSE로 평가할 수 있는 논리식을 지정한다.[4]

FOREIGN KEY(F.K)[편집]

  • 관계형 데이터베이스에서 테이블 간의 관계를 정의하기 위해 기본키를 다른 테이블의 외래키로 복사하는 경우 외래키가 생성된다.
  • 외래키 지정시 참조 무결성 제약 옵션을 선택할 수 있다.[4]

각주[편집]

  1. 김동근, 〈table 테이블〉, 《김동근의 텀즈, 컴퓨터 용어사전》, 2002-06-17
  2. 2.0 2.1 2.2 2.3 돌딱, 〈관계형 데이터베이스의 구조〉, 2020-03-18
  3. 개발자, 〈릴레이션의 특징과 용어〉, 2013-03-16
  4. 4.00 4.01 4.02 4.03 4.04 4.05 4.06 4.07 4.08 4.09 4.10 4.11 개발이 하고 싶어요, 〈CREATE TABLE 테이블 생성, 제약조건(CONSTRAINT), 확인(DESC)〉, 2014-05-29

참고자료[편집]

같이 보기[편집]


  검수요청.png검수요청.png 이 테이블 (데이터베이스) 문서는 데이터에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.