009. 정규화(Normalization), Primary Key, 관계

2023.4.3 (월)

HR 계정 실습

• 데이터베이스 정규화 (Normalization)
  - 제 1 정규화
  - 제 2 정규화
  - 제 3 정규화
  - 제 4 정규화 (BCNF)
  - 역정규화(비정규화)

(자바 수업 에서) 작은 하나의 큰 클래스보다 작개쪼개어 나눠서 구성된 여러개의 클래스가 강력하다고 했음
끊임없이 나누고 분리하는 작업 수행하게 되고, 정규화도 이 중에 하나!
특히나 관계형 데이터베이스에서 하나의 커다란 테이블보다 작게 나눠진 테이블들이 위력적이다.

 

(DB에서) 정규화란 테이블을 나누는(분리하는) 것을 말한다.
WHY?
ex) EMP 테이블이나 DEPT 테이블을 따로 나눠두지 않으면 굳이 JOIN 해서 쓰지 않을 수도 있는데 왜 나누었을까?
- 데이터가 합쳐져있는 테이블 안에서, 하나의 데이터를 찾기 위해 많은 데이터를 메모리에서 퍼올려져야함
  (쪼개져있다면, 필요한 부분만 빠르게 찾아서 퍼올릴 수 있다)

○ 정규화란?
한 마디로 데이터베이스 서버의 메모리 낭비를 막기 위해,
어떤 하나의 테이블을... 식별자를 가지는 여러개의 테이블로나누는 과정을 말한다.

-- ex) 춘식이가... 옥장판을 판매한다.
--     고객리스트 → 거래처 직원 명단이 적혀있는 수첩의 정보를
--     데이터베이스화 하려고 한다.

-- 테이블명 : 거래처직원
/*
   10Byte     10Byte      10Byte        10Byte    10Byte 10Byte    10Byte
-----------------------------------------------------------------------------
거래처회사명 회사주소     회사전화    거래처직원명  직급 이메일    휴대폰
-----------------------------------------------------------------------------
     LG      서울여의도  02-3456-6789    최호중     부장  chj@na... 010-...
     LG      서울여의도  02-3456-6789    윤석원     과장  ysw@na... 010-...
     LG      서울여의도  02-3456-6789    송유택     대리  syt@na... 010-...
     LG      서울여의도  02-3456-6789    이경수     부장  lks@na... 010-...
     SK      서울소공동  02-3456-6789    정성화     부장  csh@na... 010-...
     LG      부산동래구 051-9999-8888    김리현     대리  klh@na... 010-...
     LG      서울여의도 051-9999-8888    유성재     부장  ysj@na... 010-...
                            :
                            :
-----------------------------------------------------------------------------                            
*/
/*
가정) 서울여의도 LG 라는 회사에 근무하는 거래처 직원 명단이
      총 100만 명이라고 가정한다.
      (한 행(레코드)은 70Byte 이다.)
      
      어느 날... → 『서울여의도』에 위치한 『LG』본사가
      『경기분당』으로 사옥을 이전하게 되었다.
      이로 인해...
      회사 주소는 『경기분당』 으로 바뀌고
      회사 전화는 『031-111-2222』로 바뀌게 되었다.
      
      그러면.... 100만 명의 회사주소와 회사전화를 변경해야 한다.
      
      - 이 때 수행되어야 할 쿼리문 → UPDATE 구문
      
      UPDATE 거래처직원 
      SET 회사주소  = '경기분당', 회사전화 = '031-111-2222'
      WHERE 거래처회사명 = 'LG'
            AND 회사주소 = '서울여의도'; 
        
     --> 100만 개 행을 하드디스크상에서 읽어다가
         메모리에 로드시켜 주어야한다.
         즉, 100만 * 70Byte 모두
         하드디스크상에서 읽어다가 메모리에 로드시켜 주어야 한다는 말이다.
         
         --> 이는 테이블의 설계가 잘못되었으므로
             DB 서버는 조만간 메모리 고갈로 인해 DOWN 될 것이다.
             
             --> 그러므로 정규화 과정을 수행해야 한다.
*/

- 규칙과 정해진 가이드라인에 따라서 테이블을 나누는(분리하는) 것
→ DB 서버 메모리 낭비를 막기 위해서 한다.

- 식별자를 갖게 끔 나누어야 함
- 정규화를 하게 될  때는 마음에 드는 것을 골라서 하는게 아니라 순서대로 진행하게 된다.
 ( 제 1 정규화를 마친 결과물로 → 제 2 정규화 → 제 3 정규화 → 제 4 정규화 [→ 역정규화(비정규화)] )

