배움터  
  HOME > 배움터 > 무료강좌
무료강좌
 
액세스 2000, 김규경님의 데이터베이스 기초 다지기 - 제19강. Northwind의 조회필드, Access 2000
  


제19강. Northwind의 조회필드


테이블과 관련된 용어 몇 가지

Master TableDetail Table : 테이블이 다이나믹하게 변하면서 하나의 주제에 관련된 두 테이블의 일대다의 관계를 표현할 때 사용합니다. [일]측이 master [다]측이 Detail 테이블입니다.

Lookup Table / Code Table : 단일 필드에 입력할 선택항목을 가지고 있는 테이블을 뜻합니다. 레코드의 추가/삭제가 다이나믹 하지 않고 대개 일정하게 유지되고 하나의 필드에 대한 추가적인 정보를 가진 고유 레코드로만 만들어진 테이블입니다. 필드의 크기가 크지 않는 경우는 하나의 필드로만 구성되고 필드의 크기가 큰 경우는 두 개 이상의 필드로 구성됩니다. 코드 키와 설명을 가지고 있는 테이블. 목록(분류, 종류 등)에 대한 코드와 그 코드에 대한 설명으로 구성되어 있으며 대개 단일 필드의 크기를 줄이고, 속도와 입력의 효율성을 위해 사용합니다. 코드는 대개 설명 필드의 내용을 약자나 의미 있는 코드로 표현합니다.

P415M17 Pentium IV 1.5GHz with 17” Monitor

Junction Table : 데이터베이스 디자인 단계에서 업무분석을 통해 주제 테이블들을 구성하고 두 개의 주제 테이블이 다대다의 관계로 분석이 되면 반드시 일대다의 관계가 만들어지도록 새로운 테이블을 만들게 되는데 이것을 병합테이블이라고 합니다.
 

조회테이블 / 코드테이블

이전에 ‘테이블의 정규화’에서 이미 설명 드린 바 있지만 기본 키에 매여있지 않아 중복되는 경우는 제2정규화를 통해서, 필드끼리 의존성이 있는 경우는 제3정규화를 통해서 중복되는 자료는 또 하나의 테이블로 떼어 내게 되는데 이 테이블은 Master-Detail 관계일 수도 있고 LookUp 테이블 형태일 수도 있습니다.

정규화된 Northwind 예제파일에서 조회필드

다음 예는 정규화된 Northwind 예제파일에서 조회필드가 사용되는 내용들입니다. 간단하지만 한번 보고 넘어가도록 하겠습니다.

바운드 열, 열의 개수, 열의 너비 등의 속성을 한번씩 확인하시길 바랍니다.

대개 열의 개수는 2개(코드/기본키필드 + 설명필드), 열의 순서는 기본키필드-설명필드 순서, 따라서 바운드 열은 1번 열, 그리고 조회필드를 사용하는 이유는 코드 형태의 자료를 보려는 것이 아니라 알아보기 쉬운 필드를 보기 위한 것이므로 1번 열의 너비를 0 센티미터로 설정하여 숨겨버리고 실제로 콤보상자는 하나의 열만 있는 것처럼 되어 있군요.

참고로 Northwind 테이블의 기본 키는 Customers 테이블만 5글자 크기의 텍스트형식이고 모두 일련번호 형식이라는 것도 기본 키를 무엇으로 할까 고민하는 초보자들을 맘 편하게 할 것으로 생각됩니다.

Products 테이블의 제품 분류(CategoryID) 열의 내용을 보면 중복되는 것이 많습니다. 따라서 이것을 따로 떼어내어 Categories라는 조회테이블을 만들고 제품분류 필드는 조회 필드를 만들어 자료의 입력을 쉽게 하도록 하였습니다.

Products 테이블을 디자인 보기로 열고 제품분류 필드의 컨트롤표시가 콤보상자로 되어 있는데 이것을 텍스트상자로 변경을 하고 저장한 다음 데이터시트보기로 한번 보시지요.

보시면 다음과 같이 Categories 테이블의 제품번호(CategoryID)열의 값이 Products 테이블의 제품분류 열에 들어 있다는 것을 아실 겁니다.

