이미지 검색을 사용해 보세요
검색창 이전화면 이전화면
최근 검색어
인기 검색어

소득공제 강력추천
Microsoft SQL Server 2000 개발자용
CD 1
정원혁
대림 2001.01.31.
베스트
IT 모바일 top100 4주
가격
20,000
10 18,000
YES포인트?
1,000원 (5%)
5만원 이상 구매 시 2천원 추가 적립
결제혜택
카드/간편결제 혜택을 확인하세요

이미 소장하고 있다면 판매해 보세요.

  •  해외배송 가능?
  •  문화비소득공제 가능

책소개

7월 이벤트 안내

목차

1. SQL Server 2000을 시작하며

2. MS-SQL Server 2000의 설치
설치 전의 고려 사항
Setup을 시작하자
Setup을 마친 후 - 검사
서비스 시작과 중지
접속하기
쿼리 분석기 기초 사용법
엔터프라이즈 관리자(EM) 기초 사용법
일반적인 문제들과 해결책
SQL 서버 삭제하기
멀티 인스턴스
업그레이드
따라하기

3. SELECT 문 기초
온라인 설명서 사용하기
따라하기
기본적인 SELECT 문
컬럼에 대한 처리
따라하기
변수
자료형(data type)
SELECT에서의 자료형 바꾸기
행에 대한 처리
따라하기

4. R-DBMS 입문
관계형 데이터베이스
관계형 데이터베이스의 특성
데이터 모델링
CASE TOOL과 ER-Diagram
따라하기

5. SELECT 문(2) 요약 정보와 조인
요약 정보 처리
하위 질의(subquery)
IN / EXISTS
상관관계의 하위 질의(Correlated subquery)
SELECT INTO
UNION
따라하기

6. 테이블 만들기
데이터베이스 개체
테이블 만들기
테이블 수정하기
따라하기

7. 데이터 수정
INSERT
DELETE
UPDATE

8. 테이블 만들기-고급
데이터 무결성(Data Integrity)
NULL
기본 키
유일 제약 (UNIQUE)
IDENTITY
DEFAULT 제약과 절차적 방법의 DEFAULT
RULE과 CHECK 제약
참조 키
제약 중지시키기/ 기존 데이터 검사하지 않기(Disable / Defer)
무결성 강화 객체들을 사용할 때 고려할 사항
따라하기

9. SQL문 고급
흐름 제어문
계산 함수 다시 보기
일괄 처리(Batch)와 스크립트
따라하기

10. 색인(1)
색인의 기본 개념
색인의 종류
색인 시뮬레이션
쿼리 분석기 옵션들(Plan 보기)
따라하기

11. 색인(2)
색인 더 깊이 알기
DBCC (DataBase Consistency Checker)
따라하기

12.트랜잭션(1)
트랜잭션
트랜잭션과 잠금
따라하기

13. 트랜잭션(2)
트랜잭션 고립화 수준(Transaction Isolation Level)
트랜잭션 관련 옵션
잠금과 성능
트랜잭션과 분산 데이터
따라하기

14. 뷰
뷰(view) 개념 잡기
뷰 만들기/ 고치기/ 지우기
뷰에 대한 정보 얻기
뷰에 사용할 수 없는 것
시스템 뷰
인덱스된 뷰(Indexed View)
분할된 뷰(Partitioned View)
따라하기

15. 저장 프로시저
저장 프로시저
만들기 / 고치기 / 지우기
프로시저 종류
실행시키기
따라하기

16. 트리거
트리거 정의
만들기/ 고치기/ 지우기
따라하기
트리거 사용 하기
트리거 더 깊이 알기
따라하기

17. 사용자 정의 함수
개념 잡기
만들기/ 고치기 / 지우기
실행하기
간단한 예
정보 얻기 / 암호화
WITH SCHEMABINDING
의존성
만들거나 고칠 때 고려사항
함수의 종류
따라하기

18. 커서
커서(CURSOR) 정의
커서의 종류
커서 기본 문법
커서 만들고 사용하기
따라하기
커서 vs 쿼리
따라하기

19. 전체 텍스트 색인(Full Text Index)
전체 텍스트 색인 개념 잡기
전체 텍스트를 만드는 절차
전체 텍스트 질의
따라하기

저자 소개 1

