2009/04/26 19:50
데이터베이스 구조 튼튼한지 확인(02) General Tech.2009/04/26 19:50
튼튼한 구조 만들기
필드 정밀 조정
이름에 포함된 것?
- 필드는 데이터베이스에서 가장 기초적인 구조임.
- 점검 목록은 다음과 같다.
- 이름이 설명적이고 전체 조직에서 의미가 있는가?
- 필드 이름이 명확하고 명료한가?
- 도시의 경우(EmpCity, CustCity 등)
- 필드 이름으로 두문자어 또는 약어를 사용하고 있는가?
- 한 가지 이상의 특성을 암시적 또는 명시적으로 식별하는 이름을 사용하고 있는가?
- 마지막으로 필드 이름으로는 단수형을 사용할 것(복수형은 의미가 두 개이므로 단일 값을 나타내는 필드의 성격과 맞지 않음)
거친 모서리 다음기?
- 필드가 테이블 주제의 특별한 특성을 나타내는지 확인.
- 필드가 단일 값을 가지고 있는지 확인
- 다중 값 필드 : 같은 값들의 여러 인스턴스를 잠재적으로 저장할 수 있는 필드
- 다중 부분 필드 : 둘 이상의 서로 다른 값들을 잠재적으로 저장할 수 있는 필드
- 필드가 계산이나 연결 결과를 저장하지 않는지 확인한다.
- 계산값이 들어 있으면 수작업 또는 계산의 어떤 값이 변경될 때 마다 수행되는 절차적 코드가 필요해짐.
- 필드가 전체 데이터베이스에서 단 한번만 나타나도록 한다.
- 일관성 없는 데이터(다시 말해 데이터 변경시 다른 테이블의 해당 값을 잊어버리고 변경하지 못하는 실수가 발생하게 됨.)
다중 부분 필드 해결하기
- 다중 부분과 다중 값 필드는 데이터 무결성을 깨뜨림.
- 다중 부분 필드를 가지고 있는지는 어떻게 아는가?
- "이 필드의 현재 값을 취해서 더 작고 확실한 부분들로 분할할 수 있을까?"
- 예) 233 West Valley Hwy, San Diego, CA 92199
다중 값 필드 해결하기
- 거의 예외 없이 여러 개의 쉼표를 포함함.(예: 727, 737, 757, MD80)
- 데이터 무결성 문제에 직면할 경우가 발생함.
- SQL 쿼리로 이 필드에 대한 검색과 정렬을 수행하기 어려움.
- 다대다 관계 이므로 연결 테이블로 문제를 해결할 수 있음
- 다중 값 필드와 원본 테이블의 주 키 필드의 복사본을 기초로 사용함.
- 새 연결 테이블의 이름을 정하고 두 필드를 복합 주 키로 지정(양쪽 필드 값들의 결합만이 레코드를 유일하게 식별할 수 있음)
테이블 정밀 조정
이름에 포함된 것(두 번째)
- 정의에 의해 테이블 이름은 단일 주제를 나타내어야 한다.
- 만약 테이블 이름이 모호하거나 불명확하다면 테이블의 주제가 선정되지 않았다고 봄.
- 이름이 고유하고 전체 조직에서 의미가 있을 만큼 충분히 설명적인가?
- 이름이 정확하고 명확하고 모호하지 않게 테이블의 주제를 식별하는가?
- 이름이 물리적 특성을 나타내는 단어를 포함하는가?
- File, Record, Table과 같은단어는 피한다.
- 테이블 이름으로 두문자, 약어를 사용하는가?
- 암시적 또는 명시적으로 하나 이상의 주제를 식별하는 이름을 사용했는가?
- and, or와 같은 단어, 백스페이스, 하이픈 등은 사용하지 않는다.
- 테이블의 이름은 복수형을 사용한다.(Emplyees)
튼튼한 구조 확인하기
- 테이블이 단일 주제를 나타내는지 확인한다.
- 각 테이블이 주 키를 가지고 있음을 확인한다.
- 테이블에 의해 표현되는 것들이 개체 또는 사건임을 기억.
- 각 테이블이 주 키를 가지고 있음을 확인한다.
- 첫 째 : 각 레코드를 유일하게 식별해줌
- 둘 째 : 테이블 관계를 설정하는 데 사용.
- 테이블이 다중 부분 또는 다중 값 필드를 포함하지 않는지 확인한다.
- 테이블에 계산된 필드가 없는지 확인한다.
- 테이블에 불필요한 이중(duplicate) 필드가 없는 지 확인한다.
불필요한 이중 필드 해결하기
[Staff]
| StaffID | StaffFirstName | StaffLastName | StaffStreetAddress | StaffCity | StaffState | <<other field>> |
| 98014 | James | Leverling | 722 Moss Bay Blvd. | Kirkland | WA | ... |
| 98019 | Laura | Callahan | 901 Pine Avenue | Portland | OR | ..... |
[Classes] : 아래에서 빨간색 필드는 불필요.
| ClassID | Class | ClassRoomID | StaffID | StaffLastName | StaffFirstName | <<other field>> |
| 1031 | Art History | 1231 | 98014 | Leverling | James | ... |
| 1030 | Art History | 1231 | 98014 | Leverling | James | ..... |
위 테이블의 관계는 일대다 관계임. 따라서 클래스 테이블의 두 필드는 불필요.
관계형 데이터베이스에서 전체 데이터베이스에서 데이터는 오직 한번만 입력되어야 함.
식별하는 것은 키이다.
- 테이블 내의 각 레코드를 유일하게 식별하고, 데이터베이스 전체에서 테이블을 공식적으로 식별.
- 한 쌍의 테이블 사이의 관계를 설정하기도 함.
- 주 키는 단순키와 복합키로 구성됨.(가능하면 주 키 사용)
- 필드가 테이블 내의 각 레코드를 유일하게 식별하는가?
- 필드가 고유한 값을 가지는가?
- 필드가 미지의 값을 포함할 수 있는가?
- 필드의 값이 선택적 일 수 있는가?
- 다중 부분 필드인가?
- 필드의 값이 언젠가 수정될 수 있는가?
견실한 관계 설정하기
- 주 테이블의 주 키를 종속하는 테이블에 삽입(일대일 관계 설정)
- 일(one) 측 테이블의 주 키를 다(many) 측 테이블에 삽입(일대다 관계 설정)
- 연결 테이블을 만듬으로써 다대다 관계를 설정
삭제 규칙 설정하기
- 일대일 관계에서 '주' 테이블의 레코드나 일대다 관계의 '일' 측 레코드를 삭제해야 고아 레코드 방지.
- 제약과 연속 이라는 두 종류의 삭제 규칙을 지정할 수 있음.
- 제약 삭제 규칙 - 일대일 관계나 일대다 관계에서 종속 테이블의 데이터를 삭제하지 못하도록 막는다. 요청 레코드 삭제전에 연관 레코드를 삭제하도록 한다.
- 연속 삭제 규칙 - 일대일 관계에서 '종속' 테이블 또는 일대다 관계에서 '다' 측 테이블의 연관 레코드와 요청받은 레코드까지 삭제
- 매우 신중하게 적용.
- 질문 : 만약 고객 테이블에서 레코드가 삭제된다면 고객주문 테이블 내의 연관 테이블도 삭제 되어야 하는가?
- 예 : 연속 삭제 규칙 적용
- 아니오 : 제약 삭제 규칙 적용
참여 종류 설정하기
- 다른 테이블에 레코드를 삽입하기 전에 그 테이블에 레코드가 있어야 하는지 여부를 결정.
- 강제적 : 다른 테이블에 레코드를 입력하기 전에 이 테이블에 적어도 하나의 레코드가 반드시 있어야 함.
- 선택적 : 다른 테이블에 레코드를 입력하기 전에 이 테이블에 어떤 레코드가 있어야 할 필요가 없음.
- 다대다 관계에서 적용.
참여 수준 설정하기
- 관계는 알았지만 수준은?
- 다른 테이블의 단일 레코드에 연관될 수 있는 한 테이블의 최소 및 최대 레코드 수를 파악함으로써 수행.(참여수준을 식별)
- 쉼표로 분리하고 괄호로 둘러싸인 두 개의 숫자로 표시.
- (예 1, 12) - 참여 수준 연관 레코드가 1개이고, 최대 레코드 갯수가 12개임.
Reference : SQL Queries for Mere Mortals(운명적 존재를 위한 SQL 쿼리)
'General Tech.' 카테고리의 다른 글
| ASP.NET, Silverlight 관련 정보 공유 (0) | 2009/08/29 |
|---|---|
| MSDN 웹 캐스트 시리즈 (0) | 2009/07/28 |
| 데이터베이스 구조 튼튼한지 확인(02) (0) | 2009/04/26 |
| 관계형이란(01) (0) | 2009/04/26 |
| 사용자 데이터베이스 이전하기. (0) | 2008/12/21 |
| DAS (0) | 2008/11/30 |