---

• 제 1 정규화
  어떤 하나의 테이블에 반복되어 컬럼 값들이 존재한다면,
  값들이 반복되어 나오는 컬럼을 분리하여 새로운 테이블을 만들어준다.

→ 제 1 정규화를 수행하는 과정에서 분리된 테이블은 반드시 부모 테이블과 자식 테이블의 관계를 갖게 된다.

부모 테이블 → 참조받는 컬럼 → PRIMARY KEY (제약조건(사항))
자식 테이블 → 참조하는 컬럼 → FOREIGN KEY (제약조건(사항))

※ 참조 받는 컬럼은 무조건 고유한 값을 가져야하며, 문제가 생기면 참조받는 테이블까지 문제가 생긴다.
- 오라클이 해당 부분에 제약을 걸어두었기 때문에 제약조건이라고 한다.

참조받는 컬럼이 갖는 특징(부모 테이블) = PRIMARY KEY 의 제약조건
▶ 반드시 고유한 값(데이터)이 들어와야 한다.
     → 즉, 중복된 값(데이터)이 없어야 한다.
▶ NULL 이 있어서는 안된다. (비어있어서는 안된다.)
     → 즉, NOT NULL 이어야 한다. 

제 1 정규화를 수행하는 과정에서
▶ 부모 테이블의 PRIMARY KEY 는, 항상 자식의 FOREIGN KEY 로 전이된다.
     - 전이 : 자식테이블에 컬럼이 생성된다는 의미

/* 
 // 앞의 3 컬럼만 자르고 확인하면, 중복되는 값들을 제거하고 나면 3개의 행만이 존재하는 테이블이 된다.

-- 테이블명 : 회사 → 부모 테이블  
10Byte   10Byte     10Byte      10Byte     
-----------------------------------------------------------
회사ID  거래처회사명 회사주소     회사전화   
---------
(참조 받는 컬럼)
-----------------------------------------------------------
 10         LG      서울여의도  02-3456-6789 
 20         SK      서울소공동  02-3456-6789 
 30         LG      부산동래구 051-9999-8888
-----------------------------------------------------------

// 무턱대고 자르게 되면 다시 관계를 맺어줄 때 문제가 생기므로, 
// 참조(복원)할 수 있는 회사 ID 라는 컬럼을 추가해준다.

-- 테이블명 : 직원 → 자식 테이블
   10Byte     10Byte  10Byte    10Byte    10Byte
---------------------------------------------------------------
  거래처직원명  직급  이메일    휴대폰    회사ID
                                                                ---------
                                                  (참조 하는 컬럼)
---------------------------------------------------------------
     최호중     부장  chj@na... 010-...       10
     윤석원     과장  ysw@na... 010-...     10
     송유택     대리  syt@na... 010-...       10
     이경수     부장  lks@na... 010-...       10
     정성화     부장  csh@na... 010-...      20
     김리현     대리  klh@na... 010-...       30
     유성재     부장  ysj@na... 010-...       30
                            :
---------------------------------------------------------------
*/

--※ 테이블이 분할(분리)되기 이전 상태로 조회
--  (거래처회사명, 회사주소, 회사전화, 거래처직원명, 직급, 이메일, 휴대폰)

SELECT A.거래처회사명, A.회사주소, A.회사전화
     , B.거래처직원명, B.직급, B.이메일, B.휴대폰
FROM 회사 A , 직원 B
WHERE A.회사ID = B.회사ID(+);
--==>> 원래 상태로 조회하는데 이상 없음.

// 제 1 정규화를 수행하고 나면, 처음의 가정이 아래와 같이 변경되게 된다.
/*
가정) 서울여의도 LG 라는 회사에 근무하는 거래처 직원 명단이
      총 100만 명이라고 가정한다.
     
      어느 날... → 『서울여의도』에 위치한 『LG』본사가
      『경기분당』으로 사옥을 이전하게 되었다.
      이로 인해...
      회사 주소는 『경기분당』 으로 바뀌고
      회사 전화는 『031-111-2222』로 바뀌게 되었다.
      
      그러면.... 회사 테이블의 1건의 회사주소와 회사전화를 변경해야 한다.
      
      - 이 때 수행되어야 할 쿼리문 → UPDATE 구문
      
      UPDATE 회사
      SET 회사주소  = '경기분당', 회사전화 = '031-111-2222'
      WHERE 회사ID = 10 ; 
        
     --> 1 개 행을 하드디스크상에서 읽어다가
         메모리에 로드시켜 주어야한다.
         즉, 1 * 40Byte 를 모두 
         하드디스크상에서 읽어다가 메모리에 로드시켜 주어야 한다는 말이다.
         
         --> 이는 테이블의 설계가 잘 된 상황이다
             
             --> 정규화를 수행하기 이전에는 100만선을 처리해야 할 업무에서
                 1건만 처리하면 되는 업무로 바뀐 상황이기 때문에
                 DB 서버는 메모리 고갈 없이 아주 빠르게 처리된 것이다.

// ++
// 부모자식이 형성되지 않는 하나의 테이블이라고 하여도
// 관계형 데이터베이스 내에서 관리/확인 하기 위해서 PRIMARY KEY(식별) 를 구성하여 활용하는 것이 좋다. 
*/

