은둔형 공학자

1. COMMIT 연산(완료) 

COMMIT 

    - 트랜잭션이 연산을 완료된 것에 COMMIT 문장을 통해 트랜잭션 

         관리자에게 알려 주는 연산 

      - 트랜잭션에서 변경하려는 내용이 데이터베이스에 완전하게 반영됨 

     - SQL 구문상으로 COMMIT WORK 

ROLLBACK 연산 

     - 트랜잭션이 행한 모든 연산을 취소시키거나 트랜잭션을 재 시작하도록 함 

COMMIT 

    - 트랜잭션 실행이 성공적으로 완료되어 COMMIT 연산을 수행한 상태를 의미 

      - 계좌 이체를 하는 트랜잭션을 간략한 코드로 표현한 프로그램 소스 

A 계좌에서 B 계좌로 2000을 이체하는 트랜잭션 예를 프로그램으로 구현한 

것이다(프로그램 소스는 프로그래밍 언어마다 문법이 다를 수 있다). 

[프로그램 설명] 

1.  ACCT_SAVE 테이블에는 많은 항목들이 존재하지만, 그 중에서 

acct_name (계좌번호), acct_amt(잔액) 두개의 항목만을 사용해 보았다. 

2.  tmp_amt 변수는 서버에서 해당 조건에 맞는 acct_amt(잔액) 항목 값을 

읽어들여 잠시 저장하는 임시 변수이다. 즉 해당 계좌에 계좌 이체를 할 수 

있는지 잔액을 확인하기 위한 변수이다. 

3.  // 표시는 프로그램을 설명하는 주석이다. 

==================================================

 ACCOUNT_TRANS:       //  트랜잭션  이름 

   Begin_transaction       //  트랜잭션의 시작으로<활동(active)>상태유지 

  { 

       SELECT acct_amt  INTO :tmp_amt    //    A 계좌에서 잔액을 조회하여 

       FROMACCT_SAVE           //      임시변수 tmp_amp에 저장 

       WHERE acct_name = ‘A‘; 

                                                     //      A 계좌에서 B 계좌로2000을 이체하기 위한 잔액 비                 

                                                              교 루틴  

       IF tmp_amt<2000then         //       tmp_amt 내에 값을 비교하여 잔액이 부족하면, 

       {                            //       메시지로 결과를 알린 후 

         printf(“잔액이부족한다“);           //        더 이상 진행하지 않고, ERR_RTN 루틴 실행 

         GOTOERR_RTN;                       //        트랜잭션상태 <실패(failed)>이며, 

       }                                            //        <철회(aborted)>로 이동 예정 

       else 

  {                                                  // 잔액이 부족하지 않으면, 계좌 이체 루틴 실행 

 UPDATE ACCT_SAVE 

 SETacct_amt=acct_amt-2000 

 WHERE acct_name = ‘A‘; 

 IFERRORthenGOTOERR_RTN;     // 문장을 수행하다가 문제가 발생하면, ERR_RTN 루틴 실행 

                                                  // 트랜잭션상태 <실패(failed)>이며, <철회(aborted)>로 

 UPDATEACCT_SAVE                       //  이동 예정 

 SETacct_amt=acct_amt+2000 

 WHERE acct_name = ‘B‘; 

                                                 //  마지막 명령문 수행 직후 

                                                 //  트랜잭션 상태 <부분완료(PARTIALLYCOMMITTED)> 

 IFERRORthenGOTOERR_RTN;     //  문장을 수행하다가 문제가 발생하면, ERR_RTN 루틴 실행 

                                                //  트랜잭션상태 <실패(failed)>이며, <철회(aborted)>로 

                                                //  이동예정 

 COMMIT;                                  //   정상적으로 문장이 수행되어 COMMIT문 수행 

 printf (“계좌이체가 정상적으로 수행되었다“); // <완료(committed)> 

  GO TO END_RTN; 

 } 

  ERR_RTN; 

  ROLLBACK;                                           // 문장 수행을 실패하여 ROLLBACK문 수행<철회(aborted)> 

  END_RTN; 

  RETURN; 

} 

End_transaction 

============================

COMMIT과 ROLLBACK의 비교    

2. ROLLBACK 연산(복귀)

트랜잭션이 성공하지 못하는 원인  

시스템(사이트) 고장 

중앙 처리 장치, 주기억 장치, 전원 공급 장치 등이 고장남 

트랜잭션 고장 

트랜잭션 고장은 트랜잭션이 수행되는 도중에 철회됨 

매체 고장 

디스크 헤드, 디스크 콘트롤러 등이 고장 나서 보조 기억 장치의 전부 또는 일부 내용이 지워짐 

통신 고장 

자연적 재해 

부주의 또는 고의적인 고장 

트랜잭션(transaction)  

항공기 예약, 은행, 신용 카드 처리, 대형 할인점 등에서는  

   대규모 데이터베이스를 수백, 수천 명 이상의 사용자들이     

   동시에 접근함 

많은 사용자들이 동시에 데이터베이스의 서로 다른 부분  

   또는 동일한 부분을 접근하면서 데이터베이스를 사용함 

 동시성 제어(concurrency control) 

동시에 수행되는 트랜잭션들이 데이터베이스에 미치는  

  영향은 이들을 순차적으로 수행하였을 때 데이터베이스에    

  미치는 영향과 같도록 보장함 

다수 사용자가 데이터베이스를 동시에 접근하도록  

  허용하면서 데이터베이스의 일관성을 유지함  

트랜잭션(transaction)  

회복(recovery) 

데이터베이스를 갱신하는 도중에 시스템이 고장 나도  

  데이터베이스의 일관성을 유지함 

트랜잭션 

     - 데이터베이스 내에서 하나의 그룹으로 처리해야 하는 명령문 들을 모아 놓은 작업 단위 

  트랜잭션의 표현 형태 

원자성(Atomicity) 

     - 트랜잭션의 수행은 원자적이다(All-OR-Nothing 방식) 

[조건] 

1. Ti : 트랜잭션 이름 

2. 트랜잭션 실행 전 데이터베이스 내 A와 B 계좌 잔액 

 · A 계좌 : 2000 

 · B 계좌 : 3000 

3. 연산 설명 

 · read(X) : 데이터 X를 데이터베이스(디스크)로부터 읽어서 트랜잭션의 버퍼로 이동 

 · write(X) : 데이터 X를 트랜잭션의 버퍼에서 데이터베이스(디스크)로 이동 

일관성(Consistency) 

     - 트랜잭션 실행을 성공적으로 완료하면, 언제나 일관성 있는 데이터베이스 상태로 유지되어야 한다. 

격리성(Isolation: 고립성) 

     - 트랜잭션들이 서로 독립성을 보장받으며 수행될 수 있도록 도와준다. 

