1)번에 대한 답은 책을 다시 보면서 찾은 것 같은데 맞는지 모르겠습니다. 

- 코드북으로 부터 쿼리를 만들어서 테이블처럼 사용하는 게 맞는지요?

어떤 목적을 위하여 코드북을 만드시고, 그 코드북이 어떤 것을 말하는 것인지 잘 모르겠습니다.

말씀하신 것은 테이블에 입력되는 값을 제한하기 위한 데이터 유효성 목적으로 제작하는 코드북 테이블을 말씀하시는 것입니까?

그렇다면 레코드를 담은 테이블(예시: 직원명 - 직위 - 직원상태)가 있을 것이고, 직원명 혹은 직원상태에 입력될 수 있는 값을

목록화하여 만든 코드북 테이블이 있을 것입니다. 이때 레코드 테이블은 "홍길동 - 사장 - 휴직"으로 구성될 수 있을 것이고, 

코드북 테이블은 직위의 경우 사장, 상무, 임원, 대리, 사원 등등.. 회사에 존재할 수 있는 직위들 코드화하여 담을 것이며

직원상태의 경우 퇴사, 휴직, 재직, 실종 등등 필요하다고 생각되는 직원상태를 코드화하여 담을 수 있을 것입니다.

이렇게 어떤 필드에 들어갈 수 있는 값을 코드북화하여 저장하고, 관계를 설정하면 다음의 이점이 있을 수 있습니다.

코드북화를 하지 않는 경우에는 필드에 들어갈 수 있는 값이 추가조치를 하지 않는 한 다양할 수 있으므로, 예로 들어 직원상태 필드의 경우 입력하는 사람마다 다르게 판단해서 같은 상태에 대해서도 휴직, 휴가, 휴직중, 휴가중 이런 식으로 적어낼 수 있습니다. 물론 사람은 이것을 보고 같은 상태라고 판단할 수 있지만, 컴퓨터는 그렇지 않습니다. 휴직이나, 휴가나, 퇴사나 모두 다른 텍스트값을 가지므로 다른 값으로 인식하지요. 하지만 만약 코드북화를 하여 들어갈 수 있는 값을 딱딱 분리하여 제한시켜놓으면, 추후 이 데이터를 가지고 응용할 가능성이 생깁니다. 예로들어, 현재 우리회사에서 휴직하고 있는 사람의 레코드를 모두 불러오고 싶다고 합시다. 전자의 경우 사람이 일일히 레코드 테이블을 보고 휴직중인지 판단해야 하지만, 코드북 테이블로 입력값을 제한했을 경우 단순히 조건식에 [업무상태]="휴직"을 적어넣는 것만으로 모든 휴직중인 사람을 간편하게 불러낼 수 있습니다. 즉, 필드값 코드북의 이점은 레코드를 단순한 데이터 집합이 아닌 응용이 가능한 데이터로 변화하는 것에 있습니다.

그런데, 말씀하시는 것을 들어보니 직원상태, 직위 등등을 모두 한 테이블에 담아서 관리하시는 것인가요? 그러면 오히려 관계 설정시 직원상태에 직위 목록을 입력할 수도 있고 직위에 직원상태를 입력할 수도 있어서 관리하는 의미가 크게 퇴색할 것 같은데요. 보통은 각 필드값에 대해 코드북을 만들어 따로 관리하는 것이 일반적이고,

가장 중요한 것은 "굳이 그렇게 할 필요성이 없다고 판단되는 경우" 할 필요가 없다는 점입니다. 만약에 어떤 필드에 들어갈 수 있는 값이 정말로 무궁무진한데 코드북화하여 관리할 경우 매번 코드북과 다른 값을 입력해야 하는 순간마다 코드북에도 추가를 해줘야 하므로 이중으로 수고가 들어갑니다. 업무를 편리하려고 하는 것이 오피스 프로그램인데 오히려 더 관리하기 불편하게 만들 뿐입니다.

참고로 코드북에는 필드에 들어가는 데이터를 제한하는 유효성 목적의 코드북이 아니라 제품코드, 부자재코드와 같은 코드북도 있습니다. 글쓴이분은 첫번째 경우와 두번째 코드북 케이스를 같이 말씀하시는 것 같은데 액세스상 구동 원리는 똑같지만 사용목적이나 관리방법은 전혀 다르므로 쿼리, 조건식을 말씀하셔도 질문하시고 싶으신게 정확히 무언지는 잘 모르겠네요.

장문의 답변에 감사드립니다. 2010책에서는 코드 관리를 두 테이블로 하셨고, 2013에서는 코드 관리를 한 테이블로 하신 듯요. 저는 후자를 따르고 싶어서 테이블 필드 구성을 2013과 같이 했습니다. 그 코드북 테이블에는 직원 상태, 부서 등 다양한 내용의 코드들이 들어가 있고요. 이 경우 어떻게 활용할지에 대한 질문이었습니다. 그런데 그 답을 책에서 찾은 듯하여 댓글을 단 것이고요. 

코드북은 기본적으로 다른 테이블들과 관계 설정을 할 수가 없네요. 할 필요도 없고, 그냥 필요한 곳에 적당히 불러다 사용하는 것 같던데... 맞는지요?

답변이 늦어 죄송합니다.

말씀하신 것처럼, 해당 책에서 코드북을 사용하는 것은 관계 설정을 하지 않고 사용하는 것입니다.

DB이론에는 벗어나는 것이지만, 편리하기에 사용하는 것이죠.

그리고, 코드북 테이블은 '코드구분/코드/코드이름/정렬순서'와 같이, 아주 단순합니다.

'모든 코드 테이블을 코드북으로 구현해야 한다'라는 의미가 아닙니다.

지금 말씀하시는 것과 같이, '부서', '직위', '직원상태' 같은 필드가 필요하다면, 별도의 테이블을 만드는 것이 낫습니다.

'코드구분/코드/코드이름/정렬순서' 과 같이, 단순한 필드 구성일 때에만 사용할 수 있는 데이터를 코드북에 넣는 것이 바람직하죠.

두 번째 질문은.. 테이블 갯수를 줄이고, 코드를 한 군데에서 관리한다는 이점.

그리고 굳이 이야기 하자면.. 코드 입력/조회폼도 하나로 통일할 수 있다는 이점이 있죠.

그것 이외의 이점은 없습니다.

단점은 broadside 님께서 말씀하신 것처럼, DB 차원의 유효성 검사가 안 된다는 점이 있죠.

이런 점을 복합적으로 고려하여 사용하셔야 합니다.

그리고 이 게시판은 팀데이터21에서 답해드린다는 보증은 하지 않습니다.

사용자들끼리 질문/답변을 하자는 의미의 공개 게시판입니다.

현실은 주로 저희 임직원들이 답을 하고 있지만요.

(그런 의미에서 broadside 님께 감사드립니다.)

팀데이터21에서 출간한 책에 대한 Q/A를 하는 곳도 아닙니다.

이곳은 그저, 회원들끼리 액세스 관련한 질문/답변을 자유롭게 하는 곳입니다.

단지, 다른 곳의 게시판과 다른 점은..

시간이 좀 걸릴 수는 있어도, 혹시 답이 달리지 않는 질문이 있다면, 제가 꼭 답글을 달아 드린다는 점이 있을 뿐이죠.

그 답글도 '정답'이 아닐 수는 있겠지만요.

그런데, 질문하는 것을 보니, 클로이 님께서 공부를 아주 많이 하신듯 하네요.

예전과는 질문 수준이 좀 다릅니다. ^^