AdminID.kr (어드민아이디) - 기타 데이터베이스

MySQL Dump / Import (덤프 / 임포트)

2016-10-10T09:32:41+00:00

MySQL 덤프 / 임포트

1. dump

1.1 전체 dump

$>mysqldump -u [사용자아이디] -p 데이타베이스명 > 저장될 파일명.sql

예) mysqldump -uroot -p data > data.sql

1.2 테이블만 dump

$>mysqldump -u [사용자아이디] -p 데이타베이스명 테이블명 > 저장될 파일명.sql

예) mysqldump -u root -p data member > data_User.sql

2. 복구하기 (Import)

$> mysql -u[사용자아이디] -p 데이타베이스명 < 덤프파일명.sql

예) mysql -u root -p data < data.sql

예) mysql -u root -p data User_info < data_User.sql

3. 특정db의 특정 table에서 원하는 값만 덤프 받기

User라는 DB에 a,b,c라는 테이블이 있다. 여기서 b라는 테이블에서 no가 4번이상이고 7번 이하인 값만 덤프 받기

사용되는 옵션 -w

예) mysqldump -u root -p User b-w'no =>4 and no=< 7' > edu_a_cond.sql

4. Database 스키마만 백업 받기

data라는 DB의 모든 테이블 스키마를 백업 받기

예) mysqldump -u root -p -d data > data_db.sql

data라는 DB의 a라는 테이블 스키마를 백업 받기

예) mysqldump -u root -p data a > data_a_table.sql

출처 : http://kssong.tistory.com/2

빅데이터 시대, DB·데이터 암호화 솔루션 길라잡이

2015-04-28T15:16:59+00:00

입력날짜 : 2015-04-26 23:55

의료·금융·제조 분야에 암호화 필요한 데이터 많아...시장 확대 기대_
2014년 640억원 규모...관련 업체, 새로운 분야 적극 개척 나서

[보안뉴스 김태형] 지난해 카드사 정보유출 사고 이후 개정된 개인정보보호법에 따라 인터넷 구간 외에 내부 인사 시스템 등에서도 개인정보를 암호화하도록 규제가 강화됐다. 이에 따라 개인정보보호법상의 고유식별번호, 즉 주민등록번호에 대한 암호화뿐만 아니라 정부의 행정 시스템에도 개인정보보호를 위한 암호화가 의무화된 상태다.

이와 같이 개인정보 유출방지와 보안 강화를 위한 데이터 암호화는 기존의 DB 외에도 CCTV 영상정보나 금융분야의 로그데이터, 병원의 의료영상 및 이미지 등과 같은 비정형 데이터 암호화에 대한 관심도 높아지고 있어 빅데이터 시대의 가장 큰 보안이슈는 ‘데이터 암호화’라고 할 수 있다.

이에 따라 국내 DB·데이터 암호화 시장도 지난 몇 년간 급성장을 거듭해 왔다. 최근에는 기존 DB암호화에서 보안이 필요한 다양한 데이터의 증가로 인해 암호화 시장은 서서히 빅데이터로 이동하고 있다. KISA가 발표한 ‘2014 국내 정보보호산업 실태조사’에 따르면, 국내 DB암호화 시장의 2013년 매출은 607억 9백만원으로 집계됐으며, 2014년 매출은 약 640억 9300만원으로 5.6% 증가했다고 밝혔다.

또한 DB암호화는 종사자가 50인 이상 100인 미만인 기업의 매출이 172억 1600만원, 100인 이상인 기업의 매출이 248억 9800만원으로 나타났으며 일반기업의 매출액이 벤처기업의 매출액보다 높은 것으로 나타났다. 특히, DB보안은 공공부문 매출이 42.1%, 서비스부문이 25.1%로 주로 공공부문의 수요가 높은 제품으로 나타났다.

이와 관련 보메트릭코리아 이문형 지사장은 “빅데이터 및 IoT 시대를 맞아 각종 디바이스로 모아지는 다양한 데이터에 대한 보안을 강구하지 않으면 유출 시에는 큰 피해로 이어질 수 있다. 이로 인해 기존 법·규제 준수를 위한 DB보안뿐만 아니라 모든 중요 데이터의 암호화를 통한 고도화가 필요하다”고 강조했다.

보메트릭의 암호화 솔루션 보메트릭 인크립션(Vormetric Encryption)은 컬럼 단위가 아닌 파일 단위의 커널방식으로 암호화를 진행한다. 일반적인 암호화 솔루션은 컬럼 단위로 암호화를 지원하는 경우가 많지만 기존 컬럼 기반의 암호화로는 빅데이터의 대부분을 차지하고 있는 로그파일이나 SNS·이미지 파일과 같은 비정형 데이터 보호에는 한계가 있어 커널 방식이 유리하다는 게 보메트릭 코리아 측의 설명이다.

또한, 케이사인 구자동 부사장은 “지난해 카드사 고객정보 유출사고 이후 개정된 개인정보보호법은 인터넷 구간 외에 내부 인사시스템 등에서도 개인정보 암호화를 하도록 강화됐다. 하지만 아직까지 개인정보 암호화를 하지 않은 곳도 많기 때문에 올해에는 공공·금융 분야의 DB암호화에 집중해 나갈 계획”이라고 말했다.

케이사인의 통합 데이터베이스 보안 솔루션 ‘KSignSecureDB’는 데이터 암호화, 접근제어 및 로그감사를 통해 기업내 중요 데이터를 보호한다. 특히, 컬럼 단위로 암호화해 DB유출을 방지하고 세분화된 접근제어 기능을 제공하는 것이 특징이다.

이와 함께 펜타시큐리티 디아모(D’Amo)는 지난 2013년부터 의료영상에 대한 보안 솔루션을 제공하고 있다. 최근 들어서는 의료영상 데이터 보안에 대해서도 관심이 높아짐에 따라 이미지 전용 암호화 기능이 포함된 디아모(D’Amo) 솔루션으로 암호화 시장 확대를 이끌면서 적극적인 영업전략을 펼치고 있다.

펜타시큐리티 기획실장 김덕수 상무는 “DB암호화 시장은 2012년 이후부터 꾸준히 두 자리수 이상 성장하고 있으며 개인정보보호법으로 인한 컴플라이언스 이슈가 시장 확대를 주도하고 있다”면서 “DB를 포함해 기업에서 사용하는 각종 중요 데이터를 암호화하기 위해서는 각 기업이 사용하고 있는 IT 시스템을 충분히 검토하고 해당 환경에 적합한 암호화 솔루션을 설치해야만 보안은 물론 서비스의 안정성과 성능까지 보장받을 수 있다”고 말했다.

이어서 그는 “고객 입장에서는 암호화를 고려하는 데이터의 종류와 데이터를 담고 있는 시스템 환경 등 총체적인 IT 시스템 구조를 파악하고 해당 시스템에 가장 적절한 방식의 암호화 솔루션을 도입해야만 한다”면서 “펜타시큐리티의 통합 데이터 암호화 솔루션 D’Amo는 2004년에 국내 처음 출시한 암호화 솔루션으로서 2,900여건의 데이터 암호화 구축 레퍼런스를 보유하고 있다”고 덧붙였다.

▲ 국내외 주요 DB암호화 제품과 기능(업체명 가나다순)

또한, 소프트포럼의 암호화 솔루션 제큐어웹(XecureDB)은 정보유출 시에도 데이터 기밀성을 보장하는 DB암호화 솔루션으로, 국정원에서 안전성을 검증한 알고리즘을 사용해 인덱스를 암호화하기 때문에 고성능·안전성을 보장하는 것이 특징이다.

이글로벌 큐브원(CubeOne)의 경우 API, Plug-In 방식을 모두 지원하는 대표적인 암호화 솔루션이다. 이 외에도 DB 암호화 솔루션에는 신시웨이의 ‘페트라 사이퍼(Petra Cipher)’, 이니텍의 ‘세이프DB(SafeDB)’, 세이프넷 데이터시큐어(Data Secure) 등이 있다.

앞으로 빅데이터와 사물인터넷의 확산 등으로 데이터는 더욱 증가하고, 다양화될 것으로 보인다. 이로 인해 이제는 기본 DB 암호화 뿐만 아니라, 로그 정보, 금융거래 정보, CCTV 영상정보, 의료정보, 이미지 등 다양한 데이터에 대한 암호화가 요구되면서 DB암호화 솔루션 시장은 계속 확대될 것으로 전망된다.

한편, 오는 6월 30일 행정자치부 주최로 서울 삼성동 코엑스 그랜드볼룸에서 개최되는 ‘2015 개인정보보호 페어 & CPO워크숍’(http://www.pisfair.org/)에서는 공공기관을 비롯해 의료, 교육, 금융 분야에서 활용되는 각종 DB 및 데이터의 효율적인 암호화 방안 등은 물론 개인정보보호를 위한 각종 체크리스트와 보안대책들이 구체적으로 논의될 예정이다.

[김태형 기자(boan@boannews.com)]

출처 : http://www.boannews.com/media/view.asp?idx=46033

mariadb 원격 접속 허용

2014-04-29T08:43:49+00:00

mariadb는 기본적으로 내부(localhost)에서만 접속이 되고, 외부에서는 접속이 불가능하다.

외부에서 접속하게 되면 아래와 같은 메시지가 에러 메시지를 만나게 된다.
두둥~

Host 'xxx.xxx.xxx.xxx' is not allowed to connect to this MariaDB server

1	Host 'xxx.xxx.xxx.xxx' is not allowed to connect to this MariaDB server

차근 차근 알아보자.

# 데이터베이스 생성 MariaDB [(none)]> create database {데이터베이스명}; Query OK, 1 row affected (0.00 sec) # 사용자 등록 MariaDB [(none)]> insert into user (host, user, password) values('%', '{아이디}', password('{패스워드}')); Query OK, 0 rows affected (0.00 sec) MariaDB [(none)]> flush privileges; Query OK, 0 rows affected (0.00 sec) # 외부 접속 허용 (모든 아이피에 대해서) MariaDB [(none)]> grant all privileges on {데이터베이스명}.* to {아이디}@'%' identified by '{패스워드}' with grant option; Query OK, 0 rows affected (0.00 sec) MariaDB [(none)]> flush privileges; Query OK, 0 rows affected (0.00 sec)

# 데이터베이스 생성

MariaDB [(none)]> create database {데이터베이스명};

Query OK, 1 row affected (0.00 sec)

# 사용자 등록

MariaDB [(none)]> insert into user (host, user, password) values('%', '{아이디}', password('{패스워드}'));

Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> flush privileges;

Query OK, 0 rows affected (0.00 sec)

# 외부 접속 허용 (모든 아이피에 대해서)

MariaDB [(none)]> grant all privileges on {데이터베이스명}.* to {아이디}@'%' identified by '{패스워드}' with grant option;

Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> flush privileges;

Query OK, 0 rows affected (0.00 sec)

위와 같이 하면 외부에서도 접속이 가능하다.
iptable에서 mariadb 포트 3306 접속 허용하는 것도 깜박하지 말자!! ㅋㅋ

출처 : http://www.talkdev.net/mariadb-%EC%9B%90%EA%B2%A9-%EC%A0%91%EC%86%8D-%ED%97%88%EC%9A%A9/

Database(데이터베이스) 관련 Naming Rule(이름설정 규칙) [SQL]

2013-12-03T10:50:42+00:00

Database 관련 Naming Rule

1. Database Schema Name
1.1. 규칙
    - Database Profile 이름을 의미함
    - DB Alias 이름과 동일하게 함
    - 영문 대문자로 작성함
    - Database Short Name의 길이는 최대 8자리를 넘을 수 없음
    - Database Short Name은 각 Site의 Unique한 Name을 사용함
1.2. 표기 방식
      예) TOURDB, ETKP, TKS…

2. Table Name
2.1. 규칙
    - 테이블임을 표시하기 위해 테이블 명 뒤에 ‘_TB’ 라는 구분을 사용함
    - 테이블명은 대문자로 사용함
    - 시스템 구분 코드와 모듈구분코드로 업무 영역을 구분함
    - 의미있는 테이블명은 3단어까지 사용할 수 있음
    - 단어와 단어 사이는 ‘_’로 구성함
    - 각 단어는 최대 8자리까지 사용함
    - 구분명은 Table의 특성을 나타냄
    - 예로는 Master, Detail, Control, Summary, Trigger, History 등이 있음
2.2. 표기 방식
    <시스템 구분> + ‘_’ + <의미있는 테이블명> + ‘_’ + TB
    예) 사용자 테이블 : ACT_USERS_TB

3. Column Name
3.1. 규칙
    - 물리명은 영문 대문자를 이용함. 논리명을 사용자가 알 수 있는 정도에서 명사 및 명사형동사를 사용함
    - Column에 대한 자리수는 총 12자리로 하며, 제한은 없음
      단, 사용하는 Database의 특성에 따라 제한될 수 있음
    - Word와 Word 사이에는 ‘_’로 구분함
    - 한 Word는 8자리를 넘을 수 없음
    - 모든 Column은 Dictionary List에 등록된 약어사전 및 자료사전을 기초로 작성함
    - Dictionary List에 등록되지 않은 약어는 책임자의 동의 하에 등록함
    - Column Name은 약어의 조합으로 구성
    - 컬럼명에 컬럼을 대표하는 접미사를 사용하여 컬럼명의 성격을 나타냄.
3.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를 사용한다. MSSQL의 Identity의 경우 주로 _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.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이 우선함

4. Index Name
4.1. 규칙
    - 해당하는 테이블명 뒤에 ‘_IX’를 붙여 index임을 명확히 함
    - 대문자를 사용함
    - 일련번호는 01 ~ 99까지 사용할 수 있음
    - MSSQL의 경우 클러스터드 인덱스와 넌 클러스터드 인덱스를 구분하여 작성함.

클러스터드 인덱스 _IXC를 사용하며, 넌 클러스터드 인덱스는 일반 인덱스 명 룰을 따름.
    - 테이블에 인덱스가 하나만 존재할 경우 일련번호를 사용하지 않아도 됨.
4.2. 표기 방식
      <시스템 구분> + ‘_’ + <의미있는 테이블명> + ‘_’ + IX{<일련번호>}
      예) Table명 ‘I01_MASTER_TB’의 Index : I01_MASTER_IX01

5. Primary Key Name
5.1. 규칙
    - 영문 대문자로 작성함
    - 해당하는 테이블명의 맨 뒤에 ‘_PK’라는 구분을 사용함