영속성(Durability: 지속성) 

     - 트랜잭션이 모든 작업을 성공적으로 수행 완료하여 데이터베이스 내에     

       반영했다면, 트랜잭션의 결과는 영구적이어야  함을 말한다. 

1. 데이터베이스 설계 사례 

기업에서 흔히 볼 수 있는 작은 세계에 관한 요구사항 

회사에는 다수의 사원들이 재직 

각 사원에 대해서 사원번호(고유함), 이름, 직책, 급여, 주소 를 저장. 주소는 시, 구, 동으로 세분하여 나타냄  

각 사원은 0명 이상의 부양가족을 가질 수 있음. 한 부양 가족은 두 명 이상의 사원에게 속하지 않음. 각 부양 가족에  대해서 부양가족의 이름과 성별을 저장 

회사는 여러 개의 프로젝트들을 진행. 각 프로젝트에 대해서 프로젝트번호(고유함), 이름, 예산, 프로젝트가 진행되는 위치를 나타냄. 한 프로젝트는 여러 위치에서  진행될 수 있음. 각 프로젝트마다 여러 명의 사원들이 일함. 각 사원은 여러 프로젝트에서 근무할 수 있음. 각 사원이 해당 프로젝트에서 어떤 역할을 수행하고, 얼마 동안 근무 해 왔는가를 나타냄. 각 프로젝트마다 한 명의 프로젝트 관리자가 있음. 한 사원은 두 개 이상의 프로젝트의 관리자 가 될 수는 없음. 프로젝트 관리자 임무를 시작한 날짜를 기록 

각 사원은 한 부서에만 속함. 각 부서에 대해서  부서번호 (고유함), 이름, 부서가 위치한 층을 나타냄 

각 프로젝트에는 부품들이 필요. 한 부품이 두 개 이상의 프로젝트에서 사용될 수 있음. 하나의 부품은 다른 여러 개의 부품들로 이루어질 수 있음. 각 부품에 대해서    부품번호(고유함), 이름, 가격, 그 부품이 다른 부품들을 포함하는 경우에는 그 부품들에 관한 정보도 나타냄 

각 부품을 공급하는 공급자들이 있음. 한 명의 공급자는 여러 가지 부품들을 공급할 수 있고, 각 부품은 여러 공급자들로부터 공급될 수 있음. 각 공급자에 대해서  공급자 번호(고유함), 이름, 신용도를 나타냄. 각 공급자에 대해서 그 공급자가 어떤 부품을 어떤 프로젝트에 얼마나 공급하는 가를 나타냄  

논리적 데이터 모델 

- 데이터베이스 관리 시스템의 종류에 따라 관계 데이터 모델(relational data model) 

- 네트워크 데이터 모델(network data model), 계층 데이터 모델(hierarchical data model) 

1:1 관계 타입 

- 1:1 관계 타입의 예 

1:N 관계 타입 

N:M 관계 타입 

   - 논리적 N:M 관계

N:M 관계 타입 

   - 물리적 N:M 관계 

ISA 관계 

도메인 정의 

- 도메인을 정의한 문장 

CREATE DOMAIN DEMPNO int; 

CREATE DOMAIN DEMPNAME varchar(30); 

CREATE DOMAIN DSALARY int 

- 도메인을 정의한 문장 

CREATE TABLE EMPLOYEE( 

 empno    DEMPNO, 

 empname  DEMPNAME, 

 manager  DEMPNO, 

 salary   DSALARY   

); 

도메인 정의 

- 도메인 

•각 엔티티에서 속성들을 모아 리스트를 만든다. 

•속성 이름이 여러 단어를 포함할 경우 분리 

•마지막 단어를 기준으로 정렬 

•여기까지는 용어 사전을 정의하는 것과 동일하다 

1. 데이터베이스 설계 개요 

데이터베이스 설계의 개요 

 한 조직체의 운영과 목적을 지원하기 위해 데이터베이스를 생성하는 과정 

 목적은 모든 주요 응용과 사용자들이 요구하는 데이터, 데이터 간의 관계를 표현하는 것 

 데이터베이스 개발은 일반적인 프로젝트 라이프 사이클 과정을 따름 

 훌륭한 데이터베이스 설계는 시간의 흐름에 따른 데이터의 모든 측면을 나타내고, 데이터 항목의 중복을 최소화하고, 데이터베이스에 대한 효율적인 접근을 제공하고, 데이터베이스의 무결성을 제공하고, 이해하기 쉬워야 함 

데이터베이스 설계의 주요 단계 

 데이터베이스 설계는 요구사항 분석, 개념적 설계,  DBMS의 선정, 논리적 설계, 스키마 정제, 물리적 설계와 튜닝 등 여러 작업들로 이루어짐 

 일반적으로, 데이터베이스 설계의 완성도를 높이기 위해서 이런 작업들을 앞뒤로 왔다갔다할 필요가 있음 

요구사항 수집과 분석 

요구사항을 수집하기 위해서 흔히 기존의 문서를 조사하고, 인터뷰나 설문 조사 등이 시행됨 

인터뷰는 요구사항 수집을 위해 가장 흔히 사용됨 

설문 조사는 자유롭게 의견을 적어내도록 하는 방식과 주어진 질문에 대해서만 답을 하는 방식으로 구분 

요구사항에 관한 지식을 기반으로 관련 있는 엔티티들과 이들의 애트리뷰트들이 무엇인가, 엔티티들 간의 관계가 무엇인가 등을 파악함 

또한 데이터 처리에 관한 요구사항에 대하여 전형적인 연산들은 무엇인가, 연산들의 의미, 접근하는 데이터의 양 등을 분석함 

개념적 설계 

모든 물리적인 사항과 독립적으로, 한 조직체에서 사용되는 정보의 모델을 구축하는 과정 

사용자들의 요구사항 명세로부터 개념적 스키마가 만들어짐 

높은 추상화 수준의 데이터 모델을 기반으로 정형적인 언어로 데이터 구조를 명시함 

대표적인 데이터 모델이 ER 모델 

개념적 설계의 단계에서는 엔티티 타입, 관계 타입, 애트리뷰트들을 식별하고, 애트리뷰트들의 도메인을 결정하고, 후보 키와 기본 키 애트리뷰트들을 결정함 

완성된 개념적 스키마(ER 스키마)는 ER 다이어그램으로 표현됨 

DBMS 선정 

여러 가지 요인들을 검토한 후 DBMS를 선정함 

기술적인 요인은 DBMS가 제공하는 데이터 모델, 저장 구조, 인터페이스, 질의어, 도구, 제공되는 서비스 등 

정치적인 요인은 고수준의 전략적인 결정 등 