다음 예는 Products 테이블의 공급업체에 대한 내용입니다. Suppliers 테이블을 보시면 업체마다 일련번호를 부여하고 업체 일련번호를 Products 테이블에 저장하고 조회 필드로 운영하였습니다.

위 두 예에서 보신 바와 같이 이러한 기본 키는 일련번호로 처리하였습니다.
관계형 데이터베이스에서 크기를 줄이려면 코드화 해야 한다’ 라고 말합니다.
그러나 이렇게 코드테이블의 운영이 많아지면 테이블의 자료가 온통 코드로 가득 차서 난해해 집니다. 조회필드가 얼마나 편리한 것인지 아시겠지요?

다음은 Orders 테이블의 조회필드의 컨트롤 표시를 콤보상자로 했을 때와 해제하였을 때의 모습을 비교하여 보십시오. 약간 더 난해해 집니다.


담당자 직위는 조회필드로 사용하지 않았어요…

마지막으로 고객정보(Customers) 테이블을 한가지만 더 생각을 해봅시다.

[담당자 직위] 열을 보면 자료의 중복이 보입니다. 조회테이블을 만들 수 있는 필드입니다. 그런데 Northwind 예제에서 ‘담당자 직위(ContactTitle)’를 조회필드/조회테이블을 만들어 사용하지 않았습니다.
이유는 뭘까요?

1) 일반적으로 업체마다 공통적으로 직위는 있습니다. 그러나 여러 업체를 상대하는 경우 업체마다 직위체계가 달라 조회테이블 운영에 약간의 제약이나 테크닉이 필요할 겁니다.

2) 직위는 전화할 때 참조하거나 우편물 발송할 때나 쓰이는 정도일 겁니다. 따라서 조회테이블을 만들고 조회하고 질의테이블을 만들 때 해당 조회테이블을 포함시키는 등 작업을 복잡하게 만들 필요는 없겠습니다.

3) 또 입력되는 자료가 “영업 사원”, “영업사원”, “영업” 등과 같이 통일되지 않게 입력되더라고 문제가 되지 않습니다.

아마도 이러한 이유로 생각이 됩니다.

자기 필드에 입력된 데이터에서 목록 취하기

테이블에서는 조회필드로 이용할 필요는 없을지라도 자료를 입력할 때 편의를 위하여 입력 폼에서 새로운 데이터를 입력할 때만 콤보상자를 이용하는 것은 편리할 수 있습니다.
이때는 조회테이블을 따로 만들어서 사용하지 않고 엑셀에서 어떤 셀에 값을 입력하면 그 셀이 위치한 열에 들어 있는 항목을 자동으로 확장입력해주는 것처럼 해당 필드에 입력된 데이터 중에서 목록을 조회하여 사용하는 것이 바람직해 보입니다. 그런 경우 ‘목록 값만 허용’을 ‘아니오’로 설정하십시오.

다음은 ‘행원본’을 질의문으로 작성한 내용입니다.
이때는 코드로 처리하는 것이 아니기 때문에 그 값만 가져올 필드(ContactTitle) 하나만이 질의에 포함되어 있습니다.
쿼리 속성창에서 고유값 속성을 ‘예’로 설정하였습니다. 고유값 속성은 SQL문에서 DISTINCT 키워드에 해당됩니다.
목록의 자료를 정렬시키는 것도 잊지 않도록 하십시오.


SELECT DISTINCT Customers.ContactTitle
FROM Customers
ORDER BY Customers.ContactTitle;

이렇게 하면 Customers 테이블의 ContactTitle(담당자 직위)에 입력된 직위를 목록으로 만들어 보여줍니다.

목록에 없는 새로운 값을 입력하고 나서 이 값을 목록에 포함시키려면 F9을 눌러 새로 고침을 하면 됩니다.

위 내용을 편의상 테이블에서 설정을 하여 보여 드렸지만 원본 테이블에서는 가능하면 설정하지 마시고 폼의 입력 컨트롤에서 이용하십시오.
 

 

  목차 | 이전 | 다음