5.2. 표기방식
      <시스템 구분> + ‘_’ + <의미있는 테이블명> + ‘_’ + PK
      예) Table 명 ‘AC_USERS_TB’의 Primary Key : AC_USERS_PK

6. Foreign Key Name
6.1. 규칙
    - 영문 대문자로 작성함
    - 해당하는 테이블명의 맨 뒤에 ‘_FK’라는 구분을 사용함
    - 일반적으로 테이블명과 컬럼명까지 사용하나, OBJECT의 명칭이 길어져서 테이블명을 기준으로 작성함.
    - 일련번호 : 1 ~ 9
6.2. 표기방식
      <시스템 구분> + ‘_’ + <의미있는 테이블명> + ‘_’ + FK{<일련번호>}
      예) Table 명 ‘I01_MASTER_TB’의 Foreign Key : I01_MASTER_FK1

7. Stored Procedure Name
7.1. 규칙
    - 길이는 큰 제한이 없으나 오라클의 OBJECT NAME 길이 제한은 있음.
    - 해당하는 테이블명의 맨 뒤에 ‘_SP’라는 구분을 사용함
    - 기능명은 복수개 사용이 가능하면 3개의 단어를 넘지 않도록 함
    - 기능을 나타내는 명칭이 하나일 경우 일련번호를 생략해도 됨.
    - 단어간에는 ‘_’로 구분함
    - 업무룰에 해당되지 않는, 혹은 특정 테이블에 해당되지 않는 DBMS 전반적인 프로시저의 경우,

시스템 프로시저로 작성하는 경우에는 시스템구분 과 테이블명을 생략하고 간단히 작성할 수 있다.

예) 스키마 스크립트 GENERATION ? GENERATE_SP
- 오라클의 경우 패키지 내부의 프로시저의 경우 패키지 명칭에 시스템구분을 사용하므로,

프로시저나 함수명에 시스템구분 코드를 넣지 않는다.

또한 기능에 따른 일련번호를 사용하지 않고 OOP의 기능인 Method Overloading 의 기능을 사용하여 작성한다.

또한 명칭은 Camel 표기법을 사용하여 작성한다. 예) 사용자를 가져오는 경우 getUsers()
7.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	삭제작업(트랜잭션을 사용하여 여러 테이블에 삭제 작업이 이루어 질 때)

8. Function Name
8.1. 규칙
- 길이는 제한이 없으며 영문 대문자를 사용함
- 해당하는 테이블명의 맨 뒤에 ‘_FC’라는 구분을 사용함을 원칙으로 하나,

함수명이 길어서 사용상 불편할 경우, 특정 시스템에 국한하지 않고, 항상사용하는 라이브러리 같은 함수의 경우

       구분가능한 Short Name을 사용해도 무방하다.
    - 단어간에는 ‘_’로 구분함
    - 시스템 함수로 작성한 경우에는 접미사를 사용하지 않고, 간략한 함수이름을 사용한다. 예) INSTR, LEASTR(@x bigint, @y bigint) 등
    - 오라클의 경우 패키지 내부의 함수의 경우에는 프로시저의 해당 규칙에 따른다.

       즉 시스템구분 코드와 접미사를 사용하지 않고, Camel 표기법으로 간략하게 작성한다.
8.2. 표기방식
      <시스템 구분> + ‘_’ + <기능명> + ‘_’ + FC
      예) ‘I01_MASTER_TB’ 테이블에서 주소명를 가져오기 위한 Function
          : I01_GET_ADDRESSNAME_FC(p_AddressCode IN Char) 내지는
          : getAddressName(p_AddressCode IN Char)

9. Table Trigger Name
9.1. 규칙
    - 영문 대문자로 작성함
    - 일련번호는 01 ~ 99까지 사용 가능함
9.2. 표기방식
      <시스템 구분> + ‘_’ + <의미있는 테이블명> + ‘_’ + <일련번호> + ‘_’ + TG
    - Timing : B(Before), A(After)
    - Trigger Event : I(Insert), D(Delete), U(Update)

예) ‘I01_MASTER_TB’ 테이블에서 데이타 입력 후에 실행되는 Trigger
: I01_MASTER_AU01_TG

10. View Name
10.1. 규칙
    - 길이는 제한이 없으며, 영문 대문자로 작성함
    - 해당하는 테이블명의 맨 뒤에 ‘_VW’라는 구분을 사용함
    - 일련번호는 01 ~ 99까지 사용할 수 있음
10.2. 표기방식
      <시스템 구분> + ‘_’ + <의미있는 테이블명><일련번호> + ‘_’ + VW
      예) AC_ADMINL_USER_VW

11. Sequence Name <오라클의 경우에만 해당>
11.1. 규칙
    - 길이는 제한이 없으며 영문 대문자를 사용함
    - 해당하는 테이블명의 맨 뒤에 ‘_SQ’라는 구분을 사용함
11.2. 표기방식
      <시스템 구분> + ‘_’ + <의미있는 테이블명> + ‘_’ + SQ
      예) ‘I01_MASTER_TB’ 테이블의 Sequence : I01_MASTER_SQ

12. Package Name<오라클의 경우에만 해당>
12.1. 규칙
    - 길이는 제한이 없으며 영문 대문자를 사용함
    - 해당하는 테이블명의 맨 뒤에 ‘_PKG’라는 구분을 사용함
12.2. 표기방식
      <시스템 구분> + ‘_’ + <의미있는 패키지명> + ‘_’ + PKG
      예) 검색엔진에서 사용하는 자원에 관련된 패키지 : SCH__PKG

13. Check 제약조건
13.1. 규칙
    - 길이는 제한이 없으며 영문 대문자를 사용함
    - 기존의 명칭룰에 해당하는 접미사를 사용하지 않고, 예외적으로 접두어 CK_를 사용한다.
        일반적으로 CHECK와 DEFAULT 제약조건은 특정 테이블에 한정시켜서 작성하기 보다는
        시스템 전반에 걸쳐서 사용이 가능하므로 예외규정을 둔다.
13.2. 표기방식
      CK + ‘_’ + <의미있는 CHECK명>
      예) 이메일 체크 : CK_EMAIL
      예) 성별 체크 : CK_SEX

14. Default 제약조건
14.1. 규칙
    - 길이는 제한이 없으며 영문 대문자를 사용함
    - 기존의 명칭룰에 해당하는 접미사를 사용하지 않고, 예외적으로 접두어 DF_를 사용한다.
        일반적으로 CHECK와 DEFAULT 제약조건은 특정 테이블에 한정시켜서 작성하기 보다는
        시스템 전반에 걸쳐서 사용이 가능하므로 예외규정을 둔다
14.2. 표기방식
      DF + ‘_’ + <의미있는 DEFAULT명>
      예) Null String Default ? DF_NULLSTR
      예) 0(Zero) Default ? DF_ZERO

출처 : http://blog.daum.net/mindus/15564655

iBATIS(아이바티스) 시작

2013-09-22T13:01:01+00:00

데이터 매퍼는 자바빈즈, Map구현체, 원시래퍼타입(String, Integer…) 그리고 SQL문을 위한 XML문서를 매핑하기 위한 XML서술자를

사용하는 매우 간단한 프레임워크를 제공한다.

1.Value객체정의

    POJO타입의 파라미터 객체 정의

    파라미터(자바빈즈, Map 또는 원시래퍼)로써 객체를 제공한다.

    파라미터 객체는 update문에서 입력값을 셋팅하기 위해 사용되거나 쿼리문의 where절을 셋팅하기 위해서 사용된다

EmpVO

package ex1.vo;

public class EmpVO {
    //DB에서 가져올 컬럼명들을 멤버로 선언
    //사번 이름,직종,입사일
    private String employee_id,first_name,job_id,hire_date;

    public String getEmployee_id() {
        return employee_id;
    }

    public void setEmployee_id(String employee_id) {
        this.employee_id = employee_id;
    }

    public String getFirst_name() {
        return first_name;
    }

    public void setFirst_name(String first_name) {
        this.first_name = first_name;
    }

    public String getHire_date() {
        return hire_date;
    }

    public void setHire_date(String hire_date) {
        this.hire_date = hire_date;
    }

    public String getJob_id() {
        return job_id;
    }

    public void setJob_id(String job_id) {
        this.job_id = job_id;
    }

}

2.환경설정 파일(sqlMapConfig.xml) 작성

DB정보
SqlMap파일정보
SQL문을 위한 XML문서를 매핑하기 위한 XML서술자

<?xml version="1.0" encoding="EUC-KR"?>
<!DOCTYPE sqlMapConfig PUBLIC"-//ibatis.apache.org//DTD SQL Map Config 2.0//EN" "http://ibatis.apache.org/dtd/sql-map-config-2.dtd">
<sqlMapConfig>
    
    <transactionManager type="JDBC"> //트랜잭션타입은 JDBC
        <dataSource type="SIMPLE"> //간단한 JDBC로 할경우
            <property name="JDBC.Driver" value="oracle.jdbc.OracleDriver"/> //DB 드라이버
            <property name="JDBC.ConnectionURL" value="jdbc:oracle:thin:@localhost:1521:xe"/> //DB URL
            <property name="JDBC.Username" value="hr"/> //DB 아이디
            <property name="JDBC.Password" value="1111"/> // DB 패스워드
        </dataSource>
    </transactionManager>

    
    <sqlMap resource="ex1sqlMapemp.xml"/>

</sqlMapConfig>

3.sqlMap파일작성

SQL문 작성

구문타입

속성 (결과객체,파라미터객체지정)

사용하는 경우

<select>

id,parameterClass,resultClass,parameterMap,resultMap

데이터조회

<insert>

id,parameterMap,resultMap

데이터입력

<update>

id,parameterMap,resultMap

데이터수정

<delete>

id,parameterMap,resultMap

데이터삭제

데이터 매퍼프레임워크는 매핑된 구문을 실행하여 PreparedStatement 인스턴스를 생성할것이고

제공된 파라미터객체를 사용해서 파라미터를 셋팅하고 ResultSet으로부터 결과 객체를 생성한다.

<sql.xml>

<?xml version="1.0" encoding="EUC-KR"?>
<!DOCTYPE sqlMap PUBLIC "-//ibatis.apache.org//DTD SQL Map 2.0//EN" "http://ibatis.apache.org/dtd/sql-map-2.dtd">
<sqlMap>
    
    <select id="empAll" resultClass="ex1.vo.EmpVO">
        SELECT employee_id,first_name,job_id,hire_date FROM employees
    </select>

    <select id="searchName" resultClass="ex1.vo.EmpVO" parameterClass="String">
        SELECT * FROM employees WHERE first_name = #n#
    </select>
</sqlMap>

4.JavaApp생성

1 ) 환경설정파일 스트림 로드
2 ) 클라이언트객체생성
3 ) iBATIS를 활용하여 SQL문 호출

  4 ) 결과확인

       update의 경우에 영향을 미친 rows의 숫자를 반환한다.

       조회작업인 경우에 한 개(single)의 객체 또는 컬렉션 객체를 반환한다.

       파라미터처럼 결과 객체는 자바빈즈, Map 원시타입래퍼또는 XML이 될수 있다.

package ex1.client;

import com.ibatis.common.resources.Resources;
import com.ibatis.sqlmap.client.SqlMapClient;
import com.ibatis.sqlmap.client.SqlMapClientBuilder;
import ex1.vo.EmpVO;
import java.io.IOException;
import java.io.Reader;
import java.sql.SQLException;
import java.util.List;
import java.util.Scanner;

public class EmpClient {
    public static void main(String[] args) throws IOException, SQLException {
        //1)iBATIS환경설정 파일(sqlMapConfig.xml)을 스트림으로 생성한다
        Reader r = Resources.getResourceAsReader("ex1/config/sqlMapConfig.xml");

        //2)위에서 생성한 스트림을 가지고 sqlMap들만 가져와 sqlMapClient에게 전해준다.
        SqlMapClient smap = SqlMapClientBuilder.buildSqlMapClient(r);

        r.close();

        //3) iBATIS활용-id가 empAll인 select요소를 수행한다.
        List<EmpVO> list = smap.queryForList("empAll");

        //4) 확인
        for (EmpVO vo : list) {
            System.out.println(vo.getEmployee_id()+"/"+vo.getFirst_name());
        }

        System.out.print("이름:");
        Scanner sc = new Scanner(System.in);
        String name = sc.nextLine();

        List<EmpVO> names = smap.queryForList("searchName", name);
         for (EmpVO vo : names) {
            System.out.println(vo.getEmployee_id()+"/"+vo.getFirst_name());
        }
    }
}

출처 : http://blog.naver.com/poloecko/70094795635

iBatis(아이바티스)란?

2013-09-22T12:59:30+00:00

iBatis란?

더 빠른 JDBC 코딩을 위한 일반화된 프레임워크
- SQL 매퍼 + DAO 프레임워크

iBatis는 데이터베이스에 있는 자원들을 보다 편리하게 가져오기 위한 프레임워크이다.

XML서술자를 사용해서 간단하게 자바빈즈를 PreparedStatement의 바인드 변수인 파라미터와

ResultSet으로 맵핑시켜주는 기능으로 SQL Maps 또한 ORM이라고도 한다.

iBATIS 데이터 매퍼 프레임워크는 관계형 데이터베이스에 접근할 때 가독성, 유지보수성, 생산성 등을 향상시켜준다.

특징

간결함과 쉬운 접근성

다른 프레임워크와 객체관계맵핑툴에 비해 가장 간단한 퍼시스턴스 프레임워크

iBATIS 데이터 매퍼를 사용하기 위해서 자바빈즈와 XML 그리고 SQL만 알면 추가적으로 배워야 할것이 거의 없고

테이블을 조인하거나 복잡한 쿼리문을 수행하기 위해 필요한 복잡한 스키마도 없다.

데이터 매퍼를 사용하면 실제 SQL문의 모든 기능을 그대로 사용할수 있으며,

XML 형태로 서술된 JDBC 코드라고 생각해도 될 만큼 JDBC에 적용되는 거의 모든 기능은 iBATIS에서도 잘 적용된다

데이터베이스 관리자와 SQL 프로그래머 양 쪽 모두 이해하기 용이하다

생산성의 향상

JDBC와 SQL을 유지하면서도 훨씬 더 적은 코드로도 JDBC처럼 작동

자바코드의 20%를 사용하여 JDBC기능의 80%를 제공하는 간단한 프레임워크

작성할 필요가 없는 JDBC 코드로 인한 분량 문제는 현저하게 줄어듬 (JDBC에 비해 62%정도)