경제적인 요인은 DBMS 구입 비용, 하드웨어 구입 비용, 유지 보수(서비스) 비용, 기존의 시스템을 새로운 DBMS에 맞게 변환하는데 소요되는 비용, 인건비, 교육비 등 

논리적 설계 

데이터베이스 관리를 위해 선택한 DBMS의 데이터 모델을 사용하여 논리적 스키마(외부 스키마도 포함)를 생성함 

개념적 스키마에 알고리즘을 적용하여 논리적 스키마를 생성함 

논리적 스키마를 나타내기 위해 관계 데이터 모델을 사용하는 경우에는, ER 모델로 표현된 개념적 스키마를 관계 데이터베이스 스키마로 사상함 

관계 데이터베이스 스키마를 더 좋은 관계 데이터베이스 스키마로 변환하기 위해서 정규화 과정을 적용함 

데이터베이스 설계자가 요구사항 수집과 분석 후에 바로 논리적 설계 단계로 가는 경우가 있는데, 이런 경우에는 흔히 좋은 관계 데이터베이스 스키마가 생성되지 않음 

물리적 설계 

처리 요구사항들을 만족시키기 위해 저장 구조와 접근 경로 등을 결정함 

성능상의 주요 기준은 몇 가지로 구분할 수 있음 

응답 시간: 질의와 갱신이 평균적으로 또는 피크 시간 때 얼마나 오래 걸릴 것인가? 

트랜잭션  처리율:  1초당  얼마나  많은  트랜잭션들이 평균적으로 또는 피크 시간 때 처리될 수 있는가? 

전체 데이터베이스에 대한 보고서를 생성하는데 얼마나 오래 걸릴 것인가? 

트랜잭션 설계 

요구사항 수집과 분석 후에 데이터베이스 설계 과정과 별도로 트랜잭션 설계를 진행할 수 있음 

트랜잭션은 완성될 데이터베이스에서 동작할 응용 프로그램 

데이터베이스 스키마는 트랜잭션에서 요구하는 모든 정보를 포함해야 함 

검색, 갱신, 혼합 등 세 가지 유형으로 구분하여 입력과 출력, 동작 등을 식별함 

ER 모델 

데이터베이스 설계를 용이하게 하기 위해서 P.P. Chen이 1976년에 제안하였음 

Chen이 ER 모델을 제안한 후에 많은 학자들이 이 모델을 강화시켰음 

현재는 EER(Enhanced Entity Relationship) 모델이 데이터베이스 설계 과정에 널리 사용되고 있음 

ER 모델은 쉽게 관계 데이터 모델로 사상됨 

기본적인 구문으로는 엔티티, 관계, 애트리뷰트가 있고, 기타 구문으로는 카디날리티 비율, 참여 제약조건 등이 있음 

ER 모델은 적은 노력으로 쉽게 배울 수 있고, 전문가가 아니어도 이해하기 쉬우며, 자연어보다는 좀더 정형적이고, 구현에 독립적이어서 데이터베이스 설계자들이 최종 사용자들과 의사 소통을 하는데 적합함 

ER 모델을 기반으로 만들어진 다수의 CASE 도구(예, ERWin 등)들이 존재함 

이런 도구들은 ER 설계를 자동적으로 SQL Server, 오라클, 사이베이스 등의 데이터 정의어로 변환하고, 어떤 도구는 XML로 변환함 

ER 모델은 현재는 데이터베이스 설계를 위한 다소 구형 그래픽 표기법 

엔티티 

하나의 엔티티는 사람, 장소, 사물, 사건 등과 같이 독립적으로 존재하면서 고유하게 식별이 가능한 실세계의 객체 

사원처럼 실체가 있는 것도 있지만 생각이나 개념과 같이 추상적인 것도 있음 

엔티티 타입 

엔티티들은 엔티티 타입(또는 엔티티 집합)들로 분류됨 

엔티티 타입은 동일한 애트리뷰트들을 가진 엔티티들의 틀 

엔티티 집합은 동일한 애트리뷰트들을 가진 엔티티들의 모임 

하나의 엔티티는 한 개 이상의 엔티티 집합에 속할 수 있음 

엔티티 타입은 관계 모델의 릴레이션의 내포에 해당하고, 엔티티 집합은 관계 모델의 릴레이션의 외연에 해당함 

엔티티 집합과 엔티티 타입을 엄격하게 구분할 필요는 없음 

ER 다이어그램에서 엔티티 타입은 직사각형으로 나타냄  

강한 엔티티 타입 

강한 엔티티 타입(정규 엔티티 타입)은 독자적으로 존재하며 엔티티 타입 내에서 자신의 키 애트리뷰트를 사용하여 고유하게 엔티티들을 식별할 수 있는 엔티티 타입을 의미 

약한 엔티티 타입 

약한 엔티티 타입은 키를 형성하기에 충분한 애트리뷰트 들을 갖지 못한 엔티티 타입 

이 엔티티 타입이 존재하려면 소유 엔티티 타입이 있어야 함 

소유 엔티티 타입의 키 애트리뷰트를 결합해야만 고유하게 약한 엔티티 타입의 엔티티들을 식별할 수 있음 

애트리뷰트 

하나의 엔티티는 연관된 애트리뷰트들의 집합으로 설명됨 

예:  사원  엔티티는  사원번호,  이름,  직책,  급여  등의 애트리뷰트를 가짐 

한 애트리뷰트의 도메인은 그 애트리뷰트가 가질 수 있는 모든 가능한 값들의 집합을 의미 

예: 사원번호는 1000부터 9999까지의 값을 가짐 

여러 애트리뷰트가 동일한 도메인을 공유할 수 있음 

예: 사원번호와 부서번호가 네 자리 정수를 가질 수 있음 

키 애트리뷰트는 한 애트리뷰트 또는 애트리뷰트들의 모임으로서 한 엔티티 타입 내에서 각 엔티티를 고유하게 식별함 

ER 다이어그램에서 기본 키에 속하는 애트리뷰트는 밑줄을 그어 표시함 

애트리뷰트는 요구사항 명세에서 명사나 형용사로 표현됨 

엔티티는 독립적인 의미를 갖는데 반해서 애트리뷰트는 독립적인 의미를 갖지 않음 

ER 다이어그램에서 애트리뷰트는 타원형으로 나타냄 

애트리뷰트와 엔티티 타입은 실선으로 연결 

단순 애트리뷰트(simple attribute) 

더 이상 다른 애트리뷰트로 나눌 수 없는  애트리뷰트 

ER 다이어그램에서 실선 타원으로 표현함 

ER 다이어그램에서 대부분의 애트리뷰트는 단순 애트리뷰트 

 복합 애트리뷰트(composite attribute) 

