20201026_22 제약조건

DROP TABLE account_info CASCADE CONSTRAINT를 하면 전에 제약조건 걸어놓은것? 까지 다 삭제

 

 

 

 

• ON DELETE CASCADE

CREATE TABLE account_info (
    id NUMBER PRIMARY KEY,
    email VARCHAR2(128) NOT NULL,
    CONSTRAINT account_info_email_uq UNIQUE (email),
    CONSTRAINT account_info_email_length_chk CHECK (length(email) > 3)
);

INSERT INTO account_info(id, email) VALUES(1, 'abc@gmail.com');
SELECT * FROM account_info;
CREATE TABLE account_authentication (
    id NUMBER PRIMARY KEY,
    account_info_id NUMBER REFERENCES account_info(id) ON DELETE CASCADE
);
INSERT INTO account_authentication(id, account_info_id) VALUES (1, 1);
-- 테이블 account_info 생성
DROP TABLE account_info CASCADE CONSTRAINTS;
CREATE TABLE account_info (
    id NUMBER PRIMARY KEY,
    email VARCHAR2(128) NOT NULL,
    CONSTRAINT account_info_email_uq UNIQUE (email),
    CONSTRAINT account_info_email_length_chk CHECK (length(email) > 3)
);

-- 값 넣기
INSERT INTO account_info(id, email) VALUES(1, 'abc@gmail.com');
-- 값 확인
SELECT * FROM account_info;

-- 테이블 account_authentication 생성
DROP TABLE account_authentication CASCADE CONSTRAINTS;
CREATE TABLE account_authentication (
    id NUMBER PRIMARY KEY,
    account_info_id NUMBER REFERENCES account_info(id) ON DELETE CASCADE
);

-- account_authentication에 값 넣기
INSERT INTO account_authentication(id, account_info_id) VALUES (1, 1);
-- account_authentication 값 확인
SELECT * FROM account_authentication;

-- 부모테이블 account_info 확인
SELECT * FROM account_info;
-- 부모테이블의 값 삭제
DELETE FROM account_info WHERE id = 1;

-- 실제로 영향을 받았는지 확인
SELECT * FROM account_info;
SELECT * FROM account_authentication;

부모테이블에서 삭제하면 자식테이블에서도 같이 삭제가 된다

 

 

 

• default

CREATE TABLE account_info (
    id NUMBER PRIMARY KEY,
    email VARCHAR2(128) NOT NULL,
    created_date TIMESTAMP DEFAULT SYSDATE,
    CONSTRAINT account_info_email_uq UNIQUE (email),
    CONSTRAINT account_info_email_length_chk CHECK (length(email) > 3)
);

INSERT INTO account_info(id, email) VALUES(1, 'abc@gmail.com');
SELECT * FROM account_info;

디폴트로 걸어놓으면 됨

 

 

 

 

• 롤

롤은 여러 권한을 하나의 이름으로 묶어둔 것이라고 생각하면 쉽다.
사전 정의된 롤은 크게 세 가지가 존재하는데 다음과 같다.

• CONNECT: 사용자가 데이터 베이스에 접속 가능하도록 하기위한 CREATE SESSION 권한이 있는 ROLE
• RESOURCE: CREATE 구문을 통해 객체를 생성할 수 있는 권한과 INSERT, UPDATE, DELETE 구문을 사용할 수 있는 권한을 모아 놓은 ROLE.
• DBA: 대부분의 권한을 가지고 있는 롤

일반적으로 DB를 사용하기 위해서는 다음과 같이 사용자에게 권한을 부여해줄 수 있다.

GRANT CONNECT, RESOURCE TO 사용자_이름;

 

 

 

 

 

제약 조건(constraint)

저장할 데이터에 걸리는 특수 규칙이 바로 제약 조건이다. 제약 조건은 DB에 저장될 데이터의 정합성 및 무결성 유지하기 위해 사용된다.

• 정합성: 데이터가 제대로 들어갔는지
• 무결성: 말이 되는 데이터가 들어갔는지
  • 참조하는 부모가 없다던지
  • 있어야 할 데이터가 없다던지
  • 중복되면 안되는데 중복이 됐다던지

결론
사용자가 원하는 조건의 데이터만 유지하기 위해서 특정 컬럼에 설정하는 제약으로 데이터 무결성을 지키기 위해 제한된 조건.

 

 

• 외래키참조형식
  
  CONTRAINT 제약조건이름
  FOREIGN KEY 지정한 칼럼
  REFERENCES 참조할 테이블(참조할테이블칼럼)

 

• 제약조건예제
  

CREATE TABLE account_authentication (
    id NUMBER,
    password VARCHAR2(128) CONSTRAINT account_authentication_nn NOT NULL,
    account_info_id NUMBER,   
    CONSTRAINT account_authentication_Pk PRIMARY KEY (id),
    CONSTRAINT account_authentication_fk FOREIGN KEY (account_info_id) REFERENCES account_info(id),
    CONSTRAINT aa_pwd_length_chk CHECK (length(password)>7 )
);

 

 

 

 

• default sysdate

CREATE TABLE account_info(
    id NUMBER PRIMARY KEY,
    email VARCHAR2(128),
    created_date TIMESTAMP DEFAULT SYSDATE,
    CONSTRAINT account_info_emil_uq UNIQUE (email)   
    );