ctrl+alt+t 눌러서 터미널을 연다


sudo vi /etc/mysql/my.cnf


[client]

default-character-set=utf8


[mysql]

default-character-set=utf8



[mysqld]

collation-server = utf8_unicode_ci

init-connect='SET NAMES utf8'

character-set-server = utf8


$ service mysql restart



혹은



# client 부분밑에 추가

[client]

default-character-set = utf8


mysqld 부분밑에 추가

[mysqld]

init_connect = SET collation_connection = utf8_general_ci

init_connect = SET NAMES utf8

character-set-server = utf8

collation-server = utf8_general_ci


mysqldump 부분밑에 추가

[mysqldump]

default-character-set = utf8


# mysql 부분밑에 추가

[mysql]

default-character-set = utf8


다 셋팅 하고나서
sudo /etc/init.d/mysql restart로 재시작!


출처: http://bizadmin.tistory.com/entry/우분투-Linux-mysql-한글-설정-하기 [Happy Resource]

출처:https://otoong.tistory.com/entry/MYSQL-%EB%AC%B8%EC%9E%90%EC%97%B4-%ED%83%80%EC%9E%85-1-column-type


 MySQL의 문자열 타입은 주로 텍스트를 저장하는데 쓰이지만, 임의의 데이터를 담을 수 있는 범용 타입이다. 이 타입들은 최대 길이가 변하는 값들을 담을 수 있고 대 소문자를 구별해서 처리하는 지에 따라 선택할 수 있다.

MySQL 4.1부터 CHAR, VARCHAR 그리고 TEXT 타입에 대해 문자 세트를 특정 칼럼에 적용할 수 있다. 문법은 CHARACTER SET charset 이고, 여기서 charset은 latin1, greek혹은 utf8과 같은 문자 세트 식별자이다. 서버에 의해 지원되는 허용되는 문자 세트는 SHOW CHARACTER SET문을 실행해서 정해질 수 있다. CHAR이나 VARCHAR 칼럼에 대해 문자 세트를 적용하면 보통 이들 타입에 허용되는 BINARY 속성의 사용이 미리 막혀 버린다는 것에 주의하라.

CHAR [ (M) ]

의미 : 0부터 M바이트 길이의 고정 길이의 문자를 가진 문자열. M은 0부터 255이하의 정수 값 이어야 한다. M을 생략하면 1이 기본값으로 주어진다. M문자보다 큰 문자열은 저장할 때 M길이로 잘린다. M보다 짧은 문자열은 저장될 때 오른쪽이  공백문자로 채워진다. 채워진 공백은 값을 가져올 때 제거된다.
가능한 속성 : BINARY, CHARACTER SET
허용되는 길이 : 0부터 M바이트
기본 값 : 칼럼이 NULL이 가능하면 NULL, 그렇지 않으면 ''(빈 문자열)
필요한 저장공간 : M바이트
비교 : BINARY속성이 지정되지 않으면, 대소문자를 비교하지 않음
동의어 : 인자 없는 CHAR는 CHAR(1)에 대한 동의어이다.


VARCHAR [ (M) ]


의미 
: 0부터 M바이트 길이의 가변 길이 문자열. M은 0부터 255미만까지의 정수라야 한다. M문자보다 긴 문자열은 저장될 때 길이 M까지로 잘려나간다. 뒤쪽의 공백문자들은 저장될 때 제거된다.
허용되는 속성들 : BINARY, CHARACTER SET
허용되는 길이 : 0부터 M바이트
디폴트 값 : 칼럼에 NULL이 가능하면 NULL, 그렇지 않으면 ''(빈 문자열)
필요한 저장공간 : 값의 길이에 그 길이를 기록하기위한 1바이트를 더함
비교 : BINARY 속성이 지정되지 않으면 대소문자 구별하지 않음
동의어 : CHAR VARYING(M). MySQL 3.23.5부터 NCHAR VARYING(M)와 NATIONAL CHAR VARYING(M)는 VACHAR(M)에 대한 동의어이다.


TINYBLOB


의미 
: 작은 BLOB값
허용되는 속성들 : 전역 속성 외에는 없음
허용되는 길이 : 0부터 255바이트
디폴트 값 : 칼럼에 NULL이 가능하면 NULL, 그렇지 않으면 ''(빈 문자열)
필요한 저장공간 : 값의 길이에 그 길이를 기록하기 위한 1바이트를 더함
비교 : 대소문자 구별함


BLOB


의미 
: 보통 크기의 BLOB값
허용되는 속성들 : 전역 속성 외에는 없음
허용되는 길이 : 0부터 65535바이트
디폴트 값 : 칼럼에 NULL이 가능하면 NULL, 그렇지 않으면 ''(빈 문자열)
필요한 저장공간 : 값의 길이에 그 길이를 기록하기 위한 2바이트를 더함
비교 : 대소문자 구별함


MEDIUMBLOB


의미 
: 중간 크기의 BLOB값
허용되는 속성들 : 전역 속성 외에는 없음
허용되는 길이 : 0부터 16777215바이트
디폴트 값 : 칼럼에 NULL이 가능하면 NULL, 그렇지 않으면 ''(빈 문자열)
필요한 저장공간 : 값의 길이에 그 길이를 기록하기 위한 3바이트를 더함
비교 : 대소문자 구별함
동의어 : LONG VARBINARY


LONGBLOB


의미 
: 큰 BLOB값
허용되는 속성들 : 전역 속성 외에는 없음
허용되는 길이 : 0부터 4294967295바이트
디폴트 값 : 칼럼에 NULL이 가능하면 NULL, 그렇지 않으면 ''(빈 문자열)
필요한 저장공간 : 값의 길이에 그 길이를 기록하기 위한 4바이트를 더함
비교 : 대소문자 구별함


TINYTEXT


의미 
: 작은 크기의 TEXT값
허용되는 속성 : CHARACTER SET
허용되는 길이 : 0부터 255바이트
디폴트 값 : 칼럼에 NULL이 가능하면 NULL, 그렇지 않으면 ''(빈 문자열)
필요한 저장공간 : 값의 길이에 그 길이를 기록하기 위한 1바이트를 더함
비교 : 대소문자를 구별하지 않음