두 개 이상의 애트리뷰트로 이루어진 애트리뷰트 

동일한 엔티티 타입이나 관계 타입에 속하는 애트리뷰트 들 중에서 밀접하게 연관된 것을 모아놓은 것 

단일 값 애트리뷰트(single-valued attribute) 

각 엔티티마다 정확하게 하나의 값을 갖는 애트리뷰트 

단일 값 애트리뷰트는 ER 다이어그램에서 단순 애트리뷰트와 동일하게 표현됨 

예: 사원의 사원번호 애트리뷰트는 어떤 사원도 두 개 이상의 사원번호를 갖지 않으므로 단일 값 애트리뷰트 

ER 다이어그램에서 대부분의 애트리뷰트는 단일 값 애트리뷰트 

다치 애트리뷰트(multi-valued attribute) 

각 엔티티마다 여러 개의 값을 가질 수 있는 애트리뷰트 

ER 다이어그램에서 이중선 타원으로 표현함 

저장된 애트리뷰트(stored attribute) 

다른 애트리뷰트와 독립적으로 존재하는 애트리뷰트 

ER 다이어그램에서 단순 애트리뷰트와 동일하게 표현됨 

ER 다이어그램에서 대부분의 애트리뷰트는 저장된 애트리뷰트 

예: 사원 엔티티 타입에서 사원이름, 급여는 다른 애트리뷰트와 독립적으로 존재함 

유도된 애트리뷰트(derived attribute) 

다른 애트리뷰트의 값으로부터 얻어진 애트리뷰트 

유도된 애트리뷰트는 관계 데이터베이스에서 릴레이션의 애트리뷰트로 포함시키지 않는 것이 좋음 

ER 다이어그램에서 점선 타원으로 표현함 

예 : 애트리뷰트들의 유형 

아래 그림에서 단순 애트리뷰트, 복합 애트리뷰트, 단일 값 애트리뷰트, 다치 애트리뷰트, 키애트리뷰트, 저장된 애트리뷰트, 유된 애트리뷰트들을 구분하라 

약한 엔티티 타입 

 약한 엔티티 타입은 키를 형성하기에 충분한 애트리뷰트들을 갖지 못한 엔티티 타입 

약한 엔티티 타입에게 키 애트리뷰트를 제공하는 엔티티 타입을 소유 엔티티 타입(owner entity type) 또는 식별 엔티티 타입(identifying entity type)라고 부름 

ER 다이어그램에서 약한 엔티티 타입은 이중선 직사각형으로 표기 

약한 엔티티 타입의 부분 키는 점선 밑줄을 그어 표시  

 부분 키(partial key): 부양가족의 이름처럼 한 사원에 속한 부양가족 내에서는 서로 다르지만 회사 전체 사원들의 부양가족들 전체에서는 같은 경우가 생길 수 있는   애트리뷰트 

관계와 관계 타입 

 관계는 엔티티들 사이에 존재하는 연관이나 연결로서 두 개 이상의 엔티티 타입들 사이의 사상으로 생각할 수 있음 

관계 집합은 동질의 관계들의 집합 

관계 타입은 동질의 관계들의 틀 

관계 집합과 관계 타입을 엄격하게 구분할 필요는 없음 

요구사항 명세에서 흔히 동사는 ER 다이어그램에서 관계로 표현됨 

ER 다이어그램에서 다이어몬드로 표기 

관계 타입이 서로 연관시키는 엔티티 타입들을 관계 타입에 실선으로 연결함 

관계의 애트리뷰트 

관계 타입은 관계의 특징을 기술하는 애트리뷰트들을 가질 수 있음 

관계 타입은 키 애트리뷰트를 갖지 않음 

차수(degree) 

관계의 차수는 관계로 연결된 엔티티 타입들의 개수를 의미 

실세계에서 가장 흔한 관계는 두 개의 엔티티 타입을 연결하는 2진

 카디날리티 

카디날리티 비율은 한 엔티티가 참여할 수 있는 관계의 수를 나타냄 

관계 타입에 참여하는 엔티티들의 가능한 조합을 제한함 

관계를 흔히 1:1, 1:N, M:N으로 구분 

카디날리티에 관한 정보는 간선 위에 나타냄  

1:1 관계 

E1의 각 엔티티가 정확하게 E2의 한 엔티티와 연관되고, E2의 각 엔티티가 정확하게 E1의 한 엔티티와 연관되면 이 관계를 1:1 관계라고 함 

예: 각 사원에 대해 최대한 한 개의 PC가 있고, 각 PC에 대해 최대한 한 명의 사원이 있으면 사원과 PC 간의 관계는 1:1 관계 

1:N 관계

E1의 각 엔티티가 E2의 임의의 개수의 엔티티와 연관되고, E2의 각 엔티티는 정확하게 E1의 한 엔티티와 연관되면 이 관계를 1:N 관계라고 함 

예: 각 사원에 대해 최대한 한 대의 PC가 있고, 각 PC에 대해 여러 명의 사원들이 있으면 PC와 사원 간의 관계는 1:N 관계 

실세계에서 가장 흔히 나타나는 관계 

M:N 관계 

한 엔티티 타입에 속하는 임의의 개수의 엔티티가 다른 엔티티 타입에 속하는 임의의 개수의 엔티티와 연관됨 

예: 각 사원에 대해 여러 대의 PC가 있고, 각 PC에 대해 여러 명의 사원들이 있으면 사원과 PC 간의 관계는 M:N 관계 

카디날리티 비율의 최소값과 최대값 

ER 다이어그램에서 관계 타입과 엔티티 타입을 연결하는 실선 위에 (min, max) 형태로 표기 

어떤 관계 타입에 참여하는 각 엔티티 타입에 대하여 min은 이 엔티티 타입 내의 각 엔티티는 적어도 min 번 관계에 참여함을 의미 

max는 이 엔티티 타입 내의 각 엔티티는 최대한 max 번 관계에 참여함을 의미 

min=0은 어떤 엔티티가 반드시 관계에 참여해야 할 필요는 없음을 의미 

max=*는 어떤 엔티티가 관계에 임의의 수만큼 참여할 수 있음을 의미 

역할(role) 

관계 타입의 의미를 명확하게 하기 위해 사용됨 

특히 하나의 관계 타입에 하나의 엔티티 타입이 여러 번 나타나는 경우에는 반드시 역할을 표기해야 함 

관계 타입의 간선 위에 표시 

전체 참여와 부분 참여 

전체 참여는 어떤 관계에 엔티티 타입 E1의 모든 엔티티들이 관계 타입 R에 의해서 어떤 엔티티 타입 E2의 어떤 엔티티와 연관되는 것을 의미 