※ 정규화 하기 전과 후로 나누어 얼마나 메모리 데이터를 소비하는지 확인해야한다.
--(+ 가정 : 전체 거래처직원수 200만)
/*

<정규화>	<정규화 전>
--A. 거래처회사명, 회사전화
SELECT 거래처회사명, 회사전화  FROM 회사; --> 3 * 40 Byte	SELECT 거래처회사명, 회사전화 FROM 거래처직원 ; --> 200만 * 70Byte
--B. 거래처직원명, 직급
SELECT 거래처회사명, 회사전화  FROM 직원;  --> 200만 * 50 Byte	SELECT 거래처회사명, 회사전화 FROM 거래처직원 ; --> 200만 * 70Byte
--C. 거래처회사명, 거래처직원명
SELECT 회사.거래처회사명, 직원.거래처직원명 FROM 회사 JOIN 직원 ON 회사.회사ID = 직원.회사ID;  --> (회사) + (직원) --> (3 * 40 Byte) + (200만 * 50 Byte)	SELECT 거래처회사명, 거래처직원명 FROM 거래처직원 ; --> 200만 * 70Byte

 어떤 케이스를 다 확인해보아도 정규화를 한 것이 메모리를 적게 소비하는 것을 확인할 수 있다.

// WHERE 조건절이 없으면 테이블 전체를 스캔하여 메모리에 로드하게 된다
// (즉, SELECT * 과 동일한 메모리 소모)
*/

---

/*
-테이블명 : 주문
-------------------------------------------------------------------------
   고객ID             제품코드            주문일자            주문수량
   +++++++++++++++++++++++++++++++++++++++++++++++
                       (P.K)
-------------------------------------------------------------------------
 YSW1227(윤석원)   SWK123(새우깡)    2023-03-03 11:11:11         50
 LKS1227(이경수)   YPR234(양파링)    2023-03-03 13:40:27         30
 CHJ3361(최호중)   CPI110(초파이)    2023-03-04 09:13:08         20
 CHJ3361(최호중)   SWK123(새우깡)    2023-03-04 17:30:56         20
 CSH1227(정성화)   CPI110(초파이)    2023-03-04 19:29:13         30
 YSW1227(윤석원)   YPR234(양파링)    2023-03-05 05:03:45         50
                            :
                            :
-------------------------------------------------------------------------
*/

--※ 하나의 테이블에 존재하는 PRIMARY KEY 의 최대 갯수는 1개이다. // 0개도 가능
--   하지만, PRIMARY KEY 를 이루는(구성하는) 컬럼의 갯수는
--   복수(다수,여러개)인 것이 가능한다.
--   컬럼 1개로만(단일 컬럼) 으로 구성된 PRIMARY KEY 를
--   Single Primary Key (단일 프라이머리 키) 라고 부른다. //(혹은 언급을 하지 않기도 한다)
--   두 개 이상의 컬럼으로 구성된 PRIMARY KEY 를
--   Composite Primary Key (복합 프라이머리 키) 라고 부른다.

---

• 제 2 정규화
  제 1 정규화를 마친 결과물에서 PRIMARY KEY 가 SINGLE COLUMN 이라면
  → 제 2 정규화는 수행하지 않는다.
  하지만, PRIMARY KEY 가 COMPOSITE COLUMN 이라면
  → 반.드.시 제 2정규화를 수행해야한다.

- 식별자가 아닌 컬럼은 식별자 전체 컬럼에 대해 의존적이어야 하는데
  식별자 전체 컬럼이 아닌 일부 식별자 컬럼에 대해서만 의존적이라면, 이를 분리하여 새로운 테이블을 생성해준다.