TEXT


의미 
: 보통 크기의 TEXT값
허용되는 속성들 : CHARACTER SET
허용되는 길이 : 0부터 65535바이트
디폴트 값 : 칼럼에 NULL이 가능하면 NULL, 그렇지 않으면 ''(빈 문자열)
필요한 저장공간 : 값의 길이에 그 길이를 기록하기 위한 2바이트를 더함
비교 : 대소문자를 구별하지 않음


MEDIUMTEXT


의미 
: 중간 크기의 TEXT값
허용되는 속성 : CHARACTER SET
허용되는 길이 : 0부터 16777215바이트
디폴트 값 : 칼럼에 NULL이 가능하면 NULL, 그렇지 않으면 ''(빈 문자열)
필요한 저장공간 : 값의 길이에 그 길이를 기록하기 위한 3바이트를 더한다.
비교 : 대소문자를 구별하지 않음


LONGTEXT


의미 
: 큰 TEXT값
허용되는 속성들 : CHARACTER SET
허용되는 길이 : 0부터 4294967295바이트
디폴트 값 : 칼럼에 NULL이 가능하면 NULL, 그렇지 않으면 ''(빈 문자열)
필요한 저장공간 : 값의 길이에 그 길이를 저장하기 위한 4바이트를 더함
비교 : 대소문자를 구별하지 않음


ENUM ('value1', 'value2', ···)


의미 
: 열거값. 값의 목록 중 정확학 하나의 수에 할당되는 칼럼값
허용되는 속성들 : 전역 속성
디폴트 값 : 칼럼에 NULL이 가능하면 NULL, 그렇지 않으면 첫 번째의 열거 값
필요한 저장공간 : 1부터 255 개의 멤버까지의 열거형에 대해서는 1바이트, 255부터 65536멤버까지의 열거형에 대해서는 2바이트
비교 : 대소문자를 구별하지 않음


SET ('value1', 'value2', ···)


의미 
: 집합. 값 목록 중 영 또는 그 이상의 멤버를 할당할 수 있는 칼럼값
허용되는 속성들 : 전역 속성
디폴트 값 : 칼럼이 NULL이 가능하면 NULL, 그렇지 않으면 ''(빈 집합)
필요한 저장공간 : 1부터 8까지의 멤버가 있는 집합에 대해서는 1바이트, 9부터 16까지의 멤버가 있는 집합에 대해서는 2바이트, 17부터 24까지의 멤버가 있는 집합에 대해서는 3바이트, 25에서 32까지의 멤버가 있는 집합에 대해서는 4바이트, 그리고 33부터 64까지의 멤버가 있는 집합에 대해서는 8바이트
비교 : 대소문자를 구별하지 않음



출처: https://otoong.tistory.com/entry/MYSQL-문자열-타입-1-column-type [OT연구소]

출처: https://toma0912.tistory.com/47

 

안녕하세요. 오늘은 제약사항에 대해서 포스팅 해보려고 합니다. 우선 '제약 조건'의 의미에 대해서 알아보고 간단한 예제를 통해 제약 조건에 대해서 알아보겠습니다.

 

제약조건(Constraint)?

 

제약조건(Constraint)이란, 데이터의 무결성을 지키기 위해 제한된 조건을 의미합니다. 즉, 데이터를 삽입할 때 무조건적으로 삽입되는 것이 아니라 어떠한 조건을 만족했을 경우에만 데이터가 삽입되도록 제약을 할 수 있는 것이라고 생각하시면 됩니다.

 

우선 기본적인 제약 조건들의 사용법에 대해서 알아보겠습니다.

// 제약조건 확인하기

DESC 데이터베이스 명.테이블 명;

 

// 제약조건 삭제

ALTER TABLE [테이블 명] DROP CONSTRAINT [제약조건 이름];

ALTER TABLE [테이블 명] DROP FOREIGN KEY [제약조건 이름];

 

// 제약조건 추가

외래키 : ALTER TABLE [테이블 명] ADD CONSTRAINT [제약조건 이름] FOREIGN KEY(컬럼 명)

REFERENCES [부모테이블 명](PK 컬럼 명) [ON DELETE CASCADE / ON UPDATE CASCADE];

 

기본키 : ALTER TABLE [테이블 명] ADD CONSTRAINT [제약조건 이름] PRIMARY KEY(컬럼 명);

 

// NOT NULL 제약 조건 추가

ALTER TABLE [테이블 명] MODIFY [컬럼 명] [데이터 타입] CONSTRAINT [제약조건 이름] NOT NULL;

 

우선, 기본적으로 테이블을 생성할 때 제약 조건을 아래와 같이 추가할 수 있습니다. 그리고 나서 간단한 예제를 통해 위의 제약조건에 대해서 알아보겠습니다.

 

 

제약 정의

 

 

위의 테이블 생성 코드를 살펴보면, a 열에는 NOT NULL  제약이 걸려 있습니다. b 열에는 NOT NULL 제약과 UNIQUE 제약이 걸려 있습니다.

c 열에는 아무런 제약사항이 없는 것을 확인할 수 있습니다. 이처럼 열에 정의하는 제약을 '열 제약'이라 부릅니다.

 

또다른 예제로 테이블에 제약을 정의하는 방법에 대해서 알아보겠습니다.

위 코드를 살펴 보시면, 제약에는 이름을 붙일 수 있습니다. 제약에 이름을 붙이면 나중에 관리하기 쉬워지므로 가능한 한 이름을 붙이도록 합니다. 제약 이름은 CONSTRAINT 키워드를 사용해서 지정합니다.

 

 

제약 추가

 

1) 열 제약 추가

 

ALTER TABLE 구문을 사용해서 c열에 NOT NULL 제약 조건을 추가한 뒤, 테이블을 보면 기본 생성 테이블과 다르게 NULL에 NO라고 제약이 추가된 것을 확인할 수 있습니다.

 

2) 테이블 제약 추가

 