부분 참여는 어떤 관계에 엔티티 타입 E1의 일부 엔티티만 참여하는 것을 의미 

약한 엔티티 타입은 항상 관계에 전체 참여 

 전체 참여는 ER 다이어그램에서 이중 실선으로 표시 

카디날리티 비율과 함께 참여 제약조건은 관계에 대한 중요한 제약조건 

ER 스키마를 작성하기 위한 지침 

엔티티는 키 애트리뷰트 이외에 설명 정보를 추가로 가짐  

다치 애트리뷰트는 엔티티로 분류해야 함 

애트리뷰트들이 직접적으로 설명하는 엔티티에 애트리뷰트들을 붙임 

가능한 한 복합 식별자를 피함 

관계는 일반적으로 독자적으로 존재할 수 없지만 엔티티 타입과 관계 타입을 절대적으로 구분하는 것은 어려움 

1. 튜플 관계해석 

 관계 해석 

- 관계 데이터베이스 관리에서 관계를 조작하기 위한 비절차적인 방법의 하나 

 비절차적 방법 

- 무엇인지만(what)을 명시하고 질의를 어떻게 수행할 것인가는 명시하지 않는 것을 의미 

튜플 관계 해석(tuple relational calculus) 

- 원하는 릴레이션을 튜플 해석식(tuple calculus ex  pression)으로 정의하는 표기법 

- 대표적인 언어로는 QUEL 

정의 

{ t1.A1, t1.A1, …, tn.An｜F(t1, … tn, tn+1, …, tn+m) } 

주문 릴레이션 

'주문' 릴레이션 고객번호가 200인 고객이 주문한 주문수량과 주문액수를 검색 

예  {a.주문수량, a.주문액수 | a(주문) ∧ a.고객번호=200} 

튜플 변수

- 튜플 변수는 지정된 릴레이션의 튜플을 하나씩 그 값으로 취할 수 있는 변수 

- 범위 변수(range variable)라고도 함 

정의 

- 튜플 해석식에서 범위식은 주문(a) 

R(t) 

예 

{a.주문수량, a.주문액수 | a(주문) ∧ a.고객번호=200} 

한정 어트리뷰트와 원자식 

- 릴레이션 R에 대해 튜플 변수  t가 나타내는 튜플의 어떤 어트리뷰트 A의 값을 표현 

예  {a.주문수량, a.주문액수 | a(주문) ∧ a.고객번호=200} 

튜플 해석식에서 한정 어트리뷰트는 a.주문수량, a.주문액수, a.고객번호

- a.주문수량은 튜플 변수 a가 가리키는 주문 튜플의 어트리뷰트 주문수량의 값을 나타내는 한정 어트리뷰트 

 원자식  

- 튜플 해석식의 가장 기본이 되는 식으로 범위식과 조건식과 같은  형태 

- 범위식에 해당하는 a(주문), 조건식에 해당하는 a.고객번호=200을 예로 들수 있음 

정형식 

- 원자식, AND 연산자인 ∧과 OR 연산자인 ∨과 NOT 연산자인  ￢  그리고 정량자(∀,∃)가 결합된 식 

정량자(quantifier) 

- 전칭 정량자(Universal quantifier)와 존재 정량자(Existential quantifier) 

전칭 정량자  

- ∀로 표현하며 “for all”이라고 읽음.  

- 전칭 정량자를 사용한 정형식은 모든 가능한 튜플 t에 대해 정형식 F(t)가 참일 때 참이 된다는 뜻 

정의 (∀t)(F(t)) 

존재 정량자 

- ∃로 표현하며 “there exists”라고 읽음 

- 존재 정량자를 사용한 정형식은 정형식 F(t)를 참으로 만드는 어떤 튜플 t가 하나라도 존재만 한다면 참이 된다는 뜻 

정의  (∃t)(F(t)) 

- ‘하드디스크’를 주문한 모든 고객의 고객번호를 검색하는 관계 해석 

예  {a.고객번호|a(주문) ∧ (∃b)(b(제품) ∧ a.제품번호=b.제품번호 ∧ b.제품명= ‘하드디스크’)} 

2. 도메인 관계 해석 

도메인 관계 해석 

- 원하는 릴레이션을 도메인 해석식(domain calculus expression)으로 정의하는 표기법 

정의 { x1,x2,…,xn｜F(x1,…, xn, xn+1,…, xn+m)}  

등록(enrol) 릴레이션 

도메인 해석식의 예로 과목번호 002의 과목이수자의 학번과 성적을 검색 

예 {eSno, eGrade|enrol(eCno, eSno, eGrade) ∧ eCno=002} 

1. 순수 관계 연산자 

관계대수 

- 원하는 데이터를 얻기 위해서 어떻게(how) 질의를 수행할 것인지 일련의 연산을 순서대로 명시해야 하는 절차적 언어 

관계해석 

- 원하는 데이터가 무엇인지만(what)을 명시하고 질의를 어떻게 수행할 것인가는 명시하지 않는 비절차적 언어 

 대수 

- 수 대신 문자를 사용해서 문제를 쉽게 하고, 수학적인 법칙을 간단하고 명확하게 표현하는 것 

 관계 대수 

- 데이터베이스에 저장된 데이터를 문자와 사용한 연산을 통해 요청한 

데이터를 정보화하여 얻을 수 있는데  그 원리가 산술 연산자와 유사 

 순수 관계 연산자 

- SELECT, PROJECT, JOIN, DI­VISION 

 일반 집합 연산자 

- 합집합, 교집합, 차집합, 카티션 프로덕트(Cartesian Product) 

셀렉트(SELECT, σ), 셀렉트연산 

- 릴레이션에서 주어진 조건에 만족하는 튜플을 선택하는 연산자 

- 표기 형식은 그리스 문자 시그마(sigma)를 사용한 연산자 기호인 σ를 사용 (단, R은 릴레이션) 

ex) 학생 릴레이션에 대한 셀렉트 연산 

σ 점수≥80(학생) 

프로젝트(PROJECT, π), 프로젝트연산 

- 주어진 릴레이션에서 어트리뷰트 리스트에 제시된 어트리뷰트만을 추출하는 연산자 

ex) π 이름, 전공(학생) 

조인(JOIN, ▷◁), 조인 연산 

- 공통 속성을 중심으로 두 개의 릴레이션을 하나로 합쳐서 새로운 릴레이션 

- 연산자의 종류에는 세타 조인(theta join), 동등 조인(equi join), 자연 

조인(natural join), 외부 조인(outer join), 세미 조인(semi join) 

세타 조인 

- 두 릴레이션 R(A1, A2, ..., An)과 S(B1, B2, ..., Bm)의 세타 조인