/*
-테이블명 : 과목 → 부모 테이블
----------------------------------------------------------------------------------------------------------
과목번호   과목명    교수번호    교수명    강의실코드   강의실설명

+++++++                  +++++++
          ( P       .          K )
----------------------------------------------------------------------------------------------------------
JAVA0101   자바기초     21       장영실       A403      전산실습관 4층 50석규모
JAVA0102   자바중급     22       테슬라       T502      전자공학관 5층 30석규모
DB102      오라클중급   22       테슬라       A201      전산실습관 2층 20석규모
DB102      오라클중급   21       장영실       T502      전자공학관 5층 30석규모
DB103      오라클고급   23       에디슨       A203      전산실습관 2층 40석규모
JSP105     JSP심화      21       장영실       K101      인문사회관 1층 80석규모
                                         :
----------------------------------------------------------------------------------------------------------
// 과목명은 과목번호에만 의존적        → 별도의 과목 테이블 구성 필요
// 교수자명은 교수자번호에만 의존적 → 별도의 교수 테이블 구성 필요
*/

/*
-테이블명 : 점수 → 자식 테이블
----------------------------------------------------------------
과목번호    교수번호   학번    학생명     점수
================
            (F.K)
+++++++                     ++++
            ( P          .         K )
----------------------------------------------------------------
DB102           21      2301175  이창섭      80
DB102           21      2301177  윤석원      76
                    :
----------------------------------------------------------------
*/

// 꼭 복합 프라이머리 키가 필요한지 확인해보자는 절차

---

• 제 3 정규화
  식별자가 아닌 컬럼이 식별자가 아닌 컬럼에 의존적인 상황이라면
  → 이를 분리하여 새로운 테이블을 생성해 주어야 한다.

// 강의실 코드 - 강의실 설명 : 둘다 식별자가 아니며, 강의실 설명은 강의실 코드에 의존적이다.

---

--※ 관계(Relation)의 종류

-- 1 : 1
--> 관계형 데이터베이스 구조 상 가급적 피해야 하는 관계
--// 부득이하게 생길 수 는 있으나, 바람직하지 않은 형태이기 때문에 최대한 피하는 것이 좋다.
--// 인덱스 사용

-- 1 : 다(many)
--> 제 1 정규화를 마친 결과물에서 대표적으로 나타나는 바람직한 관계.
--  관계형 데이터베이스를 활용하는 과정에서 추구해야 하는 관계.

-- 다(many) : 다(many)
--> 논리적인 모델링에서는 존재할 수 있지만
--  실제 물리적인 모델링에서는 존재할 수 없는 관계 //(연관성이 없기 때문에)

/*
- 테이블명 : 고객 (다 : many)                 - 테이블명 : 제품 (다 : many)
-----------------------------------          -----------------------------------
고객번호 고객명 이메일 휴대폰  ...           제품코드 제품명  단가  칼로리  ...
++++++++                                     ++++++++
 (P.K)                                         (P.K)
-----------------------------------          -----------------------------------
  1100   정성화 c...   010....                swk123  새우깡  1500  320
  1101   이경수 l...   010....                ggk568  감자깡   900  270
  1102   윤석원 p...   010....                ggc951  자갈치   800  410
  1103   유준상 y...   010....                hrb858  홈런볼  2200  630
           :                                            :
-----------------------------------          -----------------------------------

                      -테이블명 : 주문등록(접수)
                     --------------------------------------
                     고객번호 제품코드 주문일자 주문수량...
                     ======== ========
                       (F.K)    (F.K)
                     --------------------------------------
                     1101     hrb858   2023...    20   ....
                     1101     ggk568   2023...    10   ....
                     1101     swk123   2023...    30   ....
                     1102     swk123   2023...     7   ....
                     1100     swk123   2023...    20   ....
                     1103     swk123   2023...    20   ....
                     --------------------------------------
*/

※ 1 : 1 관계 

※ 다 : 다 관계

※ 1 : 다 관계

---

• 제 4 정규화 (BCNF)
  위에서 확인한 내용과 같이 『다:다』 관계를 『1:다』관계로 깨뜨리는 과정이 제 4 정규화의 수행과정이다.
  → 일반적으로 파생 테이블 생성
       → 『다:다』 관계를 『1:다』 관계로 깨뜨리는 역할 수행

---