일반적으로 프레임워크는 장황한 코드를 제거하고 복잡한 구조적인 문제를 해결하면서 공통적인 작업을 수행하기 위해 존재

성능

구조적 강점 - 데이터 접근 속도 높여주는 JOIN매핑

여러가지 방식의 데이터 가져오기 전략

불필요한 수천 개의 행을 한꺼번에 데이터베이스로부터 가져오는 것 X

가져오기 미루기, SQL 줄이기 기법

=> 애플리케이션의 성능을 명백히 향상

SQL 문장과 프로그래밍 코드의 분리

작업의 분배 - 팀을 세분화하는 것을 도움

SQL문과 Java코드와의 분리만으로도 Java개발자는 Query문을 신경쓰지 않아도 된다.

SQL문이 변경되더라도 파라미터 값만 변경되지 않는다면 Java소스에서 수정할 부분이 없기 때문이다.

이식성

어떤 프로그래밍 언어로도 구현가능하다

예) 자바, C#(iBATIS.NET), Ruby(RBATIS)

데이터베이스 접근 클래스와 비즈니스 로직을 담은 클래스의 분리

이른바 DAO(Data Access Object) 패턴이 이러한 일을 담당한다.

ibatis는 DAO 계층 구현을 위한 유틸리티 성격이면서 동시에 best practice 역할도 수행한다.

자주 쓰이는 데이터를 변경되지 않는 동안에 임시 보관(Cache)

ibatis 에선 XML 설정만으로 캐시를 할 수 있다.

트랜젝션과 쓰레드 관리

트랜젝션 처리 역시 용이하다.

출처 : http://blog.naver.com/poloecko/70094791801

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

Java에서 사용되는 ORM툴 중 Hibernate와 iBatis중 국내 많은 업체들이 iBatis를 선택한 이유는 여러 설정이 필요한 Hibernate에 비해 iBatis는 직관적이여서(SQL문을 직접 쓰기때문) 이해가 빠르기 때문일것이다.

하지만 세계적 추세는 Hibernate를 중시하며 추진하는 분위기며 (제7회 공감 개발자세미나) 유연한 확장성과 대처에는 Hibernate가 좋다고 한다.

하지만 국내 개발환경(협의 후 테이블 구축 유지)에는 iBatis가 좀더 유용하며 주류가 되는 추세이다. 쿼리문의 처리에는 iBatis가 조금더 성능이 우세하다.

2010년 6월16일 이후 구글코드로 이전함에 따라 myBatis로 개명하였다*. 하지만 편의와 대중성을 위해 iBatis로 진행하겠다.

*창시자인 Clinton Begin이 iBatis의 모든 코드를 apache재단 에 기부함에 따라 이름도 바꾸었다고한다.

1. iBatis의 특징

1) 간결함, 쉬운 접근성

sql문을 xml에 그대로 서술하기 때문에 기존 sql문처리에 익숙한 개발자들이 다가가기 쉽다.

그에 따른 장점으로 개발자와 DB관리의 양쪽 모두 이해에 용이하다.

2) 생산성의 향상

JDBC의 많은 설정을 간결하게 줄여줌으로 인해 개발자의 작성분량을 줄여준다.

3) 성능

성능최적화 기법을 지원한다.

ex)예를 들어 가장 중요한 기능이라면 페이징 처리된 데이터 리스트를 읽어와서 사용할 때 불필요한 수천개의 행을 한꺼번에 데이터베이스로부터 가져오는것이 아니기 때문에 어플리케이션의 성능을 향상시킬수있다.

(이해가안되서 그냥 그대로 타이핑하였다. 코드상 처리의 장점을 말하는것 같다.)

출처 : http://metalbird.tistory.com/entry/iBatis%EB%9E%80

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

#iBatis란?

iBatis(아이바티스)는 SQL에 기반한 데이터베이스와 자바. 닷넷, 루비등을 연결시켜주는 역할을 하는 영속성 프레임워크이다. 이러한 연결은 프로그램의 소스코드에서 SQL문장을 분리하여 별도의 XML 파일로 저장하고 이 둘을 서로 연결시켜주는 방식으로 작동한다.

#데이터매퍼

iBatis 데이터매퍼 API는 프로그래머에게 자바빈즈 객체를 PreparedStatement 파라미터와 ResultSets으로 쉽게 매핑할 수 있도록 한다. 이는 자바코드의 20%를 사용하여 JDBC기능의 80%제공하는 간단한 프레임워크라는 뜻이다.

데이터 매퍼는 자바빈즈, Map구현체, 원시래퍼타입(String, Integer..) 그리고 SQL문을 위한 XML문서를 매핑하는 XML서술자를 사용하는 매우 간단한 프레임워크를 제공한다. 데이터 매퍼가 관리하는 생명주기는 다음과 같다.

파라미터(자바빈즈,Map 또는 원시래퍼)로써 객체를 제공한다. 파라미터 객체는 update문에서 입력값을 세팅하기 위해 사용되거나 쿼리문의 where절을 셋팅하기 위해서 사용된다.
매핑된 구문을 실행한다. 이 단계는 PreparedStatement 인스턴스를 생성할 것이고 제공된 파라미터 객체를 사용해서 파라미터를 셋팅한다. 그 후 구문을 실행하고 ResultSet으로부터 결과 객체를 생성한다.
update의 경우에 영향을 미친 rows의 숫자를 반환한다. 조회작업인 경우에 한 개의 객체 또는 컬렉션 객체를 반환한다. 파라미터처럼 결과 객체는 자바빈즈, Map 원시타입 래퍼또는 XML이 될 수 있다.

출처 : http://javaclass1.tistory.com/150

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

iBATIS의 개념

iBATIS는 간단한 XML서술자를 사용해서 간단하게 자바빈즈를 SQL statement에 맵핑시킨다. 간단함(Simplicity)이란 다른 프레임워크와 객체관계맵핑툴에 비해 iBATIS의 가장 큰 장점이다. iBATIS Data Mapper를 사용하기 위해서 당신은 자바빈즈와 XML 그리고 SQL에 친숙할 필요가 있다. 여기엔 배워야 할것도 거의 없고 테이블을 조인하거나 복잡한 쿼리문을 수행하기 위해 필요한 복잡한 스키마도 없다. Data Mapper를 사용하면 당신은 실제 SQL문의 모든 기능을 가질수 있다. JDBC 로만 프로그래밍 할 때의 번거로움을 줄여주기 위해 재사용 모듈로 개발된 것인데 그 주요한 어려움을 ibatis 개발자 가이드에서 다음과 같이 정리하고 있다.

iBATIS의 역사와 사용

SQL 문장과 프로그래밍 코드의 분리
JDBC 라이브러리를 통해 매개변수를 전달하고 결과를 추출하는 일
데이터베이스 접근 클래스와 비즈니스 로직을 담은 클래스의 분리
자주 쓰이는 데이터를 변경되지 않는 동안에 임시 보관(Cache)
트랜젝션과 쓰레드 관리

이러한 사항들에 대해서 한번쯤 생각해볼 필요가 있다.

SQL 문장과 프로그래밍 코드의 분리

SQL문과 프로그램 코드는 꼭 분리해야 할까? 우선 프로그램이 작은 경우는 굳이 분리할 필요가 없어 보인다. 파일만 두개로 분리되기 때문에 관리에 불편함이 가중될 수 있다. 프로그램이 커져도 분리하는 것이 꼭 유리한 것만은 아니다. SQL을 사용하는 클래스가 1000개라면 분리했을 때 2000개가 되어서 더 복잡해질 수도 있다. 그럼에도 불구하고 ibatis에서는 SQL을 분리하는 이유는 무엇일까?

Separation of Concern!! 할 일의 명확한 분리. 아마도 이것이라 짐작된다. 자바 코드에서 SQL을 없애서 순수 OO로 만들어놓기. 이것은 결벽증이나 지나친 원리집착이 아니라 체계가 다른 것을 나누어 보관하는 것이다. 논리적으로 정연한 흐름을 만들어 둘 수 있고, 객체지향 입장에서 데이터에 해당하는 도메인 모델(Domain model) 혹은 도메인 객체(Domain object)와 관계형 데이터베이스의 테이블(Table)을 느슨한 관계(loosely coupled)로 만들어서 변화에 대한 유연성을 확보할 수도 있다. 즉, 정규화를 위해서 혹은 데이터 접근의 효율성을 위해서 테이블 구조를 바꾸어도 프로그램 코드 안에 있는 SQL을 수정할 필요가 없어진다.

JDBC 라이브러리를 통해 매개변수를 전달하고 결과를 추출하는 일

select 등를 할 때 조건에 해당하는 매개변수를 설정하거나, insert 문에서 값을 할당하기 위해 매개변수를 설정하는 일은 무척 번거로운 일이다. 단순한 일이면서도 오류가 잦은 부분이다. 때문에 프로젝트를 몇 차례 겪고 나면 자신만의 라이브러리를 만들거나 공통팀에서 유틸리티를 제공하는 일을 흔하게 볼 수 있다. Apache Commons의 DB Utils 나 Spring의 JDBC Template 등은 이러한 작업을 용이하게 하려고 등장했고, ibatis 역시 이러한 작업을 훨씬 부드럽게 해준다.

데이터베이스 접근 클래스와 비즈니스 로직을 담은 클래스의 분리

이른바 DAO(Data Access Object) 패턴이 이러한 일을 담당한다. ibatis는 DAO 계층 구현을 위한 유틸리티 성격이면서 동시에 best practice 역할도 수행한다.

자주 쓰이는 데이터를 변경되지 않는 동안에 임시 보관(Cache)

ibatis 에선 XML 설정만으로 캐시를 할 수 있다.

트랜젝션과 쓰레드 관리

트랜젝션 처리 역시 용이하다.

iBATIS의 주요기능

Data Mapper (com.ibatis.sqlmap.*)

개념
iBATIS Data Mapper API는 프로그래머에게 자바빈즈 객체를 PreparedStatement파라미터와 ResultSets으로 쉽게 맵핑할 수 있도록 한다. Data Mapper의 기본적인 생각은 간단함(simple)이다. 이는 자바코드의 20%를 사용하여 JDBC기능의 80%를 제공하는 간단한 프레임워크라는 뜻이다.

작동원리
Data Mapper는 자바빈즈, Map구현, 원시래퍼타입(String, Integer…) 그리고 SQL문을 위한 XML문서를 맵핑하기 위한 XML서술자를 사용하는 매우 간단한 프레임워크를 제공한다.

다음은 생명주기에 대한 높은 레벨의 서술이다.

1) 파라미터(자바빈즈, Map 또는 원시래퍼)로써 객체를 제공한다. 파라미터 객체는 update문내에 입력값을 셋팅하기 위해 사용되거나 쿼리문의 where절을 셋팅하기 위해서 사용된다.

2) 맵핑된 statement을 실행한다. 이 단계는 마법이 일어나는곳이다. Data Mapper프레임워크는
PreparedStatement 인스턴스를 생성할것이고 제공된 파라미터객체를 사용해서 파라미터를 셋팅한다. 그리고 statement를 실행하고 ResultSet으로부터 결과 객체를 생성한다.

3) update의 경우에 영향을 미친 rows의 숫자를 반환한다. 조회문일경우에 한 개(single)의 객체 또는 컬렉션 객체를 반환한다. 파라미터처럼 결과 객체는 자바빈즈, Map 원시타입래퍼또는 XML이 될수 있다.

출처 : http://blog.empas.com/ahnyounghoe/11535652

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

가장 간단히 설명하면, JAVA에서 DB관련 작업을 편하게 해주는 프레임웍정도라고 할까?

iBATIS in action에서 iBATIS는 "SQL 실행 결과를 자바빈즈 혹은 Map 객체에 매핑해주는 퍼시스턴스 솔루션으로 SQL을 소스 코드가 아닌 XML로 따로 분리해 관리하여 지겨운 SQL 문자열 더하기에서 해방시켜 줍니다. 또한 XML에서 동적 SQL 요소를 사용하여 쿼리 문장을 프로그래밍 코딩 없이 자유롭게 변환할 수 있게 해줍니다. 이러한 접근방식으로 인해 iBATIS를 사용하면 JDBC를 사용할 때보다 약 60% 정도의 코드만으로 프로그램 작성이 가능하다" 라고 한다.

말로만 하면 뭔소리인지 모르겠으니 간단한 예제 정도를 들어보자.

- 일반적인 JDBC 예제

import javax.naming.*;
import javax.sql.*;
import java.sql.*;

public class Employee {
  public Account getAccount(int id) throws SQLException, NamingException{
    Account account = null;

    String sql = "select * from employee where id= ?";

    Connection conn      = null;
    PreparedStatement ps = null;
    ResultSet rs       = null;

    try {
      Context ctx = new InitialContext();
      DataSource ds =
              (DataSource)ctx.lookup(
                 "java:comp/env/jdbc/TestDB");
      conn = ds.getConnection();
      ps = conn.prepareStatement(sql);
      ps.setInt(1, id);
      rs = ps.executeQuery();

      while( rs.next()){
        account = new Account();
        account.setId(rs.getInt("ID"));
      }
    } finally {
      try {
        if ( rs != null ) rs.close();
      } finally {
        try {
          if (ps != null) ps.close();
        } finally {
          if (conn != null) ps.close();
        }
      }
    }
    return account;
  }
}

뭐다들 아시겠지만 간단히 쿼리를 날려서 Acount 객체에 담아가지고 오는 소스이다. 대충봐도 무척이나 길다,

이걸 iBATIS를 이용해서 처리하는 예를 보자,

- iBATIS 를 이용한 예

acount.xml
<select id="getAcount" resultClass="Acount" parameterClass="java.lang.Integer">
select * from employee where id= #id#
</select>

java
Acount act = (Acount) sqlMap.queryForObject("getAcount",new Integer(5));

보면 알겠지만 상단에 쿼리를 닮고있는 xml과 아래 간단히 크 쿼리를 실행시키는 java 한줄정도?이다.

사실 iBATIS를 설정하는 config파일과 sqlMap객체를 불러오는 부분이 있긴하지만, 무척이나 좋아보이도록,
이것만 쓰겠다. -_-;;

iBATIS 의 목표와 특징은 몇마디로 짧게정의하다면,

쉽고, 간단하고, 의존성이 적은 프레임웍이라는 것이다.
sql문과 java코드와의 분리만으로도 java개발자는 쿼리문을 신경쓰지 않아도 된다. sql문이 변경되더라도,

파라미터 값만 변경되지 않는다면, java소스에서는 수정할 부분이 없다.