테이블 제약은 ALTER TABLE의 ADD 하부명령으로 추가할 수 있습니다. 기본키는 테이블에 하나만 설정할 수 있으며, PRIMARY KEY 키워드를 사용해서 a를 기본키로 지정했습니다. 그리고, 이미 기본키가 설정되어 있는 테이블에 추가로 기본키를 작성할 수는 없습니다.

 

 

제약 삭제

 

1) 열 제약 삭제

 

기본적으로 열 제약 삭제의 경우에는 제약조건 수정과 마찬가지로 ALTER TABLE 구문을 사용합니다. 위의 코드를 살펴보시면, sample631 테이블의 c열의 NOT NULL 제약조건을 삭제한 것을 확인할 수 있습니다.

 

2) 테이블 제약 삭제

위의 코드를 살펴보시면, DROP 명령어를 통해 삭제할 제약 조건인 PRIMARY KEY를 삭제하는 것을 확인할 수 있습니다.  

 

이것으로 MySQL 제약조건 추가, 수정 및 삭제에 대해 간단히 알아보았고, 포스팅을 마치도록 하겠습니다. : )



출처: https://toma0912.tistory.com/47 [토마's 개발노트]

SHOW CREATE TABLE mytable;



1. Database 관련 Naming Rule

가.  Database Schema Name

1)   규칙

    Database Profile 이름을 의미함

    DB Alias 이름과 동일하게 

    영문 대문자로 작성함

    Database Short Name 길이는 최대 8자리를 넘을  없음

    Database Short Name  Site Unique Name 사용함

 

2)   표기 방식

<Database Short Name>
) TOURDB, ETKP, TKS

 

나.  Table Name

1)   규칙

    테이블임을 표시하기 위해 테이블  뒤에 _TB 라는 구분을 사용함

    테이블명은 대문자로 사용함

    시스템 구분 코드와 모듈구분코드로 업무 영역을 구분함

    의미있는 테이블명은 3단어까지 사용할  있음

    단어와 단어 사이는 _ 구성함

     단어는 최대 8자리까지 사용함

    구분명은 Table 특성을 나타냄

    예로는 Master, Detail, Control, Summary, Trigger, History 등이 있음

 

2)   표기 방식

<시스템 구분> + _ + <의미있는 테이블명> + _ + TB

사용자 테이블 : ACT_USERS_TB

 

다.  Column Name

1)   규칙

    물리명은 영문 대문자를 이용함논리명을 사용자가   있는 정도에서 명사  명사형동사를 사용함

    Column 대한 자리수는  12자리로 하며제한은 없음

사용하는 Database의 특성에 따라 제한될 수 있음

    Word Word 사이에는 _ 구분함

     Word 8자리를 넘을  없음

    모든 Column Dictionary List 등록된 약어사전  자료사전을 기초로 작성함

    Dictionary List 등록되지 않은 약어는 책임자의 동의 하에 등록함

    Column Name 약어의 조합으로 구성

    컬럼명에 컬럼을 대표하는 접미사를 사용하여 컬럼명의 성격을 나타냄.

 

2)   표기방식

<의미있는 컬럼명혹은 <의미있는 컬럼명> + _ + 접미사
종종 자주 사용하는 접미사는 다음과 같다.

접미사

내용

설명

_CD

CODE

주로 코드 테이블의 코드각종 코드에 사용된다숫자나 문자로이루어진 코드에 해당되며숫자나 문자의  부분이 의미가 있는 경우에 코드를 사용한다대부분 PK 해당한다.
대분류 코드 CTGRY_CD, 시도코드 SIDO_CD, 사용자 그룹 코드 USER_GROUP_CD 

_NM

NAME

코드에 대한 명칭에 주로 사용된다논리명이 이름명칭인 경우에 해당된다.
사용자이름 USER_NM, 자원명
 RES_NM,
중분류 코드명 DVSN_NM, 메뉴명 MENU_NM

_NO

NUMBER

숫자로만 이루어진 경우주로 논리명이 번호인 경우에 사용.
주민등록번호 JUMIN_NO, 조문번호
 JO_NO,
게시물번호 BOARD_NO

_SQ

SEQUENCE

오라클의 Sequence, MSSQL Identity 경우에 사용한다숫자 일련번호로 PK 설정할 경우 SQ 사용한다. MSSQLIdentity 경우 주로 _ID 사용하는 경우가 많은데사용자 아이디  USER_ID ID 의미가 틀려 SQ 사용한다.
작업번호 WORK_SQ, 이력번호 HISTORY_SQ

_ID

ID

주로 사용자 아이디의 경우에 사용한다.
사용자아이디 USER_ID, 등록자아이디 REG_ID

_DT

DATE

날짜의 경우 사용한다. DT 날짜 타입이 DATE형인 경우에만사용한다보통 날짜의 경우 CHAR(8)형으로 20050718식으로저장을 많이 한다이런 경우에는 _YMD 사용한다.
삭제일자 DEL_DT, 변경일자 CHG_DT

_YMD

YYYYMMDD

날짜의 경우 사용한다날짜 타입이 CHAR 인경우 사용한다년월일인 경우 _YMD 사용하고년월형식으로 CHAR(6) 저장될 경우 _YM 사용한다년도일자 인경우에는 YEAR, MONTH, DAY등의 컬럼명을 사용한다.

_GB

구분

구분값을 나타낼  사용한다. CD 주로 코드테이블을 별도로사용할  적당하고테이블 없이 코드상에서 구별할  사용한다가령 사용자구분 필드가 있을  일반사용자내부사용자가있다면 별도의 사용자 그룹테이블로 분리하여 사용할 경우GROUP_CD 필드명이 되지만코드상에서 일반(G), 내부(I)사용하기로 결정했다면 GROUP_GB 필드명을 사용하면 된다
통계구분 STAT_GB

_ST

STATE

상태값이다주로 CHAR(1) 형식을 사용한다.
사용자 상태 USER_ST

_FL

FLAG

플레그값이다종종 삭제하지 않는 테이블에 삭제플레그를 많이사용된다값은 0/1 이나 Y/N 많이 사용한다
삭제여부 DEL_FL, 요청여부 REQ_FL

_ORD

ORDER

순서를 나타낼  사용한다.
컬럼순서 COLUMN_ORD

_CNT

COUNT