• 역정규화 (비정규화)
  - 수행하는 것이 바람직한 경우인지 확인 해야함
  → 향후 수행하는 업무가 제대로 파악되어있지 않으면 파악이 불가능하다
      (해당 조회 결과물이 얼마나 빈번하게 사용될지 알 수 있어야한다)
  - 설계할 때는 데이터가 없지만, 향후에 얼마만큼의 데이터가 입력될지 파악이 되어야한다
  → 이 역시, 업무분석이 제대로 되어있지 않으면 할 수 없다
  
  ▶규칙을 거스르는 것이기 때문에 타당성을 제대로 검토하지않으면 안된다.

/*
 A 경우 → 역정규화를 수행하지 않는 것이 바람직한 경우

-- 테이블명 : 부서        - 테이블명 : 사원
  10             10     10          10            10     10    10      10          10                  10
----------------------------     -----------------------------------------------------------       -------------
부서번호 부서명 주소     사원번호 사원명 직급 급여 입사일 부서번호        + 부서명
+++++++                                                                                =======
----------------------------     -----------------------------------------------------------       -------------

     10개 행                            1,000,000 개 행
----------------------------     -----------------------------------------------------------       -------------
>> 업무 분석 상 조회 결과물 
// 해당 구조를 기반으로 어플리케이션이 만들어지게 되는데,
// 가장 많이 필요하게 되는 데이터의 구조가 아래와 같을 때
---------------------------------
부서명 사원명 직급 급여
---------------------------------
부서   사원     사원 사원

→ 『부서』 테이블과 『사원』테이블을 JOIN 했을 때의 크기
SELECT 부서.부서명, 사원.사원명, 사원.직급, 사원.급여
FROM 부서 JOIN 사원
ON   부서.부서번호 = 사원.부서번호;
--> (부서) + (사원)
--> (10 * 30Byte) + (1,000,000 * 60Byte) = 300 + 60,000,000 = 60,000,300Byte


→ 『사원』 테이블을 역정규화 수행한 후 이 테이블만 읽어올 때의 크기
SELECT 부서명, 사원명, 직급, 급여
FROM 사원역정규화;
--> 1,000,000 * 70Byte = 70,000,000Byte

/*
B 경우 →  역정규화를 수행하는 것이 바람직하다.

-- 테이블명 : 부서        - 테이블명 : 사원
  10             10     10          10            10     10    10      10          10                  10
----------------------------     -----------------------------------------------------------       -------------
부서번호 부서명 주소     사원번호 사원명 직급 급여 입사일 부서번호        + 부서명
+++++++                                                                                =======
----------------------------     -----------------------------------------------------------       -------------

     10개 행                            1,000,000 개 행
----------------------------     -----------------------------------------------------------       -------------
>> 업무 분석 상 조회 결과물 
// 해당 구조를 기반으로 어플리케이션이 만들어지게 되는데,
// 가장 많이 필요하게 되는 데이터의 구조가 아래와 같을 때
---------------------------------
부서명 사원명 직급 급여
---------------------------------
부서   사원     사원 사원

→ 『부서』 테이블과 『사원』테이블을 JOIN 했을 때의 크기
--> (500,000 * 30Byte) + (1,000,000 * 60Byte) = 15,000,000 + 60,000,000 = 75,000,000Byte

→ 『사원』 테이블을 역정규화 수행한 후 이 테이블만 읽어올 때의 크기
SELECT 부서명, 사원명, 직급, 급여
FROM 사원역정규화;
--> 1,000,000 * 70Byte = 70,000,000Byte

※ 역정규화 팁)
- (가장 확실한 것은 계산을 해보는 것이 가장 좋긴 하지만 매번 메모리를 확인할 수 없으니..)
  보통 데이터의 건수가 극명하게 차이가 나게 되는 경우는 역정규화를 하지 않는 것이 바람직 할 수 있으며.
  데이터의 건수가 차이가 크게 나지 않는 경우는 역정규화를 하는 것이 바람직 할 수 있다. 
  (데이터의 편차 파악)

---

• 별도의 유의사항

/*
-테이블명 : 사원 → 부모 테이블
--------------------------------------------
사원번호 사원명 주민번호 입사일  급여  직급
+++++++
--------------------------------------------
  7369   윤석원 9...     2020-.. xxxx  부장
  7370   박영희 9...     2021-.. xxxx  과장
  7371   김철수 9...     2022-.. xxxx  대리
  7372   이경수 9...     2021-.. xxxx  과장
                    :
--------------------------------------------
- 테이블명 : 사원가족 → 자식 테이블
---------------------------------
주민번호 사원번호   관계  성명
                =======
+++++++
---------------------------------
8...       7371     아내 김영희
2...       7371     아들 김중기
2...       7371     딸   김우희
8...       7370     남편 박철수
            :
---------------------------------

--// 사원테이블의 P.K  가 사원번호일 때, 사원가족테이블의 사원번호 컬럼으로 전이는 된 상황
--// (→ 널 값은 상관이 없다 ∵DEPTNO 40번)

< 구조적인 문제 >
 1. 사원가족테이블의 주민번호가 P.K일 경우, 같은 회사에 다니는 가족이 또 있을 경우 중복되어서 나올 수 없음

 2. (제 1 정규화) 사원테이블에서의 직급이 반복적으로 등장할 경우 + 예측가능한 데이터가 입력될 수 있는 상황
    → 별도의 직급 테이블(직급코드 직급명 직급수당 등) 구성 필요 - 사원테이블은 직급 코드를 참조해야한다.
//   대리(주임급)  , 부장(팀장급) 등 으로 확인되어야 함. (같은 직급이라도 다른 직위일 수 도 있는 상황도 있음)

 3. (제 1 정규화)  사원가족테이블의 관계가 예측가능한 데이터가 입력될 수 있는 상황
    → 별도의 관계 테이블을 만들기 → 데이터를 컨트롤하기 위해서는 통일이 필요
// ex) 아들래미, 내아들, 썬, 자식, 자녀 ...  // 와이프, 안사람, 부인 ...  // 배우자, 바깥양반 ... 

//결론
1) 예측 가능한 데이터가 입력 될 수 있는 상황이라면 → 코드화
2) 기존 컬럼을 통해 얻어낼 수 있는 데이터라면         → 컬럼으로 구성하지 않는다(쿼리문으로 얻는다)
// ex ) 학번 국어점수 영어점수 수학점수 총점
▶ 총점을 컬럼으로 구성하게 되면 총점의 데이터가 틀렸을 경우라도 어떤 것이 맞는지 알 수 없음 
// ex2) 학번 주민번호 나이
▶ 나이는 매번 달라지는 데이터이기 때문에 (쿼리문으로 구성하면 SYSDATE 로 매번 업데이트 가능) + 이유 상동

// 데이터에 대한 유효성이 깨지면
→ 주변의 데이터에 대한 신뢰도가 깨지며
→ 해당 테이블의 신뢰성이 깨지고

→ 해당 테이블과 관계를 맺는 테이블들도 신뢰성을 잃게 되고
→ DB 자체가 신뢰를 잃게 되어 사용할 수 없음
*/