~ 이론적인 면은 대충 접어두고 실전으로 넘어가자(사실 나도잘몰라서;;ㅈㅅ)

다음 포스트는 실제로 이클립스에서 오라클 디비와 연동하겠습니다.

출처 : http://beans.tistory.com/36

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

IBatis 는 XML 에 정의한 SQL 문을 이용하여 일반적으로 작성하는 데이터베이스 프로그래밍의 코드를 현저하게 줄여주는 Database Mapper Framework 이다.

IBatis 는 Apache Project 에서 나온 오픈소스이며, 자바진영에서는 매우 많이 사용되는 Data Mapper 프레임워크이다.

IBatis Site 는 http://ibatis.apache.org/ 이며, for.NET 메뉴를 선택하면 해당 프로그램과 도큐멘트를 받을 수 있다.

일반적으로 Web Form 에서 사용자가 데이터를 입력하고 submit 을 하게 되면 데이터베이스에 입력하기 위해서 아래와 같은 방법을 취하게 된다.

1. 입력된 데이터 검증.

2. SqlConnection 생성 및 연결

3. SqlCommand 에 파라미터를 대입

4. 데이터베이스에 입력

5. 데이터베이스 연결 종료

이것을 코드로 표현하면 아래와 같다.

-------------------------------------------------------------------------

String sql = "INSERT INTO member (userName, userId, passwd, email, regDate, etc) "

+ " VALUES (@userName, @userId, @passwd, @email, @regDate, @etc)";

SqlConnection conn = new SqlConnection(connectionStr);

SqlCommand command = new SqlCommand();

command.Connection = conn;

command.CommandText = sql;

command.Parameters.AddWithValue("@userName", userName.Text);

command.Parameters.AddWithValue("@userId", userId.Text);

command.Parameters.AddWithValue("@passwd", passwd.Text);

command.Parameters.AddWithValue("@email", email.Text);

command.Parameters.AddWithValue("@regDate", DateTime.Now);

command.Parameters.AddWithValue("@etc", etc.Text);

int affectedRow = command.ExecuteNonQuery();

conn.close();

-------------------------------------------------------------------------

이런 식으로 데이터 입력이 된다.

command 객체에 입력 파라미터를 대입하는 부분이 데이터를 입력하는 부분마다 이런식으로 작업이 되면 계속되는 반복작업으로 효율성이 떨어지게 된다.

뭐 이런 부분들을 작업이 용이하게 만들면 되지 라고 할 수도 있겠지만, 자동화 시키려면 DataSet 이나, 형식화된 DataSet, 사용자 정의 Property, Map 으로 작업해야 하지만, 여기에서 또 문제가 생긴다. 트랜잭션은 어떻게 자동화 시킬 것이며, 매개변수로 넘어오는 object 들을 SqlCommand 객체에 대입할 것이며 등등...

거 리플렉션으로 넘어오는 Object 들을 분석해서 SqlCommand 랑 대입하면 되잖아 할수도 있지만.. 만들려고 하면 이것저것 생각할 것도 많고, 상당히 귀찮은 일이 된다.

그리고 일을 하다 보면 프로그램을 실제 구현하는 것보다, 남이 만들어 놓은 프로그램을 구해서 작업을 더 많이 하게 되고, 이런 작업속에서 문제가 생겼을 경우 검색엔진을 통해서 남이 먼저 한 삽질을 찾아내서 나의 삽질을 고치게 된다.

이러한 부분을 IBatis.NET 을 이용하면 많은 부분이 해결된다.

위의 코드를 IBatis 로 대입하면 아래와 같이 된다.

1. 먼저 특정 테이블의 컬럼과 형식이 일치하는 객체를 만든다.

2. 해당 객체에 사용자가 제출한 값을 입력한다.

3. IBatis 를 입력하여 데이터를 저장한다.

간략하게 소스를 보자

--------------------------------------------------------------------

// 테이블과 1:1로 대응하는 Object생성

MemberItem memItem = new MemberItem();

// 데이터베이스에 입력 할 값들을 Object에 입력

// 아래 소스를 PropertyBinder.Bind(memItem) 처럼 자동화

memItem.UserName = UserName.Text;

memItem.UserId = UserId.Text;

memItem.Passwd = Passwd.Text;

memItem.Email = Email.Text;

memItem.RegDate = DateTime.Now;

memItem.Etc = Etc.Text;

// IBatis 를 이용하여 데이터 입력

IBatisNet.DataMapper.Mapper.Instance().Insert("createMember", memItem);

------------------------------------------------------------------------

소스가 상당히 간략해 졌다.

여기에서 중요한 부분이 있는데 SqlConnection, SqlCommand 를 생성한 부분이 없다.

연결 문자열 같은 경우는 별도의 설정 파일에 미리 입력해 두면 되고, 이 정보를 이용하여

IBatis 의 Insert() 가 호출 되면 데이터베이스 입력에 필요한 객체들이 자동으로 만들어 지게 된다.

또한 위의 소스중에서 IBatisNet.DataMapper.Mapper.Instance().Insert("createMember", memItem);

부분의 Insert 메소드에 "createMember" 라는 부분은 별도의 XML 파일에 정의된 쿼리를 지칭한다.

아래의 xml 부분이 sql query 를 별도로 저장해 놓은 부분이다.

<?xml version="1.0" encoding="utf-8" ?>

