데이터베이스 영역에서 데이터베이스를 사용하는 다양한 시스템을 데이터베이스 애플리케이션 시스템이라고 합니다.
I. 데이터베이스 및 정보 시스템
(1) 데이터베이스는 정보 시스템의 대량의 데이터를 특정 모델로 구성하여 데이터 저장, 유지 관리 및 검색을 제공하는 정보 시스템의 핵심이자 기반입니다.
정보 시스템이 데이터베이스에서 필요한 정보를 쉽고 시기 적절하며 정확하게 얻을 수 있도록 하는 기능
(2) 데이터베이스는 정보 시스템의 각 부분이 어떻게 밀접하게 결합될 수 있는지의 관건이다.
(3) 데이터베이스 설계는 정보 시스템 개발 건설의 중요한 구성 요소이다.
(4) 데이터베이스 디자이너가 갖추어야 할 기술과 지식:
데이터베이스 및 데이터베이스 설계 기술의 기본 사항
컴퓨터 과학의 기초 지식과 프로그래밍의 방법과 기교.
소프트웨어 공학의 원리와 방법
응용 분야의 지식
둘째, 데이터베이스 설계 특성
데이터베이스 구축은 하드웨어, 소프트웨어 및 하드웨어의 조합입니다.
3 점 기술, 7 점 관리, 12 점 기본 데이터
기술과 관리 사이의 인터페이스를 "건조 부분" 이라고 합니다
데이터베이스 설계는 응용 시스템 설계와 결합되어야 합니다.
구조 (데이터) 설계: 데이터베이스 프레임 또는 데이터베이스 구조를 설계합니다.
행동 (처리) 디자인: 디자인 응용 프로그램, 트랜잭션 등.
구조와 행동 분리의 설계
전통적인 소프트웨어 엔지니어링은 응용 프로그램에서 데이터 의미의 분석과 추상화를 무시하고 데이터 구조 설계 결정을 최대한 연기합니다. 초기 데이터베이스 설계는 동작 설계를 무시하고 데이터 모델 및 모델링 방법 연구에 주력했습니다.
그림과 같이:
셋째, 데이터베이스 설계 방법에 대한 간단한 소개
인공시험 오류법
디자인 품질은 디자이너의 경험과 수준과 직결된다.
과학 이론과 공사 방법의 지지가 없으면 공사의 품질을 보장하기 어렵다.
데이터베이스가 일정 기간 가동되면 다양한 문제를 다양한 수준으로 발견하고 유지 관리 비용을 늘리는 경우가 많습니다.
사양 설계 방법
수동 디자이너
기본 사상
프로세스 반복 및 단계별 미세 조정
표준 설계 방법 (계속)
일반적인 방법:
(1) 뉴올리언스법: 데이터베이스 설계는 4 단계로 나뉩니다.
남 B. 야오 방법: 데이터베이스 설계는 5 단계로 나뉜다.
I.R.Palmer 메서드: 데이터베이스 설계를 단계별 프로세스로 처리합니다.
(2) 컴퓨터 지원 설계
ORACLE Designer 2000
Sybase PowerDesigner
넷째, 데이터베이스 설계의 기본 단계
데이터베이스 설계 프로세스 (6 단계)
1. 수요 분석 단계
사용자 요구 사항 (데이터 및 처리 포함) 을 정확하게 이해하고 분석합니다
전체 설계 프로세스의 기초이자 가장 어렵고 시간이 많이 걸리는 단계입니다.
2. 개념 구조 설계 단계
전체 데이터베이스 설계의 핵심입니다.
사용자 요구에 대한 통합, 요약 및 추상화를 통해 특정 DBMS 와 독립적인 개념 모델을 형성합니다.
논리 구조 설계 단계
개념 구조를 DBMS 가 지원하는 데이터 모델로 변환합니다.
최적화해 보세요.
데이터베이스 물리적 설계 단계
논리적 데이터 모델에 대한 애플리케이션 환경에 가장 적합한 물리적 구조 (스토리지 구조 및 액세스 방법 포함) 를 선택합니다.
5. 데이터베이스 구현 단계
논리적 및 물리적 설계 결과에 따라 DBMS 가 제공하는 데이터 언어, 도구 및 숙주 언어를 사용합니다
데이터베이스 구축, 디버깅 응용 프로그램 컴파일, 데이터 저장소 구성, 파일럿 수행
6. 데이터베이스 운영 및 유지 보수 단계
데이터베이스 애플리케이션 시스템은 시범 운영을 거쳐 정식 운영에 들어갈 수 있다.
데이터베이스 시스템은 실행 중에 지속적으로 평가, 조정 및 수정해야 합니다.
디자인 특징:
설계 과정에서 데이터베이스 설계와 데이터베이스의 데이터 처리 설계를 긴밀하게 결합하여 각 단계에서 이 두 가지 측면의 요구 사항 분석, 추상화, 설계 및 구현을 동시에 수행하고, 상호 참조, 보완, 보완, 보완, 보완, 보완, 보완, 보완, 보완, 보완, 보완, 보완, 보완, 보완, 보완, 보완
설계 프로세스의 각 단계에 대한 설계 설명:
그림과 같이:
다섯째, 모든 수준의 데이터베이스 모델 형성 과정
1. 수요 분석 단계: 개별 사용자의 어플리케이션 요구를 통합합니다.
2. 개념 설계 단계: 기계 특성 및 DBMS 제품과 독립적인 개념 모델을 형성합니다 (E-R 다이어그램).
3. 논리적 설계 단계: 먼저 E-R 그래프를 특정 데이터베이스 제품이 지원하는 데이터 모델 (예: 관계형 모델) 으로 변환하여 데이터베이스 논리 모델을 형성합니다. 그런 다음 사용자의 처리 요구 사항 및 보안 고려 사항에 따라 기본 테이블을 기반으로 필요한 뷰를 설정하여 데이터의 외부 패턴을 형성합니다.
4. 물리적 설계 단계: DBMS 의 특성과 처리 요구에 따라 물리적 스토리지 일정을 잡고 인덱스를 작성하여 데이터베이스의 패턴을 형성합니다.
여섯째, 데이터베이스 설계 기술
1. 데이터베이스 설계 전 (수요 분석 단계)
1) 고객의 요구 사항을 이해하고 사용자에게 향후 수요 변화에 대해 어떻게 생각하는지 물어보십시오. 고객이 자신의 요구 사항을 설명하도록 하고, 개발이 진행됨에 따라, 고객의 요구 사항이 여전히 개발 목적에 부합하는지 확인하기 위해 자주 고객에게 물어봅니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언)
2) 기업의 업무를 이해하면 후기 발전 단계에서 많은 시간을 절약할 수 있다.
3) 입출력 주의.
데이터베이스 테이블 및 필드 요구 사항 (입력) 을 정의할 때 먼저 기존 또는 설계된 보고서, 조회 및 뷰 (출력) 를 검토하여 이러한 출력을 지원하는 데 필요한 테이블과 필드를 결정해야 합니다.
예를 들어 고객이 우편 번호별로 정렬, 분석 및 요약되는 보고서를 필요로 하는 경우, 우편 번호를 주소 필드에 넣는 대신 별도의 우편 번호 필드가 포함되어 있는지 확인해야 합니다.
4) 데이터 사전 및 ER 차트를 작성합니다.
ER 차트와 데이터 사전을 통해 데이터베이스를 아는 사람은 누구나 데이터베이스에서 데이터를 얻는 방법을 알 수 있습니다. ER 차트는 테이블 간의 관계를 표시하는 데 유용합니다. 데이터 사전에는 각 필드의 용도와 가능한 별칭이 표시됩니다. 이는 SQL 표현식의 문서에 절대적으로 필요합니다.
5) 표준 객체 명명 규칙을 정의합니다.
데이터베이스에서 다양한 객체의 이름을 표준화해야 합니다.
2. 테이블 및 필드 설계 (데이터베이스 논리 설계)
양식 설계 원칙
1) 표준화 및 표준화
데이터 표준화는 데이터베이스에서 데이터 중복을 제거하는 데 도움이 됩니다. 표준화에는 여러 가지 형태가 있지만 세 번째 패러다임 (3NF) 은 일반적으로 성능, 확장성 및 데이터 무결성 간의 최적의 균형으로 간주됩니다. 간단히 말해서, 3NF 표준을 준수하는 데이터베이스의 테이블 설계 원칙은 "한 곳에 한 가지 사실" 입니다. 즉, 테이블에는 자체 기본 속성만 포함되어 있으며 자체 속성이 아닌 경우 분해해야 합니다. 테이블 간의 관계는 외래 키로 연결됩니다. 관련 데이터를 전문적으로 저장하는 테이블 세트가 있으며 키로 연결되어 있습니다.
예를 들어 고객 및 관련 주문을 저장하는 3NF 데이터베이스에는 고객과 주문이라는 두 개의 테이블이 있을 수 있습니다. 주문 테이블에는 주문과 연관된 고객에 대한 정보가 없지만 고객 정보가 포함된 고객 테이블의 행을 가리키는 키 값이 테이블에 저장됩니다.
사실 효율성을 위해 때때로 양식을 규범화하지 않는 것이 필요하다.
2) 데이터 기반
하드 코딩 대신 데이터 구동을 사용하면 많은 정책 수정 및 유지 관리가 훨씬 쉬워지고 시스템의 유연성과 확장성이 크게 향상됩니다.
예를 들어 사용자 인터페이스가 외부 데이터 소스 (파일, XML 문서, 기타 데이터베이스 등) 에 액세스하려는 경우. 참고) 해당 접속 및 경로 정보를 사용자 인터페이스 지원 테이블에 저장하는 것이 좋습니다. 또한 사용자 인터페이스가 워크플로우 (메일 보내기, 편지지 인쇄, 기록 상태 수정 등) 와 같은 작업을 수행하는 경우 ), 그러면 워크플로우를 생성하는 데이터도 데이터베이스에 저장할 수 있습니다. 역할 권한 관리는 데이터 기반 을 통해서도 수행할 수 있습니다. 실제로 프로세스가 데이터 기반인 경우 사용자에게 상당한 책임을 맡길 수 있으며, 이들은 자체 워크플로우를 유지 관리합니다.
3) 다양한 변화를 고려한다
데이터베이스를 설계할 때 향후 변경될 수 있는 데이터 필드를 고려해야 합니다.
예를 들어 성은 이렇습니다. (서양인의 성씨, 예를 들어 여성이 결혼한 후 남편의 성 등을 주의하세요. ). 따라서 고객 정보를 저장할 시스템을 설정할 때 성 필드를 별도의 데이터 테이블에 저장하고 시작 및 종료 일자와 같은 필드를 추가하여 데이터 항목의 변경 사항을 추적할 수 있습니다.
현장 설계 원칙
4) 각 테이블에 추가해야 할 세 가지 유용한 필드.
이제 DRecordCreationDate 의 기본값은 VB 에서 () 이지만 SQL Server 에서는? 기본값은 getdate () 입니다
Sql Server 아래의 기본값은 NOT null 기본 SRecordCreator? 사용자
NRecordVersion, 레코드 버전 태그; 기록에 빈 데이터나 누락된 데이터가 있는 이유를 정확하게 설명할 수 있습니까?
5) 주소 및 전화 번호에 여러 필드를 사용합니다.
한 줄로 거리 주소를 묘사하는 것만으로는 충분하지 않다. Address_Line 1, Address_Line2 및 Address_Line3 은 더 큰 유연성을 제공합니다. 또한 전화 번호와 이메일 주소에는 자체 데이터 시트가 있어야 하며 자체 유형과 레이블 범주가 있어야 합니다.
6) 역할 엔티티를 사용하여 범주에 속하는 열을 정의합니다.
특정 범주에 속하거나 특정 역할을 가진 것을 정의해야 하는 경우 캐릭터 엔티티를 사용하여 자체 문서화를 위한 특정 시간 연결을 만들 수 있습니다.
예를 들어 person 엔티티와 person_TYPE 엔티티를 사용하여 사람을 설명합니다. 예를 들어, John Smith, 엔지니어가 John Smith, 이사로 승진하고 결국 John Smith, CIO 의 높은 자리에 오르면 두 테이블 person 과 person_TYPE 사이의 관계에 대한 키 값을 변경하고 날짜/시간을 추가하는 것이 좋습니다 이렇게 하면 person_TYPE 테이블에 가능한 모든 개인 유형 (예: 보조, 엔지니어, 이사, CIO 또는 CEO) 이 포함됩니다. 또 다른 대안은 개인 레코드를 변경하여 새로운 직함의 변화를 반영하는 것이지만, 개인의 정확한 위치 시간을 제때에 추적할 수는 없다.
7) 가능한 한 많은 숫자 유형과 텍스트 유형을 선택합니다.
Sql 에서 smallint 및 tinyint 유형을 사용할 때는 특히 주의해야 합니다. 예를 들어 총 필드 유형이 작은 월 총 매출을 보려는 경우 합계가 32,767 달러를 초과하면 계산할 수 없습니다.
고객 id 나 주문 번호와 같은 id 유형의 텍스트 필드는 평소보다 크게 설정해야 합니다. 고객 id 의 길이가 10 자리 숫자라고 가정합니다. 그런 다음 데이터베이스 테이블 필드의 길이를 12 또는 13 자로 설정해야 합니다. 그러나 이러한 추가 공간은 향후 데이터베이스 규모 증가를 위해 전체 데이터베이스를 재구축할 필요가 없습니다.
8) 삭제 표시 필드를 추가합니다.
행을 삭제 표시할 수 있도록 테이블에 삭제 표시 필드를 포함합니다. 관계형 데이터베이스에서 행을 삭제하지 마십시오. 데이터 정리 프로그램을 사용하고 색인의 무결성을 신중하게 유지하는 것이 좋습니다.
3. 키와 색인 (데이터베이스 논리 설계) 을 선택합니다
키 선택 지침:
1) 주요 설계 4 원칙
연관된 필드에 대한 외래 키를 생성합니다. -응?
모든 키는 고유해야 합니다. -응?
키 조합을 사용하지 마십시오. -응?
외래 키는 항상 고유 키 필드와 연결됩니다. -응?
2) 시스템 생성 기본 키 사용
데이터베이스를 설계할 때 시스템에서 생성한 키를 기본 키로 사용하여 데이터베이스의 인덱스 무결성을 실제로 제어합니다. 이렇게 하면 데이터베이스 및 수작업이 아닌 메커니즘이 저장된 데이터의 각 행에 대한 액세스를 효과적으로 제어할 수 있습니다. 시스템 생성 키를 기본 키로 사용하는 또 다른 장점은 일관된 키 구조가 있을 때 논리적 결함을 쉽게 찾을 수 있다는 것입니다.
3) 사용자의 키를 사용하지 마십시오 (기본 키를 업데이트 가능하게 만들지 마십시오)
테이블의 키로 사용할 필드를 결정할 때는 편집할 필드를 조심해야 합니다. 일반적으로 사용자가 편집할 수 있는 필드를 키워드로 선택하지 마십시오.
4) 선택적 키를 기본 키로 사용할 수 있는 경우도 있습니다.
옵션 키를 기본 키로 추가로 사용하면 강력한 색인을 만들 수 있습니다.
인덱스 사용 정책:
색인은 데이터베이스에서 데이터를 가져오는 가장 효과적인 방법 중 하나입니다. 데이터베이스 성능 문제의 95% 는 인덱싱 기술을 통해 해결할 수 있습니다.
1) 논리 기본 키에 대해 고유한 그룹 인덱스를 사용하고, 시스템 키에 대해 고유한 그룹 해제된 인덱스를 저장 프로시저로 사용하고, 외래 키 열에 대해 그룹 해제된 인덱스를 사용합니다. 데이터베이스에 얼마나 많은 공간이 있는지, 테이블에 액세스하는 방법, 이러한 액세스가 주로 읽기 및 쓰기에 사용되는지 고려해 보십시오.
2) 대부분의 데이터베이스는 자동으로 생성된 키 필드를 인덱스화하지만, 외래 키를 인덱스화하는 것을 잊지 마십시오. 외래 키도 마스터 테이블과 모든 관련 테이블의 레코드를 표시하는 질의를 실행하는 것과 같은 일반적인 키입니다.
3) memo/note 필드를 인덱스화하지 말고 큰 필드 (문자가 많음) 를 인덱스화하지 마십시오. 그러면 인덱스가 저장 공간을 너무 많이 차지하게 됩니다.
4) 자주 사용하는 작은 테이블을 색인화하지 마십시오.
특히 삽입 및 삭제 작업이 자주 있는 경우 작은 데이터 테이블에 대해 키를 설정하지 마십시오. 이러한 삽입 및 삭제 작업의 인덱스 유지 관리는 스캔 테이블스페이스보다 시간이 더 오래 걸릴 수 있습니다.
4. 데이터 무결성 설계 (데이터베이스 논리 설계)
1) 무결성 구현 메커니즘:
엔티티 무결성: 기본 키
참조 무결성:
상위 테이블에서 데이터 삭제: 계단식 삭제 제한적 삭제 널 값
상위 테이블에 데이터 삽입: 제한된 삽입 재귀적 삽입
상위 테이블의 데이터 업데이트: 계단식 업데이트; 제한된 업데이트 널 값
Dbms 는 외래 키 구현 메커니즘 (제약 규칙) 과 트리거 구현 메커니즘의 두 가지 방법으로 참조 무결성을 구현할 수 있습니다.
사용자 정의 무결성:
비어 있지 않습니다. 검사; 발생
2) 비즈니스 규칙이 아닌 제약 조건을 통해 데이터 무결성을 향상시킵니다.
데이터베이스 시스템을 이용하여 데이터 무결성을 실현하다. 여기에는 표준화를 통한 무결성뿐만 아니라 데이터의 기능도 포함됩니다. 또한 데이터를 쓸 때 트리거를 추가하여 데이터의 정확성을 보장할 수 있습니다. 데이터 무결성을 보장하기 위해 비즈니스 계층에 의존하지 않습니다. 테이블 (외래 키) 간의 무결성을 보장하지 않으므로 다른 무결성 규칙에 적용할 수 없습니다.
3) 필수 지침 무결성
유해 데이터를 데이터베이스에 입력하기 전에 제거합니다. 데이터베이스 시스템에 표시된 무결성 기능을 활성화합니다. 이를 통해 데이터를 깔끔하게 유지하고 개발자가 오류 상황을 처리하는 데 더 많은 시간을 할애할 수 있습니다.
4) 조회를 사용하여 데이터 무결성을 제어합니다.
데이터 무결성을 제어하는 가장 좋은 방법은 사용자의 선택을 제한하는 것입니다. 가능한 경우 선택할 수 있는 명확한 값 목록을 사용자에게 제공해야 합니다. 이렇게 하면 코드를 입력할 때 실수와 오해가 줄어들고 데이터 일관성이 제공됩니다. 일부 공개 데이터는 국가 코드, 상태 코드 등 검색에 특히 적합합니다.
5) 관점을 채택하다
데이터베이스와 응용 프로그램 코드 사이에 또 다른 추상 계층을 제공하기 위해 응용 프로그램이 데이터 테이블에 직접 액세스하지 않고도 응용 프로그램에 대한 특수 뷰를 설정할 수 있습니다. 이렇게 하면 데이터베이스 변경 작업을 보다 자유롭게 수행할 수 있습니다.
기타 설계 기술
1) 트리거 사용을 피하십시오.
트리거 기능은 일반적으로 다른 방법으로 구현할 수 있습니다. 프로그램을 디버깅할 때 트리거가 간섭이 될 수 있습니다. 만약 네가 정말로 트리거를 사용해야 한다면, 너는 그것을 기록하는 데 집중하는 것이 좋겠다.
2) 인코딩 대신 일반 영어 (또는 기타 언어) 를 사용합니다.
드롭다운 메뉴, 목록 및 보고서를 생성할 때는 영어 이름으로 정렬하는 것이 좋습니다. 인코딩이 필요한 경우 사용자가 알고 있는 영어를 인코딩에 첨부할 수 있습니다.
3) 자주 사용하는 정보를 저장합니다
일반 데이터베이스 정보 전용 테이블을 갖는 것이 유용합니다. 이 테이블에는 데이터베이스의 현재 버전, 최신 검사/서비스 (액세스용), 관련 설계 문서의 이름, 고객 및 기타 정보가 저장됩니다. 이를 통해 데이터베이스를 추적하는 간단한 메커니즘을 구현할 수 있으며, 고객이 데이터베이스가 원하는 요구 사항을 충족하지 못한다고 불평하고 연락할 때 특히 클라이언트/서버 환경이 아닌 경우에 유용합니다.
4) 버전 메커니즘 포함
버전 관리 메커니즘이 데이터베이스에 도입되어 사용 중인 데이터베이스의 버전을 결정합니다. 시간이 지남에 따라 사용자의 요구는 항상 변한다. 결국 데이터베이스 구조를 수정해야 할 수도 있습니다. 버전 정보를 데이터베이스에 직접 저장하는 것이 더 편리합니다.
5) 문서 준비
모든 바로 가기, 명명 규칙, 제한 사항 및 기능을 기록합니다.
데이터베이스 도구를 사용하여 테이블, 열, 트리거 등에 주석을 답니다. 변경 사항을 개발, 지원 및 추적하는 데 유용합니다.
데이터베이스를 기록하거나 데이터베이스 내부 또는 별도로 문서를 작성합니다. 이렇게 1 년여 후에 네가 다시 두 번째 버전을 찾아갈 때, 실수할 확률이 크게 낮아질 것이다.
6) 테스트, 테스트 및 반복 테스트
데이터베이스를 설정하거나 수정한 후에는 사용자가 새로 입력한 데이터로 데이터 필드를 테스트해야 합니다. 가장 중요한 것은 사용자가 테스트하고 사용자와 함께 작업하여 선택한 데이터 유형이 비즈니스 요구 사항을 충족하는지 확인하는 것입니다. 새 데이터베이스를 실제 서비스에 투입하기 전에 테스트를 완료해야 합니다.
7) 설계 검토
개발 과정에서 데이터베이스 설계를 검사하는 일반적인 기술은 데이터베이스가 지원하는 애플리케이션 프로토타입을 통해 데이터베이스를 검사하는 것입니다. 즉, 데이터를 최종적으로 표현하는 각 프로토타입 응용프로그램에 대해 데이터 모형을 검토하고 데이터 추출 방법을 이해해야 합니다.