---

• 참고

/*
1. 관계(relationship, relation)
   - 모든 엔트리(entry)는 단일 값을 가진다.
   - 각 열(column)은 유일한 이름을 가지며 순서는 무의미하다.
   - 테이블의 모든 행(row = 튜플 = tuple)은 동일하지 않으며 순서는 무의미하다.
   
2. 속성(attribute)
   - 테이블의 열(column)을 나타낸다.
   - 자료의 이름을 가진 최소 논리적 단위 : 객체의 성질, 상태 기술
   - 일반 파일(file)의 항목(아이템 = item = 필드 = field)에 해당한다.
   - 엔티티(entity)의 특성과 상태를 기술
   - 속성(attribute) 의 이름은 모두 달라야 한다.
   
3. 튜플 = tuple = 엔티티 = entity
   - 테이블의 행(row)
   - 연관된 몇 개의 속성(attribute)으로 구성
   - 개념정보 단위
   - 일반 파일(file)의 레코드(record)에 해당한다.
   - 튜플 변수(tuple variable)
     : 튜플(tuple)을 가리키는 변수, 모든 튜플 집합을 도메인으로 하는 변수
     
4. 도메인(domain)
   - 각 속성(attribute)이 가질 수 있도록 허용된 값들의 집합
   - 속성 명과 도메인 명이 반드시 동일할 필요는 없음
   - 모든 릴레이션에서 모든 속성들의 도메인은 원자적(atomic) 이어야 함.
   - 원자적 도메인
     : 도메인의 원소가 더이상 나누어질 수 없는 단일체일 때를 나타냄.

5. 릴레이션(relation)
   - 파일 시스템에서 파일과 같은개념
   - 중복된 튜플(tuple)을 포함하지 않는다
     → 모두 상이함(튜플의 유일성)
   - 릴레이션 = 튜플(엔티티 = entity)의 집합. 따라서 튜플(tuple)의 순서는 무의미하다.
   - 속성(attribute) 간에는 순서가 없다. 

*/