조회수 VIEW_CNT

_AMT

AMOUNT

재고량 STOCK_AMT

_SUM

SUM

분기합계 QTR_SUM, 년도합계 YEAR_SUM

 

 

3)   순서규칙

    기본적으로 관계형 모델에서 (Column) 순서는 의미가 없음그러나물리적인 형태로 생성되어 관리될 때에는 보다 효율적인 저장공간의 관리를 위해 다음 순서에 따라 우선순위를 결정함

    Primary Key 우선함

    Primary Key내에서는 Index 의미에 따라 순서를 결정함

    Not Null Columns 우선함

 

    Not Null Columns 내에서는 Foreign Key, Attributes 순서로 

    Null Columns 내에서는 다음의 규칙에 따라 순서를 결정함

    Fixed Length Columns 우선함(Date,Number,Char)

    Smaller Length Column 우선

 

라.  Index Name

1)   규칙

    해당하는 테이블명 뒤에 _IX 붙여 index임을 명확히 

    대문자를 사용함

    일련번호는 01 ~ 99까지 사용할  있음

    MSSQL 경우 클러스터드 인덱스와  클러스터드 인덱스를 구분하여 작성함클러스터드 인덱스 _IXC 사용하며 클러스터드 인덱스는 일반 인덱스  룰을 따름.

    테이블에 인덱스가 하나만 존재할 경우 일련번호를 사용하지 않아도 .

 

2)   표기 방식

<시스템 구분> + _ + <의미있는 테이블명> + _ + IX{<일련번호>}

) Table I01_MASTER_TB Index : I01_MASTER_IX01

 

마.  Primary Key Name

1)   규칙

    영문 대문자로 작성함

    해당하는 테이블명의  뒤에 _PK라는 구분을 사용함

 

2)   표기방식

<시스템 구분> + _ + <의미있는 테이블명> + _ + PK

) Table  AC_USERS_TB Primary Key : AC_USERS_PK

 

바.  Foreign Key Name

1)   규칙

    영문 대문자로 작성함

    해당하는 테이블명의  뒤에 _FK라는 구분을 사용함

    일반적으로 테이블명과 컬럼명까지 사용하나, OBJECT 명칭이 길어져서 테이블명을 기준으로 작성함.

    일련번호 : 1 ~ 9

 

2)   표기방식

<시스템 구분> + _ + <의미있는 테이블명> + _ + FK{<일련번호>}

) Table  I01_MASTER_TB Foreign Key : I01_MASTER_FK1

 

사.  Stored Procedure Name

1)   규칙

    길이는  제한이 없으나 오라클의 OBJECT NAME 길이 제한은 있음.

    해당하는 테이블명의  뒤에 _SP라는 구분을 사용함

    기능명은 복수개 사용이 가능하면 3개의 단어를 넘지 않도록 

    기능을 나타내는 명칭이 하나일 경우 일련번호를 생략해도 .

    단어간에는 _ 구분함

    업무룰에 해당되지 않는혹은 특정 테이블에 해당되지 않는 DBMS 전반적인 프로시저의 경우시스템 프로시저로 작성하는 경우에는 시스템구분  테이블명을 생략하고 간단히 작성할  있다스키마 스크립트 GENERATION  GENERATE_SP

    오라클의 경우 패키지 내부의 프로시저의 경우 패키지 명칭에 시스템구분을 사용하므로프로시저나 함수명에 시스템구분 코드를 넣지 않는다또한 기능에 따른 일련번호를 사용하지 않고 OOP 기능인 Method Overloading  기능을 사용하여 작성한다또한 명칭은 Camel 표기법을 사용하여 작성한다사용자를 가져오는 경우 getUsers()

 

2)   표기방식

<시스템 구분> + _ + <의미있는 테이블명> + _ + <기능명>{<일련번호>} + _ + SP

I01_MASTER_TB 테이블에서 데이타 입력에 대한 Procedure

    : I01_MASTER_INS01_SP

기능명

명칭

설명

INS

INSERT

단일 테이블의 단순 INSERT 작업인 경우사용자 테이블에 데이터 입력 프로시저의 경우 업무룰이 복잡하여 여러 테이블에걸쳐 삽입 작업이 된다면(서버측 트랜잭션이 구현된다면) INS 사용하지 않고, REG 사용한다.

UDT

UPDATE

단일 테이블의 단순 UPDATE 작업의 경우

DEL

DELETE

단일 테이블의 단순 삭제인 경우

LST

LIST

SELECT문을 사용하여 조회하는 경우

REG

REGISTER

등록작업  트랜잭션을 사용하여 여러 테이블에 입력 작업이이루어질 

MOD

MODIFY

수정작업  트랜잭션을 사용하여 여러 테이블에 수정 작업이이루어질 

REM

REMOVE

삭제작업  트랜잭션을 사용하여 여러 테이블에 삭제 작업이이루어  

 

    

아.  Function Name

1)   규칙

    길이는 제한이 없으며 영문 대문자를 사용함

    해당하는 테이블명의  뒤에 _FC라는 구분을 사용함을 원칙으로 하나함수명이 길어서 사용상 불편할 경우특정 시스템에 국한하지 않고항상사용하는 라이브러리 같은 함수의 경우 구분가능한 Short Name 사용해도 무방하다.

    단어간에는 _ 구분함

    시스템 함수로 작성한 경우에는 접미사를 사용하지 않고간략한 함수이름을 사용한다) INSTR, LEASTR(@x bigint, @y bigint) 

    오라클의 경우 패키지 내부의 함수의 경우에는 프로시저의 해당 규칙에 따른다 시스템구분 코드와 접미사를 사용하지 않고, Camel 표기법으로 간략하게 작성한다.

 

2)   표기방식

<시스템 구분> + _ + <기능명> + _ + FC

I01_MASTER_TB 테이블에서 주소명를 가져오기 위한 Function

    : I01_GET_ADDRESSNAME_FC(p_AddressCode IN Char) 내지는

: getAddressName(p_AddressCode IN Char)

 

자.  Table Trigger Name

1)   규칙

    영문 대문자로 작성함

    일련번호는 01 ~ 99까지 사용 가능함

 