필라넷(http://www.feelanet.com) 이사이자, DB사업부장이고 SQL Server 아카데미(http://www.sqlacademy.com) 본부장을 겸임하고 있다. 마이크로소프트 공인 강사(MCT)이며 MCDBA이다. 비영리 단체로 SQL Server 전문가 모임인 SQL Specialist의 리더이며, PASS(Professional Association for SQL Server, http://sqlpass.org) 한국 지부 지부장이다. 트라이콤 교육센터에서 주로 강의를 하고 있고, 이전에 마이크로소프트에서 기술지원 엔지니어, 컨설턴트로 일했다. 이랜드에서
필라넷(http://www.feelanet.com) 이사이자, DB사업부장이고 SQL Server 아카데미(http://www.sqlacademy.com) 본부장을 겸임하고 있다. 마이크로소프트 공인 강사(MCT)이며 MCDBA이다. 비영리 단체로 SQL Server 전문가 모임인 SQL Specialist의 리더이며, PASS(Professional Association for SQL Server, http://sqlpass.org) 한국 지부 지부장이다. 트라이콤 교육센터에서 주로 강의를 하고 있고, 이전에 마이크로소프트에서 기술지원 엔지니어, 컨설턴트로 일했다. 이랜드에서 개발자와 DBA로 일하기도 했다. 또, GTU (www.gtu.co.kr)에서 온라인 강의를 진행했다. 마이크로소프트 공인강사였으며 시스템 엔지니어 (MCSE, MCT)이다. 현재 주로 웹타임(WWW.WTIME.NET) (전, TECH DATA CONSULTING 또는 IT CONSULTING & SERVICES)의 SQL 서버 전임 강사로 일하고 있으며, 강의가 없는 틈을 이용하여 현업 컨설팅을 하고 있다. 또, ISTUDY4U(HTTP://ISTUDY4U.COM)에서 온라인 강좌도 하고 있다. 그는 97이후 계속 여러 차례 TECH ED, 윈도우 월드 등에서 강의를 했으며 현재는 마이크로소프트 토요 세미나 강사로 자신의 지식을 전달하고 있다. 아는 것과 가르치는 것이 일치하기 힘든데 그의 강의를 들은 많은 수강생들은 그의 강의에 매료 될 정도로 강의를 통해 가르치는 능력이 탁월하다. 뿐만 아니라 많은 저서, 번역서, 기고를 통해 그의 지식을 전달해 왔으며 마이크로소프트의 여러 기술 백서를 번역하고 감수했다. 이 전에는 다우 교육원 SQL 서버 전임 강사였던 그는 강사 생활 시작 전에 마이크로소프트 기술지원 부서와 컨설팅 부서에서 2년여 기간 동안 엔지니어와 컨설턴트로 일했다. 또 이랜드 정보산업에서 5년여 기간 동안, 현업 업무를 하였다. 이 기간동안 그는 NOVELL NETWARE 관리자, 바코드 시스템 개발, 영업 시스템 개발, UNIX 관리자, DB 관리자로 일했으며 부족함을 느끼자 바로 사표를 내고 비트 컴퓨터의 비트교육센터에 입학하여 XE (C / UNIX) 과정을 14기로 공부하였으며 이 기간동안 C-ISAM LIBRARY 프로젝트 / WINDOWS C++ 프로그래밍 프로젝트를 했다.

품목정보

발행일
2001년 01월 31일
쪽수, 무게, 크기
580쪽 | 1215g | 188*257*35mm
ISBN13
9788972805830

책 속으로

필자가 여러 회사를 다니며 살펴 본 바로는 대부분이 기본 키를 클러스터 색인으로 설정해 놓고 있었다. 또한 강의 중에 확인해 보아도, 대부분이 당연히 클러스터 색인이 기본 키이어야 한다고 생각하고 있었다. 과연 그럴까?

그렇지 않다. 클러스터 색인은 테이블마다 하나 밖에 존재할 수 없으며, 속도(Performance)에도 많은 영향을 미치는 요소이므로 기본 키를 무조건 클러스터 색인으로 설정하는 것은 옳지 않다. 일반적으로는 정렬되어 있어야 더 좋은 속도를 낼 수 있는 컬럼을 클러스터 색인으로 만드는 것이 가장 좋다.

예를 들어 사원 번호가 기본 키이며 CL인 경우를 흔히 보게 되는데, 업무 상 사원 번호를 "10번부터 100번까지"라는 식으로 범위를 주어 찾을 때가 얼마나 많을까? 그 보다는 오히려 이름순으로 성이 "김"씨인 사람을 찾을 때나, 부서가 "영업"인 사람을 찾을 때가 더 많을 것이다. 그렇다면 오히려 이름이나 부서에 대해 클러스터 색인을 설정하는 것이 옳다.

앞서 말한 대로 이것은 전적으로 업무의 성격에 따라 얼마든지 달라질 수 있다. 여러분 회사의 클러스터 색인을 다시 한번 점검해 보자.

결론적으로, 클러스터 색인은 한 테이블에 하나만 존재할 수 있으며, 범위를 주고 값을 찾을 때에 매우 도움이 된다. 흔히, Primary Key는 무조건 클러스터 색인을 만드는데 이것은 옳지 않다. 반드시 색인을 만들기 전과 후의 속도를 비교해 보고 결정해야 한다. 그리고 7.0부터는 앞서 언급한 바와 같이 넌 클러스터 색인이 클러스터 색인의 키 값을 포인터로 갖고 있기 때문에 클러스터 색인의 키 값이 20바이트 이상 된다면 성능은 형편 없을 것이 불 보듯 뻔하다. 아무리 범위를 주고 찾는 것이라고 하더라도 키 값이 크다면 클러스터 색인을 사용하지 말아야 한다.

--- p.334~335

전형적으로 전산에서는 데이터를 처리할 때 입력과 출력에 초점을 둔다. 예를 들면, 무엇이 입력되면 무엇이 출력되는가에 대해서 관심을 갖는 것이다. 그 결과를 나타내기 위해서 필요한 과정을 구현하는 것이 바로 전산에서 할 일이라고 생각해 왔다. 그런데, 이런 식으로 처리하는데 약간의 문제가 생기기 시작했다. 업무의 흐름이 정적으로, 또는 자주 바뀌지 않을 때는 문제가 없었다. 애초에 전산화라는 것은 늘 '일상적으로' '반복되는'일에 대해서 자동화 시키는 것이었다. 그러나 산업 사회가 발전하면서 점점 변화의 속도가 빨라졌다.

예를 들면 그전에는 어떤 한 프로젝트를 진행해서 프로그램을 완성하면 처음에만 몇번 손을 봐주면 거의 2,3년간 다시 고칠 필요가 없었다. 그러나, 이제는 그런 경우는 작은 규모나 몇 몇 특이한 경우를 제외하고는 보편적인 일이 아니다. 새로운 프로그램을 짜 놓고 정상화 시켜서 더 이상 손 볼 필요가 없는 수준이 되었다 싶으면 부서 조직 개편이 일어나서 다시 손을 봐야 하고, 기획부서나 영업부서 등에서는 새로운 보고자료를 요구해 온다. 늘 새롭게 변하는 양식에 대해 처리하고자 하다 보니 전산 업무라는 것은 마치 치다꺼리하는 업무처럼 되어 버렸다.

이런 과정으로 몇 개월, 몇 년이 쌓이게 되면 전산부서는 욕을 먹게 되거나, 더 이상은 이런 식으로 일을 처리할 수 없다고 버티게 된다. 회사는 회사 나름대로 비용투자는 엄청나게 했는데 쓸만한 결과는 나오지 않는다고 투덜댄다. 이뿐인가? 전산부서의 직원들은 전산을 3D업종이라고 생각하게 되고, 어느 정도 경력이 쌓이면 그 실력을 더 발전시키지 못하고 관리직으로 이동하게 된다. 그래서 머리 허연 프로그래머를 찾기는 무척 힘든 것이 사실이다. 이런 문제를 해결할 방법은 없을까?

1984년 즈음에 E. F. Codd 박사는 그의 논문에서 왜 현업 부서들의 요구를 전산실에서는 제대로 수용을 못할까라는 고민을 하였다. 그리고는 그는 그 결론을 사용하고 있는 데이터베이스 시스템이라고 내렸다. 지금까지 사용해 오던 데이터베이스는 계속적으로 변화하는 환경에 빠르게 대처하지 못한다는 것이다. 그래서 그는 현업부서의 요구를 분석하고 이를 신속하게 처리할 수 있는 새로운 데이터베이스 시스템을 탄생시켰다. 그것이 바로 R-DBMS인 것이다.

--- p.115

많은 프로그래머들이 기교에 충실한다고 생각한다. 새로운 tip이나 기술, 기교에는 민감해서 그런것을 자신의 프로그램 속에 구현을 해두면 가슴이 뿌듯해지는 것은 사실이지만, 그렇다고 해서 기본을 무시하는 것은 정말 문제가 있지 않을까 ?

--- p.124


관계형 데이터베이스는 그 말에서 풍기는 것처럼 '관계'가 매우 중요한 데이터베이스 시스템이다.

한 테이블이 그 자체로 존재하는 경우도 있지만, 실제 환경에서는 다른 테이블과 연관된 관계'를 맺고 있는 것이 더 흔하다. 예를 들면 사원 테이블은 부서코드 라는 것으로 부서 테이블과 관계를 맺고 있다. 부서 테이블에는 1003이라는 부서가 없는데 어떤 사원이 부서코드에 1003이라는 값을 가지고 입력된다면, 이것은 비정상적인 데이터이며, 입력을 거부해야 하는 상황이라고 할 수 있다.

앞서 다룬 것처럼, 전통적으로 이런 입력 거부에 대해서는 프로그램에서 처리해 왔다. 그러나 관계형 데이터베이스에서는 이것을 데이터베이스 서버가 처리한다.

위의 예에서 만약 부서 테이블에 부서 코드라는 컬럼의 크기를 처음에는 문자열 4바이트를 잡아두었다가 자리가 모자라 5자리로 늘린다면 사원 테이블을 비롯한 모든 부서코드를 참조하는 테이블들 역시 변경되어야 한다. 일반적으로 프로젝트의 초기 단계에서는 이런 일이 약간은 용납 되지만, 어느 정도진행된 후에는 쉽게 허용될 수 없게 된다. 그래서 R-DB는 전통적인 데이터베이스 개발 기법과는 달리 데이터 모델링이라는 과정이 꼭 필요하고, 설계에 들어가는 시간이 오히려 개발에 들어가는 시간보다 월등히 많이 필요하다. 데이터 모델링에 대해서 이 장에서 비록 간단히 다루기는 하지만, 너무나 광범위한 주제이므로 독자들은 이것이 전부라는 오해를 하지 말아야 한다. 이에 대해서는 별도의 책들을 통해서 꼭 공부를 따로 하기를 바란다. 추천도서의 목록들을 참조하도록 하자.


데이터 모델링이라는 것은 이렇듯 "관계"를 중요시 여기는 관계형 데이터베이스에서 매우 중요한 기초 개념이 된다. 제대로 모델링 과정을 거치지 않은 데이터베이스의 설계는 추후에 매우 많은 문제들을 일으키게 된다. 대부분의 데이터베이스 전문가들은 성능 향상에 있어 중요한 요소로 데이터베이스 디자인을 들고 있다. 처음에 설계를 잘못하면 아무리 튜닝을 해도 한계에 부딪히게 된다.

과거의 전통적인 데이터베이스 개발에서는 전체 중 약 30% 정도의 시간을 데이터베이스 디자인에 할당했다면 관계형 데이터베이스에서는 전체의 개발 시간중 심하면 약 70%~80%의 시간을 데이터베이스 디자인에 할당할 정도로 그 중요성이 커졌다.

--- p.116

출판사 리뷰

탁월한 데이터베이스를 위한 탁월한 책
따라하기를 하다보면 복잡한 설명 필요없이 이해 될 정도로 쉽게 SQL 서버 2000을 익힐 수 있다. 여러 강의와 세미나에서 폭발적인 인기의 주인공, 정원혁 강사가 직접 쓴 SQL 서버 2000 개발자를 위한 지침서 초보자를 위한 자세한 쿼리 분석기의 사용법 설명과 데이터베이스 설계의 경험이 없는 사람들을 위한 강화된 데이터베이스 모델링을 설명했습니다. SQL 서버 2000만의 사용자 정의 함수, INSTEAD OF TRIGGER, 인덱스된 뷰, 새로운 자료형, 전체 텍스트 등에 대한 새롭고 강화된 내용을 이해하기 쉽도록 설명했습니다. 커서, 동적인 문장 실행(EXECUTE, sp_execute), 하위 질의 등에 대한 강화된 내용을 따라하기식 구성에 떄라 설명했으며 고급자도 만족할 만한 더욱 강화된 색인, 트랜잭션에 대한 내용을 다루었습니다.

리뷰/한줄평15

리뷰

6.8 리뷰 총점

한줄평

첫번째 한줄평을 남겨주세요.