<statements>
   <insert id="createMember" parameterClass="Member.MemberItem">
        INSERT INTO member (userName, userId, passwd, email, regDate, etc)
         VALUES (#userName#, #userId#, #passwd#, #email#, #regDate#, #etc#)
       <selectKey property="idx" type="post" resultClass="int">
          select @@IDENTITY as value
       </selectKey>
     </insert>
</statements>
</sqlMap>

출처 : http://blog.daum.net/cycos88/8

innodb 와 myisam 의 차이점과 성능비교

2013-04-11T19:30:10+00:00

1. innodb 과 isam 의 비교

innodb :

데이터 파일 : Shared Datafile (인덱스와 데이터 공간이 공유)

innodb_file_per_table 를 설정하면 테이블 단위의 데이터 파일로 분리가 된다.

그러나 테이블 정보는 메인 Shared DataFile에 저장 된다.

따라서 백업에 반드시 메인 SharedDB 파일도 같이 이루어 져야한다.

MyIsam에 비해 약 1.5 ~ 2.5배의 정도 파일이 더 크게 필요로 한다.

데이터 량이 감소하더라도 증가된 데이터 파일 사이즈는 그대로임.

(OPTIMIZE TABLE `테이블` 을 수행 하면 리사이징 됨.)

트랜젝션 : ib_logfileN log파일을 통하여 대량의 트랜젝션을 버퍼링 하고 Seriallization 을 한다.

(로그파일은 최소 2개의 그룹이며, 서로 Rotate 스위칭되며 갱신되 데이터를 파일로

적용 한다. )

속 도 : 인덱스와 데이터 파일이 같은 파일에 있어 속도가 느리다.

대량의 insert, update가 일어 나면 fragment가 발생되어 더느려 진다.

백 업 : 테이블 단위의 hot Backup (파일 복사) 가 불가능하고,

mysqldump나 데이터 베이스 전체적인 복사가 필요하다.

백업에 반드시 메인 SharedDB 파일도 같이 이루어 져야한다.

MyIsam :

데이터 파일 : 인덱스(*.MYI) 와 데이터 파일(*.MYD) 분리

( innodb 보다 파일 크기가 작게 소요)

데이터 량이 감소하더라도 증가된 데이터 파일 사이즈는 그대로임.

OPTIMIZE TABLE `테이블` 을 수행 하면 리사이징 됨.

트랜젝션 : 테이블 락을 기본으로 insert update delete 가 이루어 진다.

속 도 : 인덱스와 데이터 파일이 테이블 단위 이므로 속도가 빠르다.

백 업 : 테이블 단위의 hot Backup (파일 복사) 가 유용하다.

테이블 파일만 있더라도 복구가 가능하다.

2. 필자의 견해

일반적으로 데이터 베이스의 생명은 lock 처리 이며, 성능은 디스크 분산에서 부터 결정된다

디스크 분산이 잘되어야 복구부터 로드분산이 가능하고 성능이 향상 되는 것이다.

아직 mysql은 이부분이 미흡하다.

기본 적으로 innodb는 디스크별 스토리지를 배분하기에 아직 Oracle만큼 기대할수 없다.

전반적인 평가는 Oracle을 10점으로 준다면 Mysql은 5 ~ 6점 정도가 적합하다고 본다.

아직 mysql은 속도만이 흡족한 상태이며 전문적인 부분에 있어 아직은 미흡한상태다..

하지만 미래의 데이터 베이스는 Hybrid Database 가 된다고 한다.

지금 mysql NDB Clustering 을 보면 hybrid 에 근접한 부분을 볼수가 있다.

필자는 아직 이부분을 실습 해보지는 않았지만 지금의 일반적인 mysql의 버전 보다

성능이나 기능에 있어 진보적이라고 생각한다.

향후에 상당한 사용자가 늘것으로 본며 추후에 NDB 에 대한 실습을 해보고자 한다.

-http://blog.empas.com/ing1560/18458056 펌

출처 : http://blueamor.tistory.com/620

DB 모델링 툴 검토

2013-03-21T11:28:40+00:00

ERMaster
http://ermaster.sourceforge.net/
리버스 엔지니어링 반쪽
import 가능하나 export시 테이블, 뷰, 시퀀스 등 삭제 후 재생성. 기존 자료 삭제됨

SQL Power Architect (무료버전)
PostgreSQL 자료형 serial, text 지원안됨.
리버스 엔지니어링은 됨.

출처 : http://iyobkim.blogspot.kr/2012/09/blog-post.html

데이터베이스 모델링 툴의 새로운 대안 eXERD

2013-03-21T11:17:59+00:00

데이터베이스 모델링

웹 개발이나 관리 소프트웨어 같은 정보 시스템을 구축할 때 가장 중요한 작업 중 하나가 데이터베이스 모델링입니다. 데이터베이스 모델링은 정보 시스템에서 사용하는 데이터베이스 오브젝트 모델을 설계하는 것을 말합니다.

데이터베이스 모델링 도구

데이터베이스를 모델링 할 때 모델링 도구를 사용하게 되는데 기능이 많고 복잡하고 가격이 비싸기 때문에 데이터베이스 모델러만 모델링 도구를 사용하고 개발자들은 ERD 출력물을 참고하여 개발하는 것이 현실입니다. 하지만 수많은 테이블들을 출력물을 이용하여 관리하고 개발하는 것은 상당한 시간이 소요되는 작업입니다. 예를 들어, 영어를 번역하는데 종이 사전을 사용하여 영어 단어를 찾는 것과 같습니다. 개발자도 ER 모델링 도구를 사용하면 작업이 빨라지겠지만 모든 개발자가 사용하기에는 비용이 만만치 않습니다. 그래서 꼭 필요한 기능을 포함하고 쉽고 저렴한 국내 제품인 eXERD를 소개합니다.

세상에서 가장 아름답고 제일 쉬운 ER-모델링 도구

국산 데이터베이스 모델링 도구 eXERD

eXERD는 기존 모델링 도구의 가격으로 모든 개발자가 사용할 수 있는 국내 데이터베이스 모델링 도구입니다. eXERD는 기본적으로 단독으로 사용할 수 있지만 이클립스를 기반으로 하고 있기 때문에 이클립스에 플러그인 형태로 설치해서 사용할 수도 있습니다. eXERD는 가장 기본이 되는 테이블, 컬럼, 데이터 타입 등을 대화 상자를 이용하지 않고 다이어그램 상에서 엑셀과 같은 방식으로 빠르고 편하게 디자인 할 수 있습니다. 그리고 국산 제품에 걸맞게 한글 자소 단위의 입력 제안이나 검색 등을 지원합니다. 또한, 논리 이름과 물리 이름을 다이어그램 상에 동시에 보여주고 편집 할 수 있다는 것이 강점입니다.

논리 이름, 물리 이름 그리고 편집

eXERD는 개발자를 위한 모델링 도구 답게 논리 이름과 물리 이름을 동시에 보여 주는 기능을 제공합니다. 개발자가 테이블이나 컬럼 이름을 참고하여 질의를 작성할 때 암호 코드 같은 물리 이름을 해석하기 위해 노력하지 않아도 됩니다. 이 사항은 출력물일 경우에도 동일하게 적용됩니다. 이런 단순한 아이디어가 개발자들의 가장 큰 불편함을 해소해 주는 요소입니다. 또한, 논리 이름, 물리 이름, 도메인, 데이터 타입, NOT NULL, 주석을 다이어그램 상에서 보여주고 스프레드시트와 같이 빠르고 손쉬운 편집이 가능한 것이 강점입니다.

논리 이름, 물리 이름을 동시에 보여주고 편집

애니메이션, 강조, 공지

eXERD의 놀라운 점 중 하나는 변경 사항이 발생하였을 때 애니메이션을 통하여 변경 내역을 이해 할 수 있게 한다는 점과 선택 된 개체나 작업 내역에 대해 강조함으로서 사용자에게 더욱 자세한 정보를 전달한다는 것에 있습니다. 또한, 변경 사항이 발생하였을 때 다이어그램 상에서 변경 내역을 알림 바를 통하여 공지합니다. 이러한 요소들은 변경 내역이나 현재 상황을 사용자가 정확하게 인지하도록 합니다.

컬럼 삭제 취소에 대한 공지와 삭제가 취소된 컬럼 가리키기

한글 지원

한글 메뉴와 도움말을 지원합니다. 또한, 한글 자소 단위로 도메인 입력 제안이나 검색을 지원합니다.

한글 자소 입력에 대응하는 도메인 제안 기능

검토 및 자동 수정

데이터 모델의 논리/물리적인 결함 뿐만이 아니라 표준화 준수 여부 등을 검토하여 경고 및 오류 수준으로 구분하여 사용자에게 알려줍니다. 이렇게 알려진 결과 중 자동으로 해결 될 수 있는 사항은 자동 수정 기능을 이용하여 자동으로 문제를 해결 할 수 있습니다.

검토 기능 및 문제 수정

관계 선 자동 배치

테이블과 외래 키를 디자인 하면서 상당히 많은 시간을 소요 하는 부분 중 하나가 관계 선을 배치하는 작업입니다. 보기 좋게 관계 선을 배치하고 난 후 추가 사항이 생기면 또 선을 재배치 해야 합니다. eXERD는 관계 선을 자동으로 배치 해 줍니다. 그렇기 때문에 선 정리에 시간을 많이 투자하지 않고 데이터베이스 모델링 자체에만 집중 할 수 있게 됩니다.

관계 선 자동 배치

이클립스 기반의 장점

eXERD는 단독으로 실행 할 수 있긴 하지만 이클립스를 기반으로 하고 있기 때문에 이클립스를 사용하여 개발하고 있다면 개발 도구에 플러그인 형태로 설치하여 통합 할 수 있습니다. 별도의 어플리케이션을 실행하지 않고 이클립스 내에서 개발과 데이터베이스 모델링을 동시에 할 수 있다는 점은 큰 매력입니다.

이클립스 플렛폼과 eXERD

아쉬운 점

아직까지 부족한 점도 많이 보입니다. 최근 추가된 ERwin 가져오기 기능은 7.x 버전의 파일만 지원하고 가져오는 속성도 기본적인 부분에 한정되어 있습니다. ERwin 파일로 포워드 엔지니어링을 통하여 데이터베이스에 반영하고 eXERD에서 반영된 사항을 리버스 엔지니어링을 통하여 가져오는 것이 더 확실해 보입니다. 그리고 협업 작업에 대한 지원이 부족하고 지원하는 데이터베이스의 종류가 적다는 점도 아쉬운 점입니다.

결론

대체적으로 데이터베이스 모델링 도구로서 기본적인 기능들을 모두 지원하고 사용하기가 편리하기 때문에 기존 제품들의 대안으로 충분해 보입니다. 데이터베이스 모델링 도구는 모델링만 하는 것이 아니라 빠르게 모델을 검색하고 속성들을 쉽게 파악할 수 있는 도구로도 사용될 수 있기 때문에 개발자에게도 꼭 필요한 도구라 할 수 있습니다. 이러한 관점에서 기존 제품보다 저렴한 eXERD는 기존 제품의 가격을 투자해서 많은 개발자들이 혜택을 볼 수 있는 도구입니다.

[eXERD 홈페이지] http://exerd.com

출처 : http://mhjung.wordpress.com/2012/06/19/exerd/

무료 DB모델링툴(Freeware) 검토결과

2013-03-21T11:14:20+00:00

1. 검토 결과 입니다.

■ mySQL - Workbench

Logical명, Physical명 각각의 view가 없고 Only Physical 명으로만 관리가 가능합니다.

툴의 테이블 단위 오브젝트에 코멘트 같은것을 달수도 없습니다

관계 그리고, Reverse 되는 등의 기능은 있지만, 실제로 모델링하기는 좋지 않네요

■ SQL Power Architect

Logical명, Physical명 되는 툴을 찾기위해 SQL Power Architect 라는 놈을 깔아보았습니다.

키보드 화살표로 속성간 이동이 됩니다.

속성명을 바꾸려면 엔터친 다음, 탭키로 속성명으로 이동후 편집후 Ctrl + Enter로 변경이 쉽게 되네요. ( ErWin 처럼 F2키로 쉽게 바꾸진 못하지만 그런대로 쓸만하죠? )

리버스도 잘되는거 같구요

툴의 테이블, 컬럼 오브젝트에 비고 항목도 있습니다.

허나 제가 모델링 도구로 쓰기는 힘들거 같습니다. 생산성이 안날거 같습니다.

Logical명, Physical명은 되지만 view전환이 설정창을 통해서만 가능합니다. 아쉽네요.

다운로드는 여기서 가능합니다. http://code.google.com/p/power-architect/

■ exERD
무료는 아니지만 1copy 30만원임. 올해 3분기때 mySQL 지원한다고 함.

http://www.exerd.com/index.jsp

2. 검토 과정 기록입니다

● db designer -> db designer fork -> mysql workbench 로 upgrade 됨

그런데 mysql 전용인거 같음.

* 참고 - db designer, db designer fork

http://blog.naver.com/kimjhno1/140069354133

http://franti.blog.me/90091497501

http://www.datguri.net/7398

http://trend21c.tistory.com/1052

* 아래 두개를 보니... DB Designer가 mysql-WorkBench가 된거 같음

http://www.fabforce.net/downloads.php

http://kuimoani.tistory.com/entry/%EB%AC%B4%EB%A3%8C-DB-Modeling-Tool

● 모델링툴 내용들 정리한 블로그 글 -- 뭐가 좀 있긴한데 하나씩 링크된데 가봐도 영양가가 별로

http://www.databaseanswers.org/modelling_tools.htm

● SQL Power Architect

유료도 있는데 커뮤니티 에디션은 무료임

http://www.sqlpower.ca/page/architect

http://code.google.com/p/power-architect/

● Workbench 설명, 다운로드, 데모 동영상

http://www.mysql.com/products/workbench/

출처 : http://tastegod.co.kr/68

ERD 그리는 프로그램

2013-03-21T10:49:46+00:00

Entity-Relation Model 하고 Relational Database Management System(RDBMS)의 모델은 1:1로 매핑할 수 없는 부분이 있음에도 많은 ER 모델링 소프트웨어들이 RDBMS를 지원하는 이유는 RDBMS가 대세이기 때문이리라. 예를 들자면 ER 모델에는 상속의 개념이 있지만 순수 RDBMS에서는 이를 지원하지 않는다.

하여간 불법 소프트웨어 복제가 횡행하던 시절에 사용하던, 그리고 현재도 아마 최강이라고 생각되는 두 ER 모델 디자인 툴이 있으니 맨 처음 접해본 것은 파워디자이너의 전신인 S-Designer였다.

그 다음이 ERWin.

전반적인 설계에 중점을 둔다면 파워디자이너를 추천하고 싶고 오로지 RDBMS 모델링만 하겠다면 ERWin을 추천하겠다. 관점으로 볼 때 파워디자이너가 좀 더 거시적이기 때문이다. 요즘은 자주 행하지 않는 PFD나 DFD 설계가 가능하고 이를 바탕으로 ER 모델링이 가능하다. 반면 ERWin은 좀 더 전문화된 ER 모델링 툴이라고 볼 수 있다. 일례로 개념적 ER 모델과 실제적(Physical) ER 모델에 대한 차이를 더 명확하게 설계할 수 있는 쪽은 ERWin이다.
그런데 이 블로그는 공짜 프로그램에 대한 것이다. 둘 다 상용 소프트웨어인데... 뭐 사설이 길었던 셈이다.-_-

공짜 프로그램도 둘을 소개할 예정인데 이 둘의 차이는 파워디자이너와 ERWin의 그것에 비해 훨씬 심하다.

TOAD DataModeler Freeware
http://www.casestudio.com/enu/database_design_freeware.aspx
단지 물리적 ER 모델만 설계 가능하고 한 파일에 25개의 엔티티(테이블) 밖에 설계를 할 수 없다.

여기에 비해

Open System Architect
http://www.codebydesign.com/
개념적 ER 모델과 물리적 ER 모델 둘 다 지원이 가능하다. 처음에 봤을 때는 정말 막막하다. ERWin에서 개념적 ER 모델에서 설계를 시작해서 물리적 ER 모델로 전이를 해본 경험이 있는 사람만이 쓸 수 있는 구조를 가지고 있다. 만약 ERWin을 써봤는데 이 툴을 못쓰겠다고 한다면 당신은 ERWin을 제대로 사용해 보지 않았다는 증거이다.(약간 유예를 할 수 있는 것이 인터페이스가 난삽하긴 하다.)

극과 극 체험. 만약 급박한 문서화가 필요하다면 두꺼비(TOAD)를 선택하라. 만약에 제대로 모델링을 할 수 있다면 OSA 를 추천한다. 두가지 소프트웨어 모두 ER 모델링에 대한 개념은 있어야 한다. 하지만 OSA가 훨씬 심하다.

출처 : http://elechole.tistory.com/420

[ERD 툴] DB Modelling 툴 종류 및 비교

2013-03-21T10:48:31+00:00

안녕하세요? 오늘 화이트데이인데 선물 잘 주고 받으셨는지요?

전 선물 값도 은근히 부담되던데.. ㅋ 각설하고!!

오늘은 ERD 그릴때 사용하는 DB modelling 툴의 종류를 알아보고 각 툴들을 비교해보겠습니다.

ERD를 그릴 때 사용하는 DB모델링 툴은 상당히 많은 제품들이 있는데요..

국내에서 가장 잘 알려진 CA사의 Er-win을 비롯해, 사이베이스의 PowerDesigner, ER/Studio,

DB designer 등의 모델링 툴의 종류 및 비교를 해볼 수 있게 잘 정리해 놓은 사이트를 소개해 드릴

께요.

[ERD] DB Modelling Tools 종류 및 비교

http://www.databaseanswers.org/modelling_tools.htm

이 사이트에서는 각 모델링 툴들의 가격 및 코멘트 등을 볼 수 있고, 각 제품의 홈페이지 링크가 걸

려져 있어서 각 툴들에 자세히 알고 싶다면 링크를 통해 쉽게 보실 수 있습니다. eclipse 마켓에서

판매중인 일본 ERD툴인 Azzurri Clay 모델링 툴도 보이네요. 아쉽게도 국산 ERD툴인 DA#

과 eXERD는 나와있지 않네요.

아래 그림은 세계 데이터모델링 시장 점유율인데요. Erwin, PowerDesigner, ER/Studio를 제외한

수많은 모델링 툴들이 세계 모델링 툴의 37.9%를 차지하는 것으로 파악됩니다.

<2006 세계 데이터 모델링 툴 시장 점유율(가트너)>

또한 아래 그림은 국내 데이터모델링 시장점유율인데요. 세게 모델링 시장에 비해 기타 모델링 시장

점유율은 2%밖에 안되는 것을 볼 수 있는데요. 이것은 우리나라의 소프트웨어 생태계와도 연관이

있다고 생각이 들고, 예전 자료라 지금과는 양상이 틀릴 수도 있다는 생각이 듭니다.

<2006 국내 데이터모델링 시장점유율(가트너)>

그리고 아래 그림은 국내에서 사용하고 있는 ERD 툴들을 사용해보고 평가한 자료인데요.

Erwin을 비롯한 여러 종류의 ERD 툴 평가가 있는데 참조하시길 바랍니다~

여기까지 ERD를 그릴때 사용하는 Database Modelling툴을 알아봤는데요. 가장 많이 사용하는 툴도

좋긴 하겠지만 본인이 사용하기에 편하고, 작업환경에 적합한 툴을 쓰는게 더욱 중요한 거 같습니다.

사이트를 둘러보고 잘 선택해서 사용하시길 바랍니다.

도움이 되셨다면 한 번 꾹 눌러주세요!!

출처 : http://blog.naver.com/tomatosoft/140154655542

innodb를 myisam으로 변환 가능한가요?

2012-07-28T22:42:54+00:00

-질문

xe(1.2.1 ?)를 설치할 때 이노디비로 했는데 뭔가 오류가 생겼읍니다.

로그파일 용량초과로 아예 디비 시작이 안되더군요.

그래서 용량 확장하고(그러니까 디비 작동은 합니다.) files폴더 빼고 1.2.4로 모두 덮어 썼는데,

관리자 로그인도 안 되는군요.

그래서 디비 형식을 바꿔서 기존 데이터를 계속 사용하고 싶은데요,

innodb 형식으로 저장된 데이터를 myisam으로 바꿀 수는 없을까요?

-답변

1. xe 디비를 백업받는다. (phpMyAdmin으로 가능)

mysql -u root -p xe디비명 > 백업 디비명

2. 백업 받은 xe 디비를 보면 sql 구문이다. 이중에 ENGINE=innoDB를 ENGINE=MYISAM으로 바꾼다.

3. 기존 xe 디비를 지운다.

4. 백업 받아서 ENGINE=MyISAM으로 바꾼 디비를 import한다. (phpMyAdmin으로 가능)

mysql -u root -p xe디비명 < 백업 디비명

출처 : http://www.xpressengine.com/qna/18119130

InnoDB vs MyISAM

2012-07-28T22:41:44+00:00

DB 관련 지식이 많이 부족한 지라..알아야 할 것 이 많은데 그중에서도 스토리지 엔진 종류.

MySQL 에는 몇가지 스토리지 엔진 이 존재한다. 대표적인 것이 MyISAM 과 InnoDB.

대부분 InnoDB를 사용 한 다는데 거기에는 이유가 있을 테지요.

그 이유는 무엇일까.

* 테이블의 엔진 종류 확인

mysql> show table status like '테이블이름';

Feature	MyISAM	InnoDB
Storage Limit	256TB	64TB
트랜잭션 지원	NO	YES
Locking Level	Table	Row
Geospatial Indexing Support	YES	NO
Full Text Search Indexes	YES	NO
Clustered Indexes	NO	YES
Data Caches	NO	YES
Compressed Data	YES(Read Only)	YES(Read / Write)
Foreign Key Support	No	YES

데이터 교체같은 중요한 업무가 많이 일어나면 InnoDB(트랜잭션 지원 되니까)
select 같은 단순한 작업 만 할 경우 (규모가 작을 경우) MyISAM.

출처 : http://blog.naver.com/bal0601/150134371002

테이블 스페이스(TABLE SPACE)란?

2012-07-20T14:42:07+00:00

▣ 테이블스페이스(TABLESPACE)란 ?

- 테이블스페이스는 하나 또는 여러개의 데이터 파일로 구성되어 있는 논리적인 데이터 저장 구조 입니다.

- 테이블스페이스는 크게 시스템(SYSTEM) 테이블 스페이스와 비시스템(NON-SYSTEM) 테이블 스페이스로 구분 됩니다.

- 테이블스페이스는 사용자에게 공간을 할당할 수 있으며, 테이블스페이스 안에 저장되어 있을 데이터의 가용성을 제어할 수 있습니다.

1. 시스템 테이블 스페이스

- 오라클 데이터 베이스를 생성할 때 자동으로 생기며 오라클 데이터 베이스의 기동을 위해
꼭 필요한 테이블 스페이스 입니다.

- 모든 데이터 사전(Data Dictionary) 정보와, 저장 프로시저, 패키지, 데이터베이스
트리거등을 저장 합니다

- 유저데이타가 포함될 수 있지만 관리 효율성 면에서 포함 시키지 않습니다

2. 비 시스템 테이블 스페이스

- 롤백세그먼트, 임시세그먼트, 응용프로그렘 데이타, 그리고 응용프로그렘 인덱스를 저장 할 수 있습니다

- 공간관리를 쉽게 하기 위해서 생성 합니다.

- 유저에게 할당되는 공간 입니다.

▣ 테이블스페이스의 생성

   - 옵션절을 생략할 경우 밑줄친 옵션이 디폴트 값입니다.
   - tablespace_name : 생성할 테이블 스페이스 명
   - DATAFILE : 새로 생성하는 테이블스페이스가 사용할 데이터 파일
   - filespec : 디렉토리 경로명을 포함한 파일명
   - size : 새로 생성되는 데이터 파일의 크기

   - ONLINE/OFFLINE
       ONLINE : 새로 생성되는 테이블 스페이스를 활성화 시키며, 생성 후 바로 사용할 수 있게 함
       OFFLINE : 테이블 스페이스를 비활성화 시키며, 생성 후 바로 사용할 수 없음

- PERMANT/TEMPORARY : TEMPORARY 옵션을 사용하면 생성하는 테이블스페이스는
임시 테이블스페이스가 됩니다.

- DEFAULT STORAGE

     * INITIAL : 테이블 스페이스의 맨 첫번째 Extents의 크기
     * NEXT : 다음 Extents의 크기
     * MINEXTENTS : 생성할 Extents의 최소 값
     * MAXEXTENTS : 생성할 Extents의 최대 값
     * PCTINCREASE : Extents의 증가율, Default값은 50 입니다

테이블 스페이스 생성 예제

-- sysdba권한으로 접속을 합니다.
SQL> conn sys/manager as sysdba

-- 테이블스페이스 생성
SQL>CREATE TABLESPACE storm
         DATAFILE 'C:ORACLEORADATAapp_data.dbf' SIZE 100M
         DEFAULT STORAGE
             (INITIAL    10K
              NEXT      10K
              MINEXTENTS 2
              MAXEXTENTS 50
              PCTINCREASE 50)

아래 그림 설명은 잘 못되었습니다.
두번째 extent는 next의 원래 크기와 동일합니다.
다음부터의 NEXT는 (1+pctincrease/100)에 next의 이전크기를 곱한 크기로 설정 됩니다.
그러므로 16K는 세번째 extent의 크기가 됩니다.

10k, 10k, 16k, 24K, 36k.. 이렇게 되겠죠..

▣ 테이블스페이스의 자동 확장

▣ 생성한 데이터파일이 다 채워졌을 경우 자동으로 데이터 파일을 확장하는 방법 입니다.

▣ AUTOEXTEND 옵션을 사용 하시면 됩니다.

▣ AUTOEXTEND 옵션 사용법
   - ON 아니면 OFF
   - CREATE DATABASE, CREATE TABLESPACE, ALTER TABLESPACE에서
     사용 할 수 있습니다.

▣ AUTOEXTEND 사용 예제

SQL> ALTER TABLESPACE storm
          ADD DATAFILE 'C:ORACLEORADATAapp_data02.dbf' SIZE 200M
          AUTOEXTEND ON NEXT 10M
          MAXSIZE 500M;

storm 테이블스페이스에 200M 데이터 파일을 추가 했는데요,
이 데이터 파일의 크기인 200M를 전부 사용하게 되면 500M이 될 때까지 자동으로 10M 증가합니다.

▣ AUTOEXTEND 의 OFF

SQL> ALTER DATABASE DATAFILE ‘C:ORACLEORADATAapp_data02.dbf'
AUTOEXTEND OFF;

App_data02.dbf파일의 자동확장을 중지 시킵니다.

▣ 수동으로 데이터 파일 크기 변경

- ALTER DATABASE명령으로 데이터 파일의 크기를 변경 할 수 있습니다.

   예제)
   SQL>ALTER DATABASE DATAFILE
           'C:ORACLEORADATAapp_data02.dbf' RESIZE 300M

   RESIZE명령으로 데이터 파일의 크기를 300M로 했습니다.
   기존 데이터 파일의 크기가 300M가 넘을 경우에는 300M로 줄어들게되고,
   300M가 되지 않았을 경우에는 300M로 늘어나게 됩니다.