한 결과로 얻어지는 차수는 릴레이션 R의 차수와 릴레이션 S의 차수를 합한 것(n+m) 

- 어트리뷰트는 (A1, A2, ..., An, B1, B2, ..., Bm)이며, 조인 조건을 

만족하는 튜플들로 이루어진 릴레이션 세타는  { =, <>, <=, <, >=, > } 중의 하나 

동등 조인(equi join) 

- 세타 조인 중에서 비교 연산자가 =인 조인이고 표기 형식은 그리스문자 ▷◁를 사용 

 학생 ▷◁ 학번=학번 성적 

자연 조인  

- 동등 조인 결과로 얻어진 불필요한 중복되는 어트리뷰트를 한 개 제외한 조인 

ex) 학생 ▷◁N 성적 

외부 조인 

- 상대 릴레이션에서 대응되는 튜플을 갖지 못하는 튜플이나 조인 어트리뷰트에 널 값이 들어 있는 튜플들을 

다루기 위해서 조인 연산을 확장한 조인 

- 외부 조인의 종류로는 왼쪽 외부 조인(left outer  join), 오른쪽 외부 조인(right outer  join), 완전 외부 조인(full outer join) 

왼쪽 외부 조인 

오른쪽 외부 조인 

디비전(DIVISION, ÷), 디버전연산 

 - X ⊃ Y인 2개의 릴레이션에서 R(X)와 S(Y)가 있을 때, R의 속성이  

S의 속성값을 모두 가진 튜플에서 S가 가진 속성을 제외한 속성만을 구하는 연산 

R [속성r ÷ 속성s] S  

디비전 

합집합(UNION, ∪) 

- R ∪ S는 R 또는 S에 있거나 R과 S 모두에 속한 튜플들로 이루어진 릴레이션 

정의 

R∪S = {t|t∈R ∨ t∈S} 

R, S에 속하는 모든 튜플의 집합 

합집합 

교집합(INTERSECT, ∩) 

- R ∩ S는 R과 S 모두에 속한 튜플들로 이루어진 릴레이션  

정의 

R∩S = {t|t∈R ∧ t∈S} 

R, S 양쪽 모두에 속하는 모든 튜플의 집합 

교집합 

차집합(DIFFERENCE, -) 

- R ­ S는 R에는 속하지만 S에는 속하지 않는 튜플들로 이루어진 릴레이션 

정의 

R그S = {t|t∈R ∧ t    S} 

R에는 속하고, S에는 속하지 않는 모든 튜플의 집합 

차집합 

카티션 프로덕트 연산자(CARTESIAN PRODUCT,×) 

- R × S는 차수가 n+m이고, 카디날리티가  i*j이고, 어트리뷰트가 (A1, 

A2, ..., An, B1, B2, ..., Bm)이며, R과 S의 튜플들의 모든 가능한 조합으로 이루어진 릴레이션 

정의 

R×S ＝ { r·s | r∈R ∧ s∈S } 

R과 S의 접속인 모든 튜플의 집합 

카티션 프로덕트 연산자 

외부 합집합 

- ∪+는 완전하게 합병 가능하지 않은 두 릴레이션을 합집합으로 만드는 것 

1. 제1정규형, 제2정규형 

정규화 

- 주어진 릴레이션 스키마를 함수적 종속성 등의 종속 이론을 이용하여 잘

못된 릴레이션 스키마를 보다 더 작은 속성의 세트로 나누어서 갱신 이

상이 발생하지 않는 바람직한 릴레이션 스키마로 만들어 가는 과정 

정규화 (Normal Form) 

- 테이블의 정규화된 정도 

정규형들 간의 관계

제1정규형(1NF) 

      제1정규형에 만족하는 릴레이션 

- 어떤 릴레이션 R에 속한 모든 도메인이 원잣값(atomic value) 

- 릴레이션의 속성값이 반복 집단이 없는 즉, 더 이상 분해될 수 없는 원잣

값으로만 구성 

 반복 집합이 있는 비정규 릴레이션 

- 반복 집합은 한 개의 기본키 값에 대해서 두 개 이상의 값을 가질 수 있

는 속성 

제2정규형(2NF) 

 제2정규형 

- 어떤 릴레이션 R이 제1정규형이고, 키에 속하지 않는 속성 모두가  

키에 완전 함수 종속 

 제2정규화 과정의 함수 종속 다이어그램 

 무손실 분해(nonloss decomposition) 

- 자연 조인하였을 때 아무런 정보 손실 없이 다시 원래의  

릴레이션으로 복귀된다면 2NF로 두 개의 릴레이션으로  

분해하는 것 

2. 제3정규형 

제3정규형(3NF) 

- 어떤 릴레이션 R이 2NF이고, 모든 속성들이 기본키에 이행적 함수 종속

(transitive FD)을 제외 

 이행적 함수 종속성 

- 3개의 속성에 존재하는 함수의 종속성을 의미 

 이행적 함수 종속으로 인한 갱신 이상 

- 수정 이상 

 이행적 함수 종속으로 인한 갱신 이상 

- 삽입 이상 

 이행적 함수 종속으로 인한 갱신 이상 

- 삭제 이상 

3. 보이스/코드 정규형 

보이스/코드 정규형 

- 복잡한 식별자 관계에 의해 발생하는 문제를 해결하기 위해서 제3정규형을 보완한 것 

- 릴레이션 R이 제3정규형을 만족하고, 모든 결정자가 후보키 

- 수정 이상 

 결정자가 후보키가 아닌 릴레이션에서의 갱신 이상

- 삽입 이상 

결정자가 후보키가 아닌 릴레이션에서의 갱신 이상 

- 삭제 이상  

결정자가 후보키가 아닌 릴레이션에서의 갱신 이상 

- 정규형의 특징과 정규화 과정

1. 수정 이상 

정규화의 의미 

 정규화(normalization) 

- 자료 저장 공간을 최소화하고 데이터베이스 내의 데이터가  

불일치 되는 위험을 최소화하여 좋은 데이터베이스 스키마를 설계하는 것을 목적 

데이터베이스 스키마가 잘못 설계된 경우 

- 100번 학생이 전자계산기구조와 운영체제라는 두 과목을 신청하였기에 이 학생의 이름은 두 번 저장되는 

문제점 발생 

- 중복된 데이터의 저장으로 인해 저장 공간이 낭비된다는 문제점 이외에도 중복되어 저장된 데이터 때문에 

릴레이션의 수정, 삽입, 삭제와 같은 조작을 할 때 여러 가지 곤란한 이상(anomaly) 현상이 생김 

수정 이상

- 중복 데이터 중에서 일부만 갱신되어 정보의 모순이 발생하는 것 