2)   표기방식

<시스템 구분> + _ + <의미있는 테이블명> + _ + <Timing><Trigger Event><일련번호> + _ + TG

® Timing : B(Before), A(After)

® Trigger Event : I(Insert), D(Delete), U(Update)

 

I01_MASTER_TB 테이블에서 데이타 입력 후에 실행되는 Trigger

: I01_MASTER_AU01_TG

 

차.  View Name

1)   규칙

    길이는 제한이 없으며영문 대문자로 작성함

    해당하는 테이블명의  뒤에 _VW라는 구분을 사용함

    일련번호는 01 ~ 99까지 사용할  있음

 

2)   표기방식

<시스템 구분> + _ + <의미있는 테이블명><일련번호> + _ + VW

) AC_ADMINL_USER_VW

 

카.  Sequence Name <오라클의 경우에만 해당>

1)   규칙

    길이는 제한이 없으며 영문 대문자를 사용함

    해당하는 테이블명의  뒤에 _SQ라는 구분을 사용함

 

2)   표기방식

<시스템 구분> + _ + <의미있는 테이블명> + _ + SQ

I01_MASTER_TB 테이블의 Sequence : I01_MASTER_SQ

 

타.  Package Name<오라클의 경우에만 해당>

1)   규칙

    길이는 제한이 없으며 영문 대문자를 사용함

    해당하는 테이블명의  뒤에 _PKG라는 구분을 사용함

 

2)   표기방식

<시스템 구분> + _ + <의미있는 패키지명> + _ + PKG

검색엔진에서 사용하는 자원에 관련된 패키지 : SCH__PKG

 

파.  Check 제약조건

1)   규칙

    길이는 제한이 없으며 영문 대문자를 사용함

    기존의 명칭룰에 해당하는 접미사를 사용하지 않고예외적으로 접두어 CK_ 사용한다일반적으로 CHECK DEFAULT 제약조건은 특정 테이블에 한정시켜서 작성하기 보다는 시스템 전반에 걸쳐서 사용이 가능하므로 예외규정을 둔다.

 

2)   표기방식

CK + _ + <의미있는 CHECK>

이메일 체크 : CK_EMAIL

성별 체크 : CK_SEX

 

하.  Default 제약조건

1)   규칙

    길이는 제한이 없으며 영문 대문자를 사용함

    기존의 명칭룰에 해당하는 접미사를 사용하지 않고예외적으로 접두어 DF_ 사용한다일반적으로 CHECK DEFAULT 제약조건은 특정 테이블에 한정시켜서 작성하기 보다는 시스템 전반에 걸쳐서 사용이 가능하므로 예외규정을 둔다

 

2)   표기방식

DF + _ + <의미있는 DEFAULT>

) Null String Default  DF_NULLSTR
) 0(Zero) Default  DF_ZERO

 



출처: https://jang8584.tistory.com/35 [개발자의 길]

JWT(JSON Web Token)을 이용한 API 인증 - #1 개념 소개