▣ 비 활성화(OFFLINE) 테이블 스페이스

- 오프라인 상태 테이블스페이스의 데이타에는 접근 할 수가 없습니다.
- SYSTEM 테이블스페이스와 활성화된 롤백세그먼트를 가진 모든 테이블스페이스는
오프라인 상태가 될 수 없습니다.

- 테이블스페이스를 오프라인으로 만들기

     데이타베이스가 오픈되어 있다면 데이타베이스 관리자는 SYSTEM 테이블스페이스나
     활성 롤백세그먼트나 임시세그먼트를 가진 테이블스페이스를 제외한
     어떤 테이블 스페이스든지 오프라인 상태로 만들 수 있습니다.

테이블스페이스가 오프라인상태가 됐을때 오라클 서버는 모든 관련된 모든 데이터
파일을 오프라인 상태로 만듭니다.

테이블스페이스는 세가지 모드로 오프라인 상태가 될 수 있습니다.
   * normal : 디폴드 값, 테이블스페이스의 모든 데이터 파일에 대해 체크 포인트를 수행
                     합니다.
   * immediate : CheckPoint를 수행하지 않습니다.
   * temporary : 테이블스페이스의 ONLINE데이터 파일에 대해 체크 포인트를 수행 합니다.

예제)
SQL> ALTER TABLESPACE app_data OFFLINE;

▣ 데이터 파일의 이동(ALTER DATABASE)

1) 데이터베이스를 종료 합니다.
2) 운영체제 명령을 사용하여 데이터 파일을 이동 합니다.
3) 데이터베이스를 마운트 합니다.
4) ALTER DATABASCE RENAME FILE명령을 수행하여 이름을 변경합니다.
5) 인스턴스를 시작합니다.

1) 인스턴스의 종료

C:>SQLPLUS /nolog
SQL>conn sys/manager as sysdba
SQL>shutdown immediate;

2) 운영체제 명령을 사용하여 데이터 파일을 이동

- 운영체제 명령을 이용해서 데이터 파일을 이동 시킵니다.
- UNIX에서는 mv명령을 이용해서 새로운 위치로 이동 시킵니다.

3) 데이터베이스 마운트

SQL>startup mount;

4) ALTER DATABASE명령의 수행

SQL>ALTER DATABASE RENAME FILE
'C:oracleoradatastorm.dbf' to
'D:oracleoradataoraclestorm.dbf' ;

alter database명령을 실행하면 오라클은 파일이 존재하는가를 검사합니다.
만약 이단계에서 에러가 발생하면 파일이름이 정확한지 다시 확인 하시면 됩니다.

5) 인스턴스 시작

SQL>alter database open

▣ 읽기전용(Read Only) 테이블 스페이스

- 테이블스페이스는 온라인 상태 이어야 합니다.

- 활성화된 트랜잭션은 허용되지 않습니다.(DML 작업)

- 테이블 스페이스에 활성화된 롤백 세그먼트가 포함되어 있지 않아야 합니다.

- 테이블 스페이스는 현재 온라인 백업에 포함되어 있지 않아야 합니다.

SQL>ALTER TABLESPACE app_data READ ONLY;

==>app_data 테이블 스페이스를 읽기 전용으로 변경 시킵니다.

▣ 테이블 스페이스의 삭제

◈ 데이타를 가지고 있는 테이블스페이스는 INCLUDING CONTENTS옵션 없이는 삭제할 수
없습니다.

◈ 컨트롤 파일 내에 있는 파일 포인터만 삭제됩니다. (데이터 파일은 존재)

◈ 데이타베이스 파일은 여전히 존재하므로 운영체제 레벨에서 명시적으로 삭제 되여야만 합니다.

◈ 데이터 딕셔너리의 내용이 변경 됩니다.

◈ TableSpace를 삭제 하기 전에 테이블스페이스를 오프라인 상태로 할 것을 권장 합니다.

◈ TableSpace가 일단 삭제되면 그 데이타는 데이타베이스에 더 이상 존재하지 않게 됩니다.

- INCLUDING CONTENTS: TableSpace에 Data가 이미들어있을 경우 들어있는 내용을
포함해서 모두 삭제 합니다.

- CASECADE CONSTRAINTS : Primary Key가 설정되어 있는 경우에 child 의 Foriegn Key를
삭제하고 Tablespace를 삭제 합니다.

SQL> DROP TABLESPACE app_data INCLUDING CONTENTS ;

==>app_data테이블 스페이스를 삭제 합니다.

DBA_TABBLESPACES 데이터 사전

SQL>conn sys/manager as sysdba
SQL>SELECT tablespace_name, initial_extent, max_extents, min_extlen
FROM dba_tablespaces;

DBA_DATA_FILES 데이터 사전

SQL>conn sys/manager as sysdba
SQL> SELECT file_name, tablespace_name
FROM dba_data_files;

콘트롤파일의 데이타파일 정보와 테이블스페이스 정보

SQL>conn sys/manager as sysdba
SQL> SELECT status,enabled, t.name,d.name
          FROM v$datafile d, v$tablespace t
          WHERE t.ts#=d.ts#;

STATUS    ENABLED       NAME            NAME
-------   ----------      ------------   -------------------------------------
SYSTEM READ WRITE SYSTEM       C:ORACLEORADATAORACLESYSTEM01.DBF
ONLINE    READ WRITE RBS             C:ORACLEORADATAORACLERBS01.DBF
ONLINE    READ WRITE USERS         C:ORACLEORADATAORACLEUSERS01.DBF
ONLINE    READ WRITE TEMP           C:ORACLEORADATAORACLETEMP01.DBF
ONLINE    READ WRITE TOOLS         C:ORACLEORADATAORACLETOOLS01.DBF
ONLINE    READ WRITE INDX            C:ORACLEORADATAORACLEINDX01.DBF
ONLINE    READ WRITE DRSYS         C:ORACLEORADATAORACLEDR01.DBF
ONLINE    READ WRITE STORM        C:ORACLEORADATAORACLESTORM.DBF

테이블 스페이스의데이터 파일과 테이블 스페이스의 크기 확인

DBA_DATA_FILES 데이터 사전을 이용 하면 됩니다.

SQL> COL FILE_NAME FORMAT A40
SQL> COL TABLESPACE_NAME FORMAT A15

SQL> SELECT file_name, tablespace_name, bytes, status FROM DBA_DATA_FILES;

FILE_NAME                                                    T ABLESPACE_NAME      BYTES     STATUS
-------------------------------------              ---------------    ------------    ------------
C:ORACLEORADATAORACLESYSTEM01.DBF   SYSTEM           248250368   AVAILABLE
C:ORACLEORADATAORACLERBS01.DBF          RBS                545259520    AVAILABLE
C:ORACLEORADATAORACLEUSERS01.DBF      USERS            113246208    AVAILABLE
C:ORACLEORADATAORACLETEMP01.DBF       TEMP               75497472     AVAILABLE
C:ORACLEORADATAORACLETOOLS01.DBF     TOOLS             12582912     AVAILABLE
C:ORACLEORADATAORACLEINDX01.DBF         INDX                60817408     AVAILABLE
C:ORACLEORADATAORACLEDR01.DBF            DRSYS            92274688      AVAILABLE

◎ FILE_NAME : DATAFILE의 물리적인 위치와 파일명을 알 수 있습니다.
◎ TABLESPACE_NAME : 테이블 스페이스의 이름을 알 수 있습니다.
◎ BYTES : 테이블 스페이스의 크기를 알수 있습니다.
◎ STATUS : 테이블 스페이스의 이용 가능 여부를 알 수 있습니다.

테이블 스페이스별 사용 가능한 공간의 확인

DBA_FREE_SPACE 데이터 사전

SQL> SELECT tablespace_name, SUM(bytes), MAX(bytes)
FROM DBA_FREE_SPACE
GROUP BY tablespace_name

TABLESPACE_NAME SUM(BYTES) MAX(BYTES)
---------------           ----------     ----------
DRSYS                     88268800           88268800
INDX                        60809216           60809216
RBS                       524279808          498589696
SYSTEM                      65536                 65536
TEMP                      75489280           74244096
TOOLS                     12574720           12574720
USERS                   113238016          113238016

◎ SUM을 사용한 이유는하나의 테이블 스페이스에 분산되어 있는 여유공간을 합한 것이며,
◎ MAX를 사용한 이유는 여유 공간중 가장 큰 공간의 SIZE를 의미 합니다.

데이타 화일에 대한 총 크기와 남아있는 공간, 사용한 용량, 남은 %율

DBA_FREE_SPACE, DBA_DATA_FILES 데이터 사전

SQL> COL FILE_NAME FORMAT A40
SQL> COL TABLESPACE_NAME FORMAT A30
SQL> SET LINESIZE 150
SQL> SELECT b.file_name "FILE_NAME",                                         -- DataFile Name
                 b.tablespace_name "TABLESPACE_NAME",                      -- TableSpace Name
                 b.bytes / 1024 "TOTAL SIZE(KB)",                                    -- 총 Bytes
                 ((b.bytes - sum(nvl(a.bytes,0)))) / 1024 "USED(KB)",         -- 사용한 용량
                 (sum(nvl(a.bytes,0))) / 1024 "FREE SIZE(KB)",                  -- 남은 용량
                 (sum(nvl(a.bytes,0)) / (b.bytes)) * 100 "FREE %"               -- 남은 %
         FROM   DBA_FREE_SPACE a, DBA_DATA_FILES b
         WHERE a.file_id(+) = b.file_id
         GROUP BY b.tablespace_name, b.file_name, b.bytes
         ORDER BY b.tablespace_name

FILE_NAME                                                  TABLESPACE_NAME TOTAL SIZE(KB)   USED(KB) FREE SIZE(KB)     FREE %
-------------------------------------                ---------------     --------------   -------------    ------------- ----------
C:ORACLEORADATAORACLEDR01.DBF            DRSYS                    90112            3912         86200            95.6587358
C:ORACLEORADATAORACLEINDX01.DBF         INDX                        59392                8         59384            99.9865302
C:ORACLEORADATAORACLERBS01.DBF          RBS                       532480          20488        511992            96.1523438
C:ORACLEORADATAORACLETEMP01.DBF       TEMP                       73728               8         73720             99.9891493
C:ORACLEORADATAORACLETOOLS01.DBF     TOOLS                      12288               8         12280            99.9348958
C:ORACLEORADATAORACLEUSERS01.DBF      USERS                    110592               8        110584           99.9927662

출처 : http://blog.daum.net/_blog/BlogTypeView.do?blogid=04eOW&articleno=12292551&categoryId=649222&regdt=20070817163122#ajax_history_home

SAM,DAM,VSAM,ISAM,SMS

2012-07-12T21:31:19+00:00