2. 삽입 이상, 삭제 이상 

삽입 이상 

- 불필요한 정보를 함께 저장하지 않음 

- 어떤 정보를 저장하는 것이 불가능하기에 원하지 않는 정보를 강제로 삽입해야 하는 것 

삭제 이상 

- 유용한 정보를 함께 삭제하지 않고는 어떤 정보를 삭제하는 것이 불가능한 것  

 정규화(normalization) 

- 갱신 이상이 생기지 않도록 불필요한 데이터가 중복되어 저장되지  

않게 방지하여 바람직한 릴레이션 스키마로 만들어 가는 과정 

 정규화의 목적 

- 반복적인 자료를 제거하여 다음과 같은 상태를 만들기 위한 것 

1.  어떤 관계라도 데이터베이스 내에서 표현이 가능하도록 만드는 것 

2.  관계에서 바람직하지 않은 삽입, 삭제, 갱신 이상이 발생하지 않도록 함 

3.  새로운 형태의 데이터가 삽입될 때 관계를 재구성할 필요성을 줄일 수 있음 

4.  보다 간단한 관계 연산에 기초하여 검색을 보다 효율적으로 할 수 있음 

3. 함수 종속 

  함수적 종속 정의 

- X → Y 

  결정자(determinant) 

- 주어진 릴레이션에서 다른 속성(또는 속성들의 집합)을 고유하게 결정하는 하나 이상의 속성 

 함수적 종속의 성질 

- 완전 함수 종속(FFD: Full Functional Dependency) 

- 부분 함수 종속(PFD: Partial Functional Dependency) 

  함수 종속 다이어그램 

- 릴레이션 내의 속성들의 종속 관계를 보다 쉽게 이해하기 위해서는  

이를 도식적으로 표현 

1. 키의 개념 및 종류 

 릴레이션의 특징 중의 하나가 한 릴레이션에 포함된 튜플들은 모두 달라야 한다는 것이었다. 

 릴레이션은 튜플의 집합이기에 튜플을 저장하다 보면 다음과 같은 정보를 삽입해야 할 경우가 생긴다. 

 이상(anomaly) 현상 

- 데이터가 중복 저장되면 릴레이션 조작 시 예상하지 못한 곤란한 현상이 발생하는 현상 

 키 

- 속성 혹은 속성의 집합으로 튜플을 고유하게 식별할 수 있도록 하는 속성 혹은 속성의 집합 

- 데이터를 검색하거나 정렬할 때 기준이 되는 유일하게 구분되는 속성으로 수퍼키, 후보키, 기본키, 외래키 등이 있음

수퍼키와 후보키 

 수퍼키(Super Key) 

- 릴레이션을 구성하는 속성들 중에서 각 튜플을 유일하게 식별하기 위해 사용하는 하나 혹은 그 이상의 속성들의 집합 

- 유일성이란 하나의 키 값으로 하나의 튜플만을 유일하게 식별할 수 있는 성격 

- 최소성은 모든 레코드들을 유일하게 식별하는데 꼭 필요한 속성으로만 구성되어야 하는 성질

 후보키(candidate key) 

- 릴레이션을 구성하는 속성들 중에서 각 튜플을 유일하게 식별하기 위해 사용하는 하나 혹은 그 이상의 속성들의 집합 

- 수퍼키와의 공통점 :  릴레이션에 있는 각 튜플을 고유하게 식별할 수 있어야 한다는 점 

- 수퍼키와의 차이점 :  최소한의 속성으로 구성된 유일성을 갖는 속성의 집합 

기본키 (Primary key : PK) 

- 후보키 중 튜플을 식별하는데 기준으로 사용하는 키 

- 후보키 중에서 선택한 것이기에 한 릴레이션에서 특정 튜플을 유일하게 구별할 수 있는 속성 

- Null 값을 가질 수 없음  

- 기본키로 정의된 속성에는 동일한 값이 중복되어 저장될 수 없음 

*Null 값은 데이터베이스에서 아직 알려지지 않거나 모르는 

값으로써 “해당없음” 등의 이유로 정보 부재를 나타내기 위해 

사용하는, 이론적으로 아무것도 없는 특수한 데이터를 말한다. 

대체키 (Alternate key) 

- 후보키가 둘 이상일 때 기본키로 선택되지 않은 나머지 후보키 

- 보조키라고도 함 

- 사원번호를 기본키로 정의하였다면 주민번호가 대체키가 됨 

복합키 

- 하나의 칼럼이 후보키의 역할을 하지 못함 

- 두 개 이상의 칼럼이 합쳐져야 후보키의 역할을 하는 경우를 말함 

외래키 (Foreign Key) 

- 상호 관련이 있는 테이블들 사이에서 데이터의 일관성을 보장해 주는 수단 

 외래키의 필요성을 설명하기 위해서 다음과 같은 질문 

- CASE1 부서 릴레이션의 첫 번째 튜플이 삭제된다면 어떻게 될까? 

- CASE2 부서 릴레이션의 20번 부서 번호가 50으로 변경된다면 어떻게 될까? 

- CASE3 사원 릴레이션에 부서 번호 60인 사원이 삽입된다면 어떻게 될까? 

2. 무결성 제약조건 

개체 무결성

- 개체가 결점이 없음을 의미 

- 결점이 없는 무결한 개체가 되려면 데이터베이스에 저장되어 관리될 때 본질적으로 서로 구별될 수 있어야 함 

- 개체를 유일하게 식별하기 위해서는 당연히 식별자가 반드시 있어야 함 

릴레이션을  구성하는  속성  중의  하나를  기본키로 

지정하여 널(NULL) 값이나 중복된 값을 가질 수 없는 

속성을  갖도록 하여  언제  어느  때고  개체가 유일하게 

식별 가능하도록 하는 것이 ‘개체 무결성 제약조건’이다. 

- 기본키 값이 널 값을 갖게 된다면 튜플을 유일하게 식별할 수 없게 됨 

- 튜플을 유일하게 식별할 수 없게 되면 서로 구별할 수 없는 개체가 존재하게 된다는 의미가 되기에 개체 무결성에 위배됨 

- 기본키의 유일한 식별성을 잃지 않도록 하기 위해서는 중복되는 값을 갖지 말아야 함 

- 동시에 널 값 역시 포함되어서는 안 된다. 

- 특정 개체가 무결성을 유지하도록 하기 위해서 릴레이션을 생성하는 데

이터 정의문에서 어떤 속성이 릴레이션의 기본키인지를 알려주어야 함 

- 기본키로 제약조건을 지정한 속성은 널(NULL) 값이나 중복된 값을 가질 수 없음 

 예 

    ‘사원’ 릴레이션에서 ‘사원번호’가 기본키로 정의되면 튜플을 추가할 때 