조대협 (http://bcho.tistory.com)


REST API에 대한 보안과 인증이 화두가 되면서 많이 언급되는 것이 OAuth인데, 근래에 들어서 화두가 되고 있는 것이 JWT (JSON Web Token)이라는 표준이다.


Claim기반 토큰의 개념


OAuth에 의해서 발급되는 access_token은 random string으로 토큰 자체에는 특별한 정보를 가지고 있지 않는 일반적인 스트링 형태 이다. 아래는 페이스북에서 발급된 access_token의 형태로 일반적인 문자열 형태임을 확인할 수 있다.



<그림1.  Facebook의 Oauth에서 사용하는 일반적인 스트링 기반 토큰 예제>

 

 API나 서비스를 제공하는 서버 입장에서 그 access_token을 통해서 사용자에 연관된 권한(예를 들어 scope같은 것)을 식별한 뒤 권한을 허용해주는 구조이다.

즉 서비스를 제공하는 입장에서는 토큰을 가지고 그 토큰과 연관된 정보를 서버쪽에서 찾아야 한다. (사용자 ID나 권한등).

JWT는 Claim 기반이라는 방식을 사용하는데, Claim이라는 사용자에 대한 프로퍼티나 속성을 이야기 한다. 토큰자체가 정보를 가지고 있는 방식인데, JWT는 이 Claim을 JSON을 이용해서 정의한다.

다음은 Claim을 JSON으로 서술한 예이다.이 JSON 자체를 토큰으로 사용하는 것이 Claim 기반의 토큰 방식이다.

{

  "id":"terry"

  ,"role":["admin","user"]

  ,"company":"pepsi"

}

<코드 1. JSON으로 Claim을 기술한 토큰의 형태 >

자 그렇다면, 이러한 Claim 방식의 토큰은 무엇이 좋을까? 이 토큰을 이용해서 요청을 받는 서버나 서비스 입장에서는 이 서비스를 호출한 사용자에 대한 추가 정보는 이미 토큰안에 다 들어가 있기 때문에 다른 곳에서 가져올 필요가 없다는 것이다.

“사용자 관리” 라는 API 서비스가 있다고 가정하다.

 이 API는 “관리자(admin)” 권한을 가지고 있는 사용자만이 접근이 가능하며, “관리자” 권한을 가지고 있는 사용자는 그 관리자가 속해 있는 “회사(company)”의 사용자 정보만 관리할 수 있다. 라고 정의하자

이  시나리오에 대해서 일반적인 스트링 기반의 토큰과 JWT와 같은 Claim 기반의 토큰이 어떤 차이를 가질 수 있는 지 알아보도록 하자.


OAuth 토큰의 경우



<그림 2. String 토큰에 의한 API 권한 인증 흐름>

 

1.    API 클라이언트가 Authorization Server (토큰 발급서버)로 토큰을 요청한다.

이때, 토큰 발급을 요청하는 사용자의 계정과 비밀번호를 넘기고, 이와 함께 토큰의 권한(용도)을 요청한다. 여기서는 일반 사용자 권한(enduser)과 관리자 권한(admin)을 같이 요청하였다.

2.    토큰 생성 요청을 받은 Authorization Server는 사용자 계정을 확인한 후, 이 사용자에게 요청된 권한을 부여해도 되는지 계정 시스템등에 물어본 후, 사용자에게 해당 토큰을 발급이 가능하면 토큰을 발급하고, 토큰에 대한 정보를 내부(토큰 저장소)에 저장해놓는다.

3.    이렇게 생성된 토큰은 API 클라이언트로 저장된다.

4.    API 클라이언트는 API를 호출할때 이 토큰을 이용해서 Resource Server(API 서버)에 있는 API를 호출한다.

5.    이때 호출되는 API는 관리자 권한을 가지고 있어야 사용할 수 있기 때문에, Resource Server가 토큰 저장소에서 토큰에 관련된 사용자 계정, 권한 등의 정보를 가지고 온다. 이 토큰에 (관리자)admin 권한이 부여되어 있기 때문에, API 호출을 허용한다. 위에 정의한 시나리오에서는 그 사용자가 속한 “회사”의 사용자 정보만 조회할 수 있다. 라는 전제 조건을 가지고 있기 때문에, API 서버는 추가로 사용자 데이타 베이스에서 이 사용자가 속한 “회사” 정보를 찾아와야한다.

6.    API서버는 응답을 보낸다.


JWT와 같은 Claim 기반의 토큰 흐름을 보자

 



<그림 3. Claim 기반의 토큰을 이용한 API 권한 인증 흐름 >

 

1.    토큰을 생성 요청하는 방식은 동일하다.  마찬가지로 사용자를 인증한다음에, 토큰을 생성한다.

2.    다른 점은 생성된 토큰에 관련된 정보를 별도로 저장하지 않는다는 것이다. 토큰에 연관되는 사용자 정보나 권한등을 토큰 자체에 넣어서 저장한다.

3.    API를 호출하는 방식도 동일하다.

4.    Resource Server (API 서버)는 토큰 내에 들어 있는 사용자 정보를 가지고 권한 인가 처리를 하고 결과를 리턴한다.

결과적으로 차이점은 토큰을 생성하는 단계에서는 생성된 토큰을 별도로 서버에서 유지할 필요가 없으며

토큰을 사용하는 API 서버 입장에서는 API 요청을 검증하기 위해서 토큰을 가지고 사용자 정보를 별도로 계정 시스템 등에서 조회할 필요가 없다는 것이다.


참고 : 다른 Claim 기반 토큰은?


그러면 이러한 Claim 기반의 토큰이 JSON이 처음일까? 이미 이전에, XML기반의 SAML 2.0이 이와 비슷한 개념을 가지고 있다. Assertion이라는 개념으로 XML안에 이러한 Claim 정보를 넣어서 넘길 수 있었으나, 문제점은 전체적인 사이즈가 너무 크고, 구조가 복잡하여 쉽게 접근이 어려웠다. 더군다가 크기가 크기 때문에 API와 같이 자주 호출해야 하는 경우에는 HTTP 헤더등에 실어서 보내기가 어렵고, 파싱에 대한 오버해드가 크기 때문에 적절하지 않았다. (주로 다른 사이트나 시스템간의 SSO에서 상호 사용자 인증등을 위해서 사용된다. 무겁기는 하지만 표준화가 잘되어 있기 때문에 사용자 인증 시나리오에서는 현재에도 많이 사용된다.)

JWT는 이JSON Claim을 BASE64로 인코딩하여HTTP Header에 쉽게 넣을 수 있으며, JSON 기반이기 때문에 파싱과 사용이 쉽다.

결과적으로 Claim 기반의 토큰은 토큰 자체가 정보를 담음으로써, 토큰을 가지고 서비스나 API 접근을 제어할 때 별도의 작업이 서버에서 필요하지 않으며, 토큰 자체를 서버에서 관리할 필요가 없기 때문에 구현이 상대적으로 단순해진다.


JWT에 대한 소개


Claim 기반의 토큰에 대한 개념을 대략적으로 이해했다면, 그러면 실제로 JWT가 어떻게 구성되는지에 대해서 살펴보도록 하자.


Claim (메세지) 정의

JWT는 Claim을 JSON형태로 표현하는 것인데, JSON은 “\n”등 개행문자가 있기 때문에, REST API 호출시 HTTP Header등에 넣기가 매우 불편하다. 그래서, JWT에서는 이 Claim JSON 문자열을 BASE64 인코딩을 통해서 하나의 문자열로 변환한다.

{

  "id":"terry"

  ,"role":["admin","user"]

  ,"company":"pepsi"

}

<코드 2. JSON 기반의Claim 예제>

문자열을 BASE64 인코딩 한 결과

ew0KICAiaWQiOiJ0ZXJyeSINCiAgLCJyb2xlIjpbImFkbWluIiwidXNlciJdDQogICwiY29tcGFueSI6InBlcHNpIg0KfQ0K

<코드 3. JSON 기반의 Claim 코드 2를 BASE64 인코딩 한 결과>


변조 방지

위의 Claim 기반의 토큰을 봤으면, 첫번째 들 수 있는 의문이 토큰을 받은 다음에 누군가 토큰을 변조해서 사용한다면 어떻게 막느냐? 이다. 이렇게 메세지가 변조 되지 않았음을 증명하는 것을 무결성(Integrity)라고 하는데, 무결성을 보장하는 방법중 많이 사용되는 방법이 서명(Signature)이나 HMAC 사용하는 방식이다. 즉 원본 메세지에서 해쉬값을 추출한 후, 이를 비밀 키를 이용해서 복호화 시켜서 토큰의 뒤에 붙인다. 이게 HMAC방식인데,  누군가 이 메세지를 변조를 했다면,변조된 메세지에서 생성한 해쉬값과 토큰뒤에 붙어 있는 HMAC값이 다르기 때문에 메세지가 변조되었음을 알 수 있다. 다른 누군가가 메세지를 변조한후에, 새롭게 HMAC값을 만들어내려고 하더라도, HAMC은 앞의 비밀키를 이용해서 복호화 되었기 때문에, 이 비밀키를 알 수 없는 이상 HMAC을 만들어 낼 수 없다.


※ HMAC에 대한 자세한 설명은http://bcho.tistory.com/807 를 참고하기 바란다.

그래서 앞의 JSON 메세지에 대해서 SHA-256이라는 알고리즘을 이용해서 비밀키를 “secret” 이라고 하고, HMAC을 생성하면 결과는 다음과 같다.

i22mRxfSB5gt0rLbtrogxbKj5aZmpYh7lA82HO1Di0E

<코드 4. 코드 2의 JSON기반 Claim에 대해서, SHA1-256으로 생성한 HMAC>

서명 생성 방식

그러면 무결성 보장을 위해서 사용할 수 있는 알고리즘이 SHA1-256 HMAC 뿐일까? 보안요건에 따라서 SHA1-256,384,512. 그리고 공인 인증서 (Ceritification)을 이용한 RS256 등등 다양한 서명 방식을 지원한다. 그렇다면 JWT 토큰이 어떤 방식으로 서명이 되어 있는지는 어떻게 알 수 있을까?

그래서 JWT 토큰의 맨 앞부분에는 서명에 어떤 알고리즘을 사용했는지를 JSON형태로 정의한후, 이 JSON을 다시 BASE64 방식으로 인코딩한 문자열을 붙인다

{"alg":"HS256","typ":"JWT"}

<코드 5. JSON으로 서명 생성 방식은 SHA1-256으로 정의한 예>

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

<코드 6. 위의 코드 5 JSON 문자열을 BASE64 인코딩한 결과>

 

전체 메세지 포맷


위에서 설명한, 서명 방식, JSON 기반의 Claim,그리고 서명(Signature)까지 포함된 전체적인 JWT 토큰의 구조를 보면 다음과 같다.

{서명 방식을 정의한 JSON을 BASE64 인코딩}.{JSON Claim을 BASE64 인코딩}.{JSON Claim에 대한 서명}

이를 정리해서 그림으로 서술해 보면 다음과 같다.


<그림. JWT 토큰 구조>

그리고 결과로 나온, JWT 토큰은

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.ew0KICAiaWQiOiJ0ZXJyeSINCiAgLCJyb2xlIjpbImFkbWluIiwidXNlciJdDQogICwiY29tcGFueSI6InBlcHNpIg0KfQ0K.i22mRxfSB5gt0rLbtrogxbKj5aZmpYh7lA82HO1Di0E

가 된다.


2편에서 다룰 내용

  • 유출 방지(암호화)

  • 상세 스펙

  • 구현예제



출처: http://bcho.tistory.com/999 [조대협의 블로그]

출처: http://bcho.tistory.com/999 [조대협의 블로그]

출처: http://ohgyun.com/470


키워드: OAuth

문제:
보안은 늘 어려운 것 같다.

잘 정리된 문서를 찾기도 어렵고, 있다 하더라도 난 좀 이해하기 어렵더라. @_@


이번에 OAuth 인증 처리가 필요하던 차에, 한빛 소프트에서 나온 EBook을 보게 됐다.

오잉~~ 쉽게 설명되어 있어서 참 좋더라. :D


http://www.hanb.co.kr/ebook/look.html?isbn=9788979149944



책 읽으면서 정리해둔 게 있어 옮겨둔다.



해결책:


서버사이드 웹 애플리케이션


1. 권한 서버로 권한 코드 요청하기


요청 URL 예: https://accounts.google.com/o/oauth2/auth


client_id: 등록한 애플리케이션의 아이디

redirect_uri: 권한 코드 획득 후 리다이렉트할 URI

scope: 요청 데이터의 접근 범위 (API 서버에 따라 컴마나 공백으로 구분)

response_type=code

state: CSRF를 막기위한 1회성 랜덤값

approval_prompt:

          사용자가 방문할 때마다 승인받을 것인가? 매번 받으려면 force, 처음만 받으려면 auto

access_type:

          사용자가 컴퓨터를 사용하지 않는 동안에도 접근하도록 할 것인가?

          그렇다면 offline이고, 이 땐 애플리케이션에서 재발급 토큰을 가져올 수 있다.

          online을 사용하면 재발급 토큰은 발급되지 않는다.



---> 이 요청을 보내면 API 서비스의 권한 허용 페이지로 이동한다.

     "어떤 앱이 이런이런 권한을 사용하려 합니다. 허용하겠습니까?"의 메시지다.

     허용하면, 위에 정의했던 redirect_uri 의 경로로 리다이렉트되며,

     이 때 접근 요청을 승인했을 때를 나타내는 권한 코드(code)와 요청에 포함했던 (state)가 함께 전달된다.



2. 권한 코드로 액세스 토큰 발급받기


이제, 전달받은 code와 state로 API 요청을 만들기 위해 권한 코드를 OAuth 액세스 토큰으로 교환해야 한다.

액세스 토큰의 엔드포인트로 HTTP POST 요청을 보내면 된다.


요청에는 아래 파라미터가 필요하다.


code: 애플리케이션에 전달되는 권한 코드

redirect_uri: 권한 엔드포인트에 첫 요청을 보낼 때의 등록된 위치

grant_type=authorization_code: 권한 코드의 액세스 토큰으로의 교환을 의미



헤더에는 client_id와 client_secret을 포함해 보낸다.

- HTTP Basic Authorization 헤더로 (client_id 와 client_secret을 포함하는 방식)

- POST의 파라미터로 client_id와 client_secret을 포함하는 방식



--> 이 요청이 인증되고 다른 파라미터가 유효하면, 권한 서버는 JSON 인코딩 응답에 OAuth 액세스 토큰을 리턴한다.

    access_token: API 요청을 허가하는데 사용하는 토큰

    token_type: 발급된 액세스 토큰의 타입. 주로 'bearer'가 사용되지만, 확장 가능하다.

    expires_in: 토큰은 시간 제약이 있을 수 있다. 이 값은 추가 정보이고 만료되기까지 남은 시간(초)를 의미한다.

    refresh_token: 액세스 토큰이 만료된 후 새로운 액세스 토큰을 얻기 위해 사용하는 토큰이다.

                         재발급 토큰이 있으면 offline 모드에서도 계속 API에 접근할 수 있다.

                         액세스 토큰과 재발급 토큰은 항상 기밀이 유지되어야 하고,

                         자원 소유자를 포함한 임의의 사용자에게 노출되지 말아야 한다.

                         재발급 토큰은 사용자 계정과 연관된 서버사이드 데이터베이스에 저장되어야 한다.

                         액세스 토큰도 데이터베이스에 저장할 수 있지만, 주로 성능 때문에 세션에 캐시한다.



3. API 호출하기


발급받은 액세스 토큰으로 API에 요청할 수 있다.

이를 전달 토큰(bearer token)이라 하고, 주로 헤더에 넣어 보낸다.


"Authorization: Bearer 액세스 토큰"




4. 액세스 토큰 재발급 받기


액세스 토큰을 발급받을 때 토큰의 만료시간을 계산해 함께 저장해둔다.

다음 요청 시 토큰이 만료되었다면, 재발급 토큰으로 다시 액세스 토큰을 발급받아온다.



* 액세스 토큰과 재발급 토큰

- 액세스 토큰의 유효함을 확인할 때 매번 권한 서버나 데이터베이스에 요청하면 API 응답이 늦어질 수 있다.

  이 때문에 주로 서명이나 암호화한 토큰을 사용해 검증 범위를 줄인다.

  사용자가 이전에 허가했던 애플리케이션의 접근을 취소할 수 있기 때문에,

  API 서비스가 암호화를 사용해 검증하더라도 안전할 수 있게 토큰의 유효 범위를 짧게하는 것이 필요하다.


     client_id

     client_secret

     grant_type=refresh_token

     refresh_token: 재발급 토큰

  --> 이 응답으로는 access_token, refresh_token, expires_in 을 받음 






클라이언트 사이드 웹 애플리케이션



암묵적 허가 플로우를 사용하며 아래 경우에 사용한다.

- 데이터에 접근이 일시적으로 필요할 때

- 사용자가 규칙적으로 API 제공 업체에 로긍니할 때

- OAuth 클라이언트가 자바스크립트, 플래시 등을 사용해 웹 브라우저에서 실행될 때

- 웹 브라우저의 신뢰도가 높고, 신뢰할 수 없는 사용자나 애프리케이션에 노출될 염려가 적을 때



1. 권한 서버로의 요청 파라미터


client_id

redirect_uri

scope

response_type=token (액세스토큰)


--> 권한을 얻으면 redirect_uri 에 정의한 페이지로 이동하면서,

     URL에 해시(#) 형태로 access_token과 관련 정보가 추가된다.


     http://example.com/callback#access_token=xxx&token_type=Bearer&expires_in=3600



2. API 요청하기


전달받은 access_token 으로 요청을 보내면 된다.

도메인이 다른 경우엔 jsonp로 보낸다.



3. 액세스 토큰 재발급 받기


암묵적 허가 플로우에서는 권한 코드 플로우와 달리 토큰을 재발급하기 위한 특정 프로토콜을 사용하지 않는다.

처음 토큰을 가져올 때와 동일한 방식으로 가져와야 한다.


아직 표준화되지 않았지만, 일부 OAuth 2.0 제공자들은 즉시 모드(immediate mode)를 지원한다.

즉시 모드는 사용자에게 알리지 않고 새로운 액세스 토큰을 투명하게 애플리케이션으로 보낼 수 있도록,

숨겨진 iframe 내에서 토큰 재발급 과정을 허용한다.

주로 `immediate=true`라는 파라미터를 추가로 제공해 해결한다.





자원 소유자 비밀번호 플로우


사용자 이름과 비밀번호를 액세스 토큰으로 교환하고, 재발급 토큰은 선택적으로 사용한다.

다른 OAuth 플로우에 비해 의미있는 보안성을 가지며,

주로 사용자의 강한 신뢰가 바탕이 되어야 한다.

자원 소유자의 비밀번호가 애플리케이션에 노출되기 때문에, 보통 API 제공 업체가 배포한 공식 애플리케이션에만 추천한다.



1. 사용자에게 인증 요청


사용자에게 아이디와 비밀번호를 받아 권한 서버로 요청을 보낸다.

아래 파라미터가 필요하다.


grant_type=password: 이 플로우에서는 'password'라고 기술한다.

scope: 접근 요청할 수 있는 데이터

client_id: (선택) 애플리케이션의 등록 값

client_secret: (선택) 파라미터 이름만 보면 비밀성을 내포하는 듯 하지만, 네이티브 모바일 애플리케이션 같은

               공개 클라이언트를 위해서도 API 제공 업체에서 가끔 사용한다.

               이런 경우, 파라미터 값은 비밀이 아니어서 애플리케이션 사용자가 발견할 수도 있다.

username: 자원 소유자가 제공하는 사용자 이름(utf-8)

password: 자원 소유자가 제공하는 비밀번호(utf-8)



--> 요청에 성공하면 아래 값을 application/json 형태로 응답한다.

     access_token: API 접근에 사용하는 액세스 토큰

     id: 사용자의 유일한 식별값.

               (예제에서는 URL 형태인데, 사용자에 대한 더 많은 정보를 얻기 위해 OAuth에서 보호되는 자원처럼 접근될 수 있다고 한다. 잘은 모르겠다)

     signature: (선택) 서버에 식별 URL을 보낸 후, 이 URL이 변경되지 않았음을 검증하기 위해 사용하는 서명이다.



2. API 호출


마찬가지로 헤더에 "Authorization: Bearer 액세스토큰" 값을 넣어 API를 요청하면 된다.

https://xploit.ninty.ninja/Tools

Tools


Tutorials






// 스위치 관련 exploits 정리

https://gbatemp.net/threads/switch-hacking-homebrew-discussion.464282/


Useful Links


Tools By The Community


Proof of Concept Exploits

These exploits are of no use for non-developer people and only show what will be possible soon!



// CVE-2016--4657 - LiveOverflow

https://gbatemp.net/threads/cve-2016-4657-walk-through-and-intro-to-browser-exploitation.464327/


https://reswitched.tech/



// 스위치 관련 software 및  OS 등 관련 정보 기술

http://switchbrew.org/index.php?title=Main_Page

+ Recent posts