SAM file : Sequential Access Method file이란 의미로 메인프레임 시절에 사용되던 용어가 최근까지 이어져서 사용된 사례입니다.

즉, 레코드를 순차적으로 기록한 파일을 의미합니다.

초창기에는 Tape로 대용량 저장장치를 썼기 때문에 이때에는 순차적으로 읽고 쓰기 위한 파일 포맷이 필요했습니다.

장점은 Key 순서대로 편성되므로 속도가 빠르고 어떠한 입출력 매체에도 편성 가능하며 매체의 효율이 좋다는 것입니다.

단점은 추가, 삭제, 이동시에 자료의 추가적인 이동이 필요하다는 점이구요.
코볼에서는 주로 ISAM(Indexed Seauential Access Method) File을 많이 썼는데 이는 index로 SAM파일의 임의의 위치부터 읽을때 유용하기때문에 사용되었습니다.

DAM file: Direct Access Method file이란 의미로 SAM파일에 반대되는 개념입니다.

ISAM file : Indexed Seauential Access Method file (Indexed Sequential Access Method dataset) 으로 DD(Data Definition)에 Index area를 추가하여 표시하는 방식입니다.

추가로 DD에는 index area말고 prime area와 overflow area가 있습니다.

VSAM: Virtual Storage Access Method로 Storage에 읽고 쓰기위한 메인프레임의 인터페이스입니다.

그 외의 용어 참고

SMS: Storage Management Subsystem

CICS: Customer Information Control Systems

JCL: Job Control Language

*참고*

출처 : http://hypermin.tistory.com/45?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+hypermin+(hypermin's+blog+(carpe+diem!!)+-+a+korean+sw+developer)

고급 조인 만들기 : SELF JOIN, NATURAL JOIN, OUTER JOIN

2012-05-08T15:57:55+00:00

Introduction

12장에서 내부 조인만 다루었다. 13장에서 자체 조인(Self JOIN), 자연 조인(Natural JOIN), 외부 조인(Outer JOIN) 을 다룬다. 여러 조인을 다루는 이유는 서로 다른 테이블을 조합하여, 결과를 찾기 위해서다. 이렇게 여러 테이블을 다루다 보면, 이름을 쓰는게 헷갈리거나, 어렵거나, 귀찮을 수 있는데, 이럴때 별칭을 사용 하면 된다.

Content

1. 왜 별명(alias)을 사용하고, 어떻게 별명(alias)을 사용 하는가?

별명은 테이블 이름이 길거나, 이름 이해가 어렵거나, 특수문자를 사용 할 수 없는 환경에서 보다 쉽게 사용하기 위해서 사용 한다. 별명은 계산 필드, 칼럼(열), 테이블 이름에 붙일 수 있다.

사용 방법은 바꾸고자 하는 이름 뒤에 AS 를 붙이고, 별명을 기입하면 된다.(오라클에선 AS 없이 그냥 한칸 띄우고 별명을 지어 주면 된다.) 즉, 다음 예와 같다.

SELECT
    vend_id AS vi, 
    vend_name AS vn,    
    vend_address AS va 
FROM
    Vendors AS ven

관련 링크

별명이 끝났으니, 이제 각각의 조인들에 대해서 알아 보자.

2. 자체 조인 - Self JOIN

2-1 무엇을 "자체 조인 - Self JOIN"이라고 하는가?

테이블 A 가 있다고 치면, 테이블 A가 테이블 A를 참조 하는, 즉, 자기 자신을 참조 하는 조인을 Self JOIN 라고 한다. 보통 테이블에 한 컴럼이 자신에게 있는 다른 레코드를 참조할 경우 쓰인다.

2-2 어떻게 "자체 조인 - Self JOIN"을 사용 하는가?

SELECT
    c1.cust_id, c1.cust_name, c1.cust_contact 
FROM
    Customers AS c1, Customers AS c2 
WHERE
    c1.cust_name = c2.cust_name 
    AND c2.cust_contact = 'Jim Jones';

해석

출력

본능적으로 알 수 있으니, 별도의 설명이 필요 없다.

관련 링크

3. 자연 조인 - Natural JOIN

3-1. 무엇을 "자연 조인 - Natural JOIN" 이라고 하는가?

테이블 조인 유형 중 한가지 이다. 테이블 간 중복된 열이 있다면, 한개만 표시하는 JOIN 을 뜻한다. 그렇다고 Natural JOIN 이 스스로 걸러낸다는 것을 의미하지는 않는다. 이것은 질의를 만드는 사람의 손으로 걸러내야 한다는 의미이다. (실제로 PostgreSQL 에서 해 보니, 중복된 열이라 할지라도, 지정해 주면 출력이 되더라. 결국 사람의 손을 거쳐야 하는 것.)

곰곰히 생각해 보면, "자연 조인 - Natural JOIN" 을 따로 구분 짓지는 않을 것 같다. 왜냐하면, 인간이 가진 손으로 기입하는 것이기 때문이다. 이 의미는 "내부 조인 - INNER JOIN" 에 중복된 열을 제거 한 것뿐 이다. "자연 조인 - Natural JOIN"을 구분 한다 해도, 얻게 되는 이점이 무엇인가? 전혀 없다. 나는 이렇게 본다.

3-2. 어떻게 "자연 조인 - Natural JOIN" 을 사용 하는가?

SELECT   
    C.*, O.order_num, O.order_date, OI.prod_id, 
    OI.quantity, OI.item_price 
FROM
    Customers AS C, Orders AS O, OrderItems AS OI 
WHERE
    C.cust_id = O.cust_id 
    AND OI.order_num = O.order_num 
    AND prod_id = 'RGAN01';

해석

출력

관련 링크

http://jongrak.textcube.com/70

4. 외부 조인 - OUTER JOIN

4-1. 무엇을 "외부 조인 - OUTER JOIN" 이라고 하는가?

여러 JOIN 중 한 조인 형태이며, 크게 내부 조인과 외부 조인으로 나뉜다. 내부 조인은 엮을 대상이 있을 때만, 엮여 지지만, 외부 조인은 엮일 대상이 없다고 해도 엮인다. 이것이 차이다. 이러한 차이점 때문에 외부 조인은 기준이 될 테이블을 정해 주어야 한다. 기준이 된 테이블을 정해 준다는 것은 엮이는게 없더라도, 기본적으로 보여질 테이블을 정해 준다는 것을 의미한다.

그러므로 왼쪽을 기준으로 정한 외부 조인을 LEFT OUTER JOIN 이라고 하며, 오른쪽을 기준으로 정한 외부 조인을 RIGHT OUTER JOIN 이라고 한다. 이때 왼쪽과 오른쪽을 결정하는 기준은 JOIN 절 이다. JOIN 을 기준으로 왼쪽 과 오른쪽으로 나뉜다.

이렇게 왼쪽과 오른쪽을 나눈것 외에 둘 다 포함하는 조인이 있는데, 이를 FULL OUTER JOIN 이라고 한다. 이는 엮일 데이터가 있건 없건 모든 테이블을 보겠다는 의미이다. FULL JOIN 은 각 DBMS 마다 지원 여부를 확인해 봐야 한다. (PostgreSQL 은 된다.)

4-2. 어떻게 "외부 조인 - OUTER JOIN" 을 사용 하는가?

모든 예를 다 찍기 어려우므로 사진과 링크로 대체 한다.

LEFT OUTER JOIN 해석

LEFT OUTER JOIN 출력

RIGHT OUTER JOIN 해석

RIGHT OUTER JOIN 출력

FULL OUTER JOIN 해석

FULL OUTER JOIN 출력

쿼리의 결합 : UNION 으로 쿼리 결합하기

2012-05-08T15:56:46+00:00

Introduction

쿼리 결합은 대개 "서로 다른 테이블을 참조하기 위해서거나, 테이블 하나에서 여러 조건을 찾기 위해서" 사용 한다. 이번 장은 UNION을 이용한 쿼리 결합을 다룬다.

Content

1. 무엇을 쿼리 결합 이라 하는가?

쿼리가 질의 라는 것은 안다. 질의 라는 것은 DB에 질문을 하는 것이라는 것도 안다. 그렇다면, 쿼리 결합은 무엇을 의미할까? 이것은 쿼리 하나에 쿼리가 여러개 들어가 하나의 쿼리가 된 형태를 뜻한다.

2. 왜 쿼리 결합을 이용하는가?

쿼리 결합은 다른 테이블 참조나 테이블 하나에 여러 조건을 확인해야 할 때 많이 사용 한다. 쿼리 결합은 서브 쿼리를 이용한 결합과 UNION 을 통한 결합이 있으며, 이번장에선 UNION 을 통한 결합을 배운다.

3. 어떻게 UNION을 사용하는가?

쉽다. SELECT 문을 두개 준비하고, 그 사이에 UNION을 넣어주면 된다. 다음 코드를 보자

SELECT 
    cust_name, cust_contact, cust_email 
FROM 
    Customers 
WHERE 
    cust_state IN ('IL', 'IN', 'MI') 
UNION
SELECT 
    cust_name, cust_contact, cust_email 
FROM 
    Customers 
WHERE 
    cust_name = 'Fun4All';

해석

출력

4. 주의 사항이 UNION 에 있는가?

테이블이 두개 이상일 때, UNION을 사용 할 수 있다.
UNION으로 엮인 쿼리는 동일한 열을 선택해야 한다. 그렇다고 같은 순서로 나열해야 한다는 것을 의미하지는 않는다.
열 데이터 형식은 서로 호환되어야 한다.
기본적으로 UNION 을 사용 하면, 중복된 행은 출력하지 안하지 않는다. 이때 중복된 행이란 것은 UNION 으로 지정한 테이블 간 동일한 행을 의미한다. 만약 중복된 행이라도 출력해야 한다면 UNION ALL 을 사용 하면 된다.

5. 다른 사항이 더 있는가?

UNION 과 WHERE 절에 여러 조건을 엮는 것은 서로 비슷하다. 그렇지만 UNION ALL 을 사용하면 다르다.
UNION 으로 결합 시킨 쿼리에 대해서 정렬 하고 싶다면, 제일 마지막 쿼리에 ORDER BY를 붙이면 된다.

관련 링크

Digression

별거 없음. 단지 UNION 이란 것이 있고, UNION ALL 이 존재 한다는 것을 알았을 뿐

출처 : http://ikpil.com/1104

ERD 를 엑셀 EXCEL 로 변환

2012-04-23T15:13:17+00:00

1) 메뉴에서 - Tool > Data Browser

2) Data Browser 창에서 File - New ERWin Report로 들어간다.

3) 문서를 보고 따라한다.

4) 막판에 export 할때는

메뉴에서 File > Export 들어간다.

- Export : csv

- Presentation : Tabular with duplicates

- Export to : File

출처 : http://naragu.tistory.com/entry/ERD-%EB%A5%BC-%EC%97%91%EC%85%80-EXCEL-%EB%A1%9C-%EB%B3%80%ED%99%98

관계형 데이터 모델(Relational Data Model) 의 설계

2012-02-17T13:02:15+00:00

참고 : Join에 관해 글을 올리다 보니 관계형 데이터 모델에 대한 설명이 우선 되어야 할 것 같아 이글을 올립니다.

현 재 상용 데이터베이스 제품은 대다수가 채용하고 있는 관계형 데이터 모델의 개념이 처음 언급된 것은 1970년대 E. F. Codd 박사의 "A Relational Model of Data for Large Shared Data Backs"라는 논문이었다. 그 당시, 사용되던 데이터 모델로는 계층형 데이터 모델, 네트워크형 데이터 모델이 있었지만 관계형 데이터 모델의 구조가 기존 데이터 모델에 비해 좀 더 유연하여 실세계를 좀 더 현실감 있게 반영할 수 있었기 때문에 많은 데이터베이스 시스템에 구현되었으며 이로 인하여 관계형 데이터 모델을 지원하는 관계형 데이터베이스 관리 시스템(RDBMS) 제품들이 데이터베이스 시장을 지배하게 되었다.

관계형 데이터 모델은 기본적으로 다음과 같이 핵심적인 3개의 구성요소로 구성되어 있으며, 실세계의 모든 업무체계를 아래의 3가지로 모두 표현할 수 있다는 개념이다.

1. 개체(Entity) : 시스템화하고자 하는 사건, 사물

2. 관계(Relationship) : 개체간, 속성간의 연관성

3. 속성(Attribute) : 개체, 관계성의 성질을 나타내는 더 이상 쪼갤 수 없는 정보의 단위

위 에서 표현된 각 구성요소들이 결국에는 관계형 데이터베이스에 구현된다. 즉, 개체는 테이블이라는 3차원의 구조로 표현되며, 관계는 외래키(FK :Foreign Key), 속성은 테이블 내의 컬럼으로 구축된다. 그러므로, 데이터베이스 시스템을 구축하기에 앞서 모델링하고자 하는 실세계를 개체, 관계, 속성으로 명확히 정의할 필요가 있다.

관계형 데이터베이스의 정의

관계형 데이터 모델을 전산화하여 논리적으로 구축해 놓은 것이 관계형 데이터베이스이다.

관계형 데이터베이스는 정보를 저장하기 위하여 아래와 같은 2차원의 테이블 구조를 사용한다. 예를 들어, 회사의 모든 사원 정보를 데이터베이스에 저장하고자 한다면 다음과 같은 사원 테이블이 필요하게 되는데, 이는 관계형 모델로 정의된 사원 개체가 관계형 데이터베이스 내에서 사원 테이블로 구현된 것이다.

관계형 데이터베이스의 용어

관계형 데이터베이스에서 모든 데이터는 2차원 테이블에 저장된다. 다음과 같이 사원 정보가 입력되어 있는 사원 테이블에서 각 번호가 의미하는 것은 다음과 같다.

① 행(Row) : 특정한 한 명의 사원을 표현하기 위해 필요한 모든 데이터이다. 테이블 내의 각 행은 반드시 기본키에 희하여 식별 가능해야 하며, 기본키의 값은 절대 중복되면 안된다. 테이블내의 행들은 임의 순서로 저장되어 있으나, 검색시 정렬이 가능하다.

② 기본키(PK :Primary Key) : 사번(EMPNO) 컬럼은 절대 중복 될 수 없으며, 값이 반드시 지정되어야 한다. 그러므로, 테이블내의 모든 행들은 기본키에 의해 식별될 수 있다.

③ 컬럼(Column) :급여(SAL) 컬럼은 기본키가 아니므로 특별한 제약조건이 지정되지 않는 한, 값을 지정하지 않아도 되며 값이 중복되어도 상관 없다.