‘주민번호’나 ‘  성명’ 필드에는 값을 입력하지 않아도 되지만 ‘사원번호’ 

속성에는 반드시 값이 입력되어야 한다. 또한 ‘사원번호’ 속성에는 이미 한 

번 입력한 속성값을 중복하여 입력할 수 없다. 

참조 무결성 

- 참조 무결성은 릴레이션 간에 적용되는 제약조건 

- 릴레이션 모델에서는 두 객체 간의 관계를 외래키 혹은 릴레이션으로 표현함 

외래키를 통해 릴레이션은 참조할 수 없는 외래키 값을 가질 

수  없도록  함으로써  두  테이블  간의  데이터  무결성을 

유지하는 것을 ‘참조 무결성 제약조건’이라고 한다. 

예 

‘사원’ 릴레이션의 ‘부서 번호’ 속성에는 ‘부서’ 릴레이션의 

‘부서 번호’ 속성에 없는 값은 입력할 수 없다. 

 참조 무결성 제약조건의 유지 

- 두 테이블 간에 외래키에 의한 참조 관계에 있고 두 테이블 간 데이터 불

일치가 발생하는 상황이 될 때, DBMS는 제한(restrict), 연쇄(cascade), 

널 값으로 대체(nullify)와 같은 조치를 취할 수 있다. 

 부서테이블의 첫 번째 튜플을 삭제하려 할 때 

- 제한(restrict)은 삭제하려는 튜플의 부서 번호 값을 사원 테이블에서 가

지고 있는 튜플이 있으므로 삭제 연산을 거절 

- 연쇄(cascade)는 삭제된 부서 번호 값을 갖는 사원 테이블의 튜플도 함께 삭제 

- 널 값으로 대체(nullify)는 삭제연산을 수행한 뒤 삭제된 부서 번호 값을 

갖는 사원 테이블의 튜플에서 부서 번호를 null 값으로 대체 

레이션(Relation) = 테이블  

 관계형 데이터베이스 

- 현재 가장 많이 사용되고 있는 데이터베이스 

- 엔티티(Entity)나 관계(Relation)를 모두 행과 열로 구성된 표 형식으로 데이터를 관리 

 릴레이션(Relation) = 테이블 

- 관계형 데이터베이스에서 정보를 구분하여 저장하는 기본 단위 

 릴레이션 스키마 

- 릴레이션 이름과 일정수의 속성들의 집합으로 구성 

 릴레이션 인스턴스 

- 어느 한 시점에서 릴레이션에 포함되어 있는 튜플의 집합 

속성(Attribute) = 열 

- 릴레이션에서 관리하는 구체적인 정보 항목에 해당하며 엔티티의 특성을 기술  

튜플(Tuple) = 행 

- 속성의 모임으로 구성 

- 릴레이션에서 각각의 행에 해당 

- 파일 구조에서 레코드와 같은 의미 

ex) ‘사원’은 릴레이션을 나타내는 이름이고 ‘사원번호 : 101, 이름 : 김사랑, 

직급 : 사원, 급여 : 250, 부서명 : 인사부’는 ‘사원’ 

릴레이션을 구성하는 튜플이다.  

 튜플의 수를 카디날리티(Cardinality, 기수, 대응수)라고 함. 

도메인(Domain) 

 도메인 

- 릴레이션에 포함된 각각의 속성들이 취할 수 있는 같은 타입의 원자(atomic) 값들의 집합 

 도메인의 정의에 대한 예 

- CREATE DOMAIN DEMPNO INTEGER 

- CREATE DOMAIN DEMPNAME VARCHAR(30) 

- CREATE DOMAIN DSALARY INTEGER 

 도메인이라는 개념이 필요한 이유 

- 릴레이션에 저장되는 데이터 값들이 본래 의도했던 값들만 저장되고 관리되도록 하는데 있음.  

릴레이션 스키마와 인스턴스 

 릴레이션 

- 릴레이션 스키마(릴레이션 타입) + 릴레이션 인스턴스(릴레이션 어커런스) 

정의 

릴레이션이름 (기본키, 속성이름, 속성이름, … 속성이름n) 

 문제(3.1) 

- 사원(사원번호, 이름, 직급, 주민번호, 급여, 부서명) 

 사원 릴레이션 스키마에서 릴레이션의 이름, 속성, 기본키

를 구별해 보자. 

릴레이션 이름    : 사원

기본키            : 사원번호

속성                : 이름, 직급, 주민번호, 급여, 부서명

속성간의 순서 

 릴레이션을 구성하는 속성 간의 순서는 중요하지 않다. 

- 한 릴레이션 내의 속성들의 순서를 바꾼다고 해서 다른 릴레이션이 되지는 않음 

- 관계 데이터베이스에서 속성값은 릴레이션 내에서의 속성의 위치에 의해서가 아니고 속성 이름에 의해서 참조되기 때문 

상이한 튜플 

 한 릴레이션에 포함된 튜플들은 모두 다르다.  

- 릴레이션의 각 튜플을 살펴보면 어떠한 튜플도 정확하게 동일한 값을 갖지 않음 

- 릴레이션은 튜플의 집합이기에 튜플을 유일하게 식별하기 위해 고유한 값을 저장하는 속성이 적어도 한 개 있어야 함 

- 키는 속성 혹은 속성의 집합으로 키 덕분에 테이블에 중복된 튜플이 존재할 수 없게 됨 

예  

    <부서> 테이블의 부서 번호나 <사원> 테이블의 사원번호 혹은 주민번호가 키에 해당한다. 

튜플의 순서 

 릴레이션에 포함된 튜플의 순서는 중요하지 않다.  

- 튜플이 물리적으로 저장될 경우에는 저장하는 순서에 따라서 튜플의 순

서가 정해지고 출력을 하게 되면 먼저 저장된 것이 위에, 나중에 저장된 

것이 아래에 출력됨 

- 대규모 릴레이션일 경우 튜플의 위치를 일일이 기억한다는 것은 불가능

하고 그럴 이유도 없음 

- 실질적으로 상용되는 DBMS는 효율성을 위해서 튜플의 순서를 바꿀 수 

있는 여러 가지 방법을 제공하여 릴레이션에 포함된 튜플의 순서는 무의미 

릴레이션의 변동성 

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

속성의 명칭과 값  

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

튜플의 속성 

 속성은 더 이상 쪼갤 수 없는 원잣값만을 저장해야 한다. 

- 속성에는 여러 개의 값들을 리스트나 집합 형태로 저장할 수 없음 

- 하나의 속성이 두 개 이상의 값을 갖게 되면 릴레이션을 하나 추가한 후에 이를 참조할 수 있도록 해야 함