④ 외래키(FK :Foreign Key) : 외래키는 테이블간의 관계를 정의하는 컬럼이다. 부서코드(DEPTNO) 컬럼은 외래키로서 다른 테이블의 기본키 또는 고유(Unique) 제약조건이 걸려 있는 고유키 컬럼을 참조한다. 여기서는 부서(DEPT) 테이블의 부서코드(DEPTNO)컬럼을 참조하고 있다.

⑤ 필드(Field) : 행과 컬럼이 교차하는 지점을 필드(Field)라고 정의한다.

⑥ 널(Null) : 필드에 값이 지정되어 있지 않는 경우를 일반적으로 NULL 값을 갖는다고 표현한다.

NULL 값 자체도 다음의 두 가지 의미를 갖는데, "값이 아직 지정되지 않았다(Undefine)"는 의미와

"값을 아직 모른다(Unknown)"는 의미이다. 절대, 0(Zero)이나 공백(Space)과는 의미가 다르므로 혼돈해서는 안 된다.

기본키(PK)와 외래키(FK)

ERD 에서 표현된 개체는 추후 테이블로, 속성은 컬럼으로, 관계는 외래키 또는 테이블로 구현된다고 기술한 바 있다. 여기서는 관계형 데이터베이스에서 아주 중요하게 다루어지는 기본키(PK :Primary Key)와 외래키(FK :Foreign Key)에 대하여 살펴본다.
기본키는 다음 그림과 같이 테이블내의 각 행을 유일하게 식별 할 수 있는 컬럼이며 외래키는 자신 또는 다른 테이블의 기본키 또는 고유키를 참조하는 컬럼이다.

예 를 들어, 위 그림과 같이 관계형 데이터베이스에 부서 테이블과 사원 테이블이 구축되어 있다고 가정하자. 부서 테이블에는 부서 정보가 입력되어 있으며, 사원 테이블에는 사원들의 정보가 각각 입력되어 있다. 부서 테이블내에서 각각의 부서 정보를 유일하게 식별할 수 있는 컬럼을 기본키로 설정하게 되는데, 이 경우는 부서코드(DEPTNO)를 기본키로 설정했다. 그러나, 부서 테이블내에 입력된 실제 데이터를 보면 부서코드(DEPTNO) 컬럼 외에 부서명(DNAME), 위치(LOG) 컬럼 모두 기본키가 될 자격(모든 값이 고유하고 NULL 값이 존재하지 않음)은 충분히 있지만 부서명(DNAME)이나 위치(LOG) 컬럼은 추후 NULL값이 입력되거나 데이터 값이 중복 입력될 소지가 충분히 있으므로 기본키의 후보로서 적절치 않음을 알 수 있을 뿐 아니라 기본키는 해당 테이블의 대표 속성으로서 나름대로 의미를 가지기 때문에 부서코드(DEPTNO)가 기본키로서 적절함을 알 수 있다. 부서 테이블 또한 동일한 맥락에서 사번(DEPTNO)이 기본키로 지정되었음을 확인 할 수 있다.

외래키는 테이블간의 관계를 정의하는 컬럼으로 위 그림에서는 사원들의 소속부서 정보를 관리하고자 설정된 것이다. 만약, 사원의 소속부서 정보를 궅이 데이터베이스에 구축하여 관리하고자 할 필요가 없다면 이러한 관계 설정은 불필요한 것이 된다. 여기서는 부서 테이블의 기본키 컬럼을 사원 테이블의 외래키 컬럼으로 추가시켜 부서와 사원간의 관계를 상호 참조 할 수 있도록 지정하였다. 이로써 각각의 사원들이 어느 부서에 소속되어 있는지, 각각의 부서에 소속된 직원들은 누구인지 등의 정보를 검색할 수 있게 된다.

데이터 모델링의 4단계

데이터 모델링은 다음 그림과 같이 4단계에 걸쳐서 진행되며, 각 단계별 수행 작업과 산출물은 다음과 같다.

1) 요구형성 및 분석

데 이터베이스 시스템 구축을 위한 요구사항을 취합하여 분석한 후, 업무처리 규정을 도출하는 단계이다. 이 단계에서 필요한 자료는 업무분장표, 현재업무흐름도, 입출력 활용 장표, 인터뷰 내용, 현 시스템분석도 등이 요구되며 이를 기반으로 최종 업무처리 규정이 산출되게 된다.

예) 업무처리 규정

* 각각의 회사원은 한 부서에 소속된다.

* 회사원에 관해서는 사번, 이름, 주소 등의 정보가 유지된다.

* 부서에 관해서는 부서코드, 부서명에 대한 정보가 유지된다.

2) 개념적 설계

전 단계에서 산출된 업무처리규정을 이용하여 중심 데이터인 개체를 도출하고 개체 관계도(ERD)를 작성하는 과정이다. 데이터베이스를 처음 다루는 입문자에게 개체라는 개념이 상당히 어렵게 느껴질 수도 있으나 관계형 데이터 모델이 최종적으로 관계형 데이터베이스에 구축될 때, 개체가 테이블로 변환된다는 생각을 하면 쉽게 개념을 잡을 수 있을 것이다.

3) 논리적 설계

전 단계에서 산출된 ERD로부터 엔티티를 테이블, 속성을 컬럼, 관계를 테이블 또는 속성으로 적절히 변화하는 단계이다. 이 과정에서는 정규화라는 과정이 필수적으로 선행된다. 정규화란 자료의 손실이나 불필요한 정보의 도입 없이 데이터의 일관성, 최소한의 데이터 중복, 최대의 데이터 안정성 확보를 위한 안정적 자료구조로 변환하는 기번을 의미하는데, 쉽게 말하자면 동일한 테이블내에 같은 데이터들이 중복해서 입력이 되면 데이터가 입력, 수정, 삭제되는 조작 과정에서 여러 가지 이상현상이 발생하기 때문에 정규화는 이러한 일들이 발생되지 않도록 데이터 중복을 최소화하여 테이블을 여러 개로 분리시키는 일련의 과정을 말한다.

예) 테이블로의 변환 예

부서 테이블(부서코드(PK), 부서명, 위치)

사원 테이블(사번(PK), 이름, 주소, 부서코드(FK))

4) 물리적 설계

전 단계에서 변환된 관계형 테이블을 실제 데이터베이스 서버에 구현 할 수 있도록 테이블 차트를 작성한다. 또한, 이 단계에서는 서버의 디스크 구조에 따라 데이터 파일의 배치, 인덱스 최적 설계, 트랜잭션 처리 알고리즘 등을 결정하여 구현된 데이터베이스가 최대한의 성능을 발휘할 수 있도록 구현하는 단계이다.

ERD(Entity - Relationship Diagram)

ERD는 데이터베이스 모델링의 4단계 중에서 개념적 설계의 산출몰로서 도출되어야 하는 결과이다.

ERD 는 수작업으로 작성할 수도 있으나, 최근의 데이터베이스들은 엄청난 수의 테이블을 포함하고 있기 때문에 ERD를 직접 손으로 작성한다는 것은 거의 불가능하다. 이를 위해서 상용 ERD작성 툴을 많이 사용하는데, 그 대표적인 소프트웨어가 CA의 Erwin이라는 프로그램이다.

Erwin에서 관계형 데이터 모델의 기본이 되는 3개의 구성요소는 다음과 같이 표현된다.

■ 개체(Entity)

Erwin에서 개체는 사각형으로 표현되며, 사작형의 상단에 개체의 이름이 기술된다.

ERD 에서 관계를 표시하는 방법은 관계의 카디널리티(Cardinality)에 따라 다르게 표현된다. 여기서, 카디널리티란 각 관계자에서 참여자의 수를 표현하는 것을 말하는데 쉽게 설명하자면 한개 부서에 한명의 사원만이 배정되는 관계는 1:1이 되며, 한개 부서에 한명이상의 사원이 배정되면 1:M(Many)이 되는 것이다. M:M의 경우는 한 개의 부서에 한명이상의 사원이 배정되며, 한명의 사원이 여러 부서에 동시에 소속될 수 있다는 의미가 된다. 예를 들면, 인사과에 홍길동, 콩쥐, 팥쥐 등 여러 명의 사원이 배정되는 관계라면 1:M, 인사과에 홍길동, 콩쥐 팥쥐등 여러명의 사원이 배정되는 동시에 홍길동이 인사과, 총무과, 홍보과 등의 여러 부서에 소속되면 M:M 관계가 되는 것이다. 그러나. M:M 관계의 경우는 논리적인 테이블로 구현할 수 없기 때문에 논리적 설계과정에서 M:M 관계를 테이블로 변환하여 두 개의 1:M 관계로 반드시 분해 하여야만 한다는 점을 잊으면 안 된다.

그러면 Erwin에서 이러한 카디널리티가 어떻게 표현되는지 살펴보자. Erwin에서 카디널리티가 1로 표현되는 엔티티 쪽은 실선으로 그리고 M으로 표현되는 엔티티 쪽은 까마귀 밭(Crow's foot)과 같이 그린다. 위와 같은 경우는 한 개의 부서에 여러 명의 사원이 소속되는 관계를 표현한 것임을 알 수 있다.

또한, 관계로 표현된 점선의 양단에 ○ 기호를 확인 할 수 있는데, 이 기호는 선택도를 표시한 것이다. 즉, ○이 붙어 있는 경우를 선택(Optional), 그렇지 않은 경우를 필수(Mandatory)라고 표현하는데, 사원 엔티티 쪽에 ○이 붙어 있는 경우는 각 부서에 사원이 한명도 배정되지 않을 수도 있다는 의미이고 반대로, 부서 엔티티 쪽에 ○이 붙어 있는 경우는 사원 중에서 어떠한 부서에도 소속되지 않은 사원이 있을 수 있음을 의미한다.

카디널리티와 선택도가 이해되었다면 다음과 같은 ERD를 각각 분석해보도록 하자, ERD를 읽을 때는 왼쪽엔티티에서 오른쪽 엔티티로 한번 읽고, 그 반대로 한번 읽는다.

마 지막으로 카디널리티와 선택도 이외에 한가지 더 알아두어야 할 것이 있는데 관계의 식별성이다. 지금까지 Erwin에서 표현되는 관계는 점선이었는데, 이 점선을 비식별(Non-Identifying) 관계라고 부른다. 비식별 관계로 표시되는 경우는 카디널리티가 1쪽인 엔티티의 기본키 속성이 M쪽인 엔티티의 외래키로 구현되는 과정에서 일반 속성으로 추가된다는 의미이다. 즉, 아래 그림과 같이 부서 엔티티의 기본키인 부서코드 속성이 사원 엔티티의 외래키로 생성되며 일반 속성으로 추가된다는 의미이다.

반 면에 다음과 같이 실선으로 표시되는 관계를 식별(Identitying) 관계라고 부르는데, 이와 같은 경우, 카디널리티가 1쪽인 엔티티의 기본키 속성이 M쪽인 사원 엔티티의 외래키로 구현되는 과정에서 사원의 기본키 속성으로 추가된다는 의미이다. 즉, 아래 그림과 같이 부서 엔티티의 기본키인 부서코드 속성이 사원 엔티티의 외래키로 생성되며 기본키 속성으로 추가된다는 의미이다.

식 별/비식별 관계는 두개의 엔틴티간에서는 큰 의미가 없기 때문에 다음과 같은 세 개의 엔티티로 구성된 식별/비식별 관계를 살펴보도록 하자. 먼저, 지역 엔티티, 부서 엔티티, 사원 엔티티로 수성되어 있으며 각각 1:M 관계로 설정되었다. 즉, 지역 엔티티의 기본키인 지역코드가 부서 엔티티의 외래키(일반 속성)로 추가되었고, 부서 엔티티의 기본키인 부서코드가 사원 엔티티의 외래키(일반 속성)로 추가되었음을 확인할 수 있다. 이러한 ERD에서 사원의 이름을 검색조건으로 지역명을 검색하고자 한다면 3개의 엔티티를 모두 조인(Join) 하여야 한다.

반 면, 아래와 같이 지역 엔티티와 부서 엔티티간의 식별관계로 수성된 경우는 사원 엔티티에 지역 엔티티와 부서 엔티티의 기본키가 각각 포함되므로 지역 엔티티와 사원 엔티티가 직접 조인(Join)이 가능해지기 때문에 위의 경우보다 수행성능이 항상될 것임을 예상할 수 있다.

출처 : http://oksoft.tistory.com/26

phpMyAdmin 설치 하는 방법

2007-02-21T19:20:19+00:00

phpMyAdmin 은 MySQL 디비를 웹에서 접근하고 관리할 수 있는 PHP로 된 무료 프로그램입니다.

데이타베이스를 백업하거나 자료를 수정하는 등 직접 데이타 베이스를 다룰 일이 있을 때 사용하면 편리 합니다.

이번에 웹 호스팅을 옮기면서 약 5년만에 새 버전을 설치 했는데, config 바꾸는 방법이 바뀌서 간단히 정리를 했습니다.

새 버전은 로그인을 하면서 인코딩을 선택할 수 있게 되어 있더군요.

phpMyAdmin 설치 하는 방법

1. PHP 프로그램을 다운로드 받습니다.
최신 버전은 http://www.phpmyadmin.net/home_page/downloads.php 에서 다운로드 할 수 있습니다.

2. 압축을 푼 후에 libraries 폴더 안의 config.default.php 을 상위 폴더로 복사 한 후 이름을 config.inc.php 로 변경합니다.

3. config.inc.php 을 열어서 다음의 사항을 수정합니다.

$cfg[’blowfish_secret’] = ”; -> $cfg[’blowfish_secret’] = ‘cookie‘;
$cfg[’Servers’][$i][’auth_type’] = ‘config’; -> $cfg[’Servers’][$i][’auth_type’] = ‘cookie‘;

4. phpMyAdmin 디렉토리 파일을 업로드 합니다.

5. 올린 계정에 접속하면 다음과 같은 화면이 나옵니다.

웹 호스팅할 때 받은 mysql 아이디와 패스워드를 입력하면 데이타베이스를 볼 수 있는 화면으로 로그인 하게 됩니다.

구문타입	속성 (결과객체,파라미터객체지정)	사용하는 경우
<select>	id,parameterClass,resultClass,parameterMap,resultMap	데이터조회
<insert>	id,parameterMap,resultMap	데이터입력
<update>	id,parameterMap,resultMap	데이터수정
<delete>	id,parameterMap,resultMap	데이터삭제