1. 데이터베이스 디자인 개요
- 광범위하게 말하면 데이터베이스 디자인은 데이터베이스 및 해당 애플리케이션 시스템의 디자인, 즉 전체 데이터베이스 애플리케이션 시스템의 디자인입니다.
- 좁은 의미에서 : 데이터베이스 자체를 설계하는 것, 즉 모든 수준의 데이터베이스 모델을 설계하고 데이터베이스를 설정하는 것은 데이터베이스 애플리케이션 시스템 설계의 일부입니다. 의.
여기에 언급 된 데이터베이스 디자인은 좁은 의미를 나타냅니다.
데이터베이스 디자인의 정의 :
데이터베이스 설계는 주어진 애플리케이션 환경에 최적화 된 데이터베이스 논리 모드 및 물리적 구조를 구축 (설계)하고 이에 따라 데이터베이스 및 해당 애플리케이션 시스템을 구축하여 정보 관리 요구 사항을 포함한 다양한 애플리케이션 요구 사항에 맞게 데이터를 효과적으로 저장 및 관리 할 수 있도록하는 것을 말합니다. 및 데이터베이스 운영 요구 사항.
데이터베이스 디자인의 특징
- 기술 3 점, 관리 7 점, 기본 데이터 12 점 . 이것은 데이터베이스 구축의 기본 법칙이기도합니다.
"기본 데이터 12 점"은 데이터의 수집, 정렬, 구성 및 지속적인 업데이트가 데이터베이스 구축의 중요한 부분임을 강조합니다. - 구조 (데이터) 설계와 행동 (처리) 설계가 결합 됩니다. 구조적 특성에 초점을 맞춘 초기 데이터베이스 설계.
데이터베이스 설계 방법
대규모 데이터베이스 설계는 여러 분야를 포함하는 포괄적 인 기술이며 거대한 엔지니어링 프로젝트이기도합니다. 그는 데이터베이스 설계에 종사하는 전문가가 다음과 같은 다양한 지침과 기술을 보유해야합니다.
- 컴퓨터의 기본 지식
- 소프트웨어 공학의 원리와 방법
- 프로그래밍 방법 및 기술
- 데이터베이스에 대한 기본 지식
- 데이터베이스 설계 기술
- 응용 분야 지식
초기 설계 방법 : 수작업과 경험의 조합.
현재 설계 방법 : New Orleans 방법 (New Orleans), E-R모델 기반 설계 방법, 3NF(제 3 정규형) 설계 방법, 객체 지향 데이터베이스 설계 방법, UML (Unified Modeling Language) 방법.
데이터베이스 설계 단계
데이터베이스 설계 과정에서 수요 분석과 개념적 구조 설계는 어떤 데이터베이스 관리 시스템과도 독립적으로 수행 될 수 있으며, 논리적 구조 설계 및 물리적 구조 설계는 선택된 데이터베이스 관리 시스템과 밀접한 관련이 있습니다.
1. 요구 사항 분석 단계
적절하고 정확하게 수행되는지 여부는 데이터베이스 구축의 속도와 품질을 결정합니다.
2. 개념적 구조 설계 단계
사용자 요구의 통합, 유도 및 추상화를 통해 특정 데이터베이스 관리 시스템과 독립적 인 개념 모델이 형성됩니다.
3. 논리적 구조 설계 단계
개념적 구조를 데이터베이스 관리 시스템에서 지원하는 데이터 모델로 변환하고 최적화합니다.
4. 물리적 구조 설계 단계
스토리지 구조 및 액세스 방법을 포함한 논리적 데이터 구조의 애플리케이션 환경에 가장 적합한 물리적 구조 선택
5. 데이터베이스 구현 단계
논리적 설계 및 물리적 설계 결과를 기반으로 데이터베이스 구축
응용 프로그램 작성 및 디버그
데이터 저장 및 테스트 실행 구성
6. 데이터베이스 운영 및 유지 보수 단계
시운전 후 정식 운용이 가능하며 운용 중 지속적으로 평가, 조정 및 수정되어야합니다.
다음 그림은 설계 프로세스의 각 단계에서 데이터 특성에 대한 설계 설명입니다.
데이터베이스 디자인 프로세스의 모든 수준에서 패턴
다음 그림은 데이터베이스 디자인의 여러 단계에서 형성된 모든 수준의 데이터베이스 패턴을 보여줍니다.
- 수요 단계 : 각 사용자의 애플리케이션 요구 사항 통합
- 개념 설계 단계 : 기계 특성 및 각 데이터베이스 관리 시스템 제품 (ER 다이어그램)과 독립적 인 개념 모델 형성
- 논리 설계 단계 :
- 먼저 ER 다이어그램을 관계형 모델과 같은 특정 데이터베이스 제품에서 지원하는 데이터 모델로 변환하여
데이터베이스 논리 모델 을 형성합니다. - 그런 다음 사용자 처리 요구 사항 및 보안 고려 사항을 기반으로 기본 테이블을 기반으로
필요한 뷰 (View)를 설정하여 데이터의 외부 모드를 구성합니다.
- 물리적 설계 단계 :
데이터베이스 관리 시스템의 특성 및 처리 요구 사항, 물리적 스토리지 배열, 인덱싱 및 데이터베이스 모델 구성에 따라
2. 수요 분석
수요 분석은 단순히 사용자 요구 사항을 분석하는 것입니다. 데이터베이스 설계의 시작점
요구 사항 분석 작업
수요 분석의 임무는 실세계에서 처리해야 할 대상에 대한 상세한 조사를 통해 원래 시스템 (수동 시스템 또는 컴퓨터 시스템)의 작업 조건을 완전히 이해하고, 사용자의 다양한 니즈를 명확히하고, 그 기능을 결정하는 것입니다. 이를 바탕으로 새로운 시스템. 새 시스템은 향후 확장 및 변경을 완전히 고려해야합니다.
요구 분석 방법
수요 분석을 수행하려면 먼저 사용자의 실제 요구 사항을 조사하고 사용자와 합의한 다음 이러한 요구 사항을 분석하고 표현해야합니다.
사용자 요구 사항을 조사 할 단계 :
(1) 조직 구조 조사
(2) 다양한 부서의 사업 활동 조사
(3) 요구 사항, 완전성 및 완전성 요구 사항을 처리, 정보 요구 사항을 포함하여 새로운 시스템에 대한 다양한 요구 사항을 명확히하기 위해 사용자를 지원
(4 ) 새 시스템의 경계 결정
일반적인 조사 방법 :
(1) 후속
개인적으로 비즈니스 작업에 참여하여 사업 활동에 대해 배울 수있는 작업
(2) 행동 조사 회의
사용자와 토론을 통해 비즈니스 활동 및 사용자의 요구를 이해하기
(3) 사람을 소개하십시오
(4) 질문
에 대한 some 설문 조사에 대한 질문은 누군가에게 물어볼 수 있습니다.
(5) 설문지를 디자인하고 사용자에게 설문지 작성 을 요청합니다 . 설문지가
합리적으로 설계되면 매우 효과적입니다.
(6) 기록
확인 데이터 확인 원래 시스템과 관련된 기록
분석 방법 :
구조화 된 분석 방법 (Structured Analysis, SA 방법이라고 함) SA 방법은 최상위 시스템 조직에서 시작하여 하향식, 계층 별 분해 방법
을 사용하여 사용자의 요구를 분석하고 표현합니다. 분석 보고서를 사용자에게 제출하고 사용자의 승인을 받아야합니다.
요구 사항 분석 프로세스 :
데이터 사전
데이터 사전은 상세한 데이터 수집 및 데이터 분석의 주요 결과입니다. 이는 데이터 자체가 아니라 데이터베이스의 데이터, 즉 메타 데이터에 대한 설명입니다. 데이터 사전은 요구 사항 분석 단계에서 설정되며 데이터베이스 설계 프로세스 중에 지속적으로 수정, 보강 및 완성됩니다.
데이터 사전에는 일반적으로 데이터 항목, 데이터 구조, 데이터 흐름, 데이터 저장 및 처리 절차가 포함됩니다. 데이터 항목은 가장 작은 데이터 단위이며 여러 데이터 항목이 데이터 구조를 형성 할 수 있습니다. 데이터 사전은 데이터 항목 및 데이터 구조의 정의를 통해 데이터 흐름 및 데이터 저장의 논리적 내용을 설명합니다.
데이터 항목
데이터 항목은 세분화 할 수없는 데이터 단위입니다. 데이터 항목에 대한 설명에는 일반적으로 다음이 포함됩니다.
数据项描述={数据项名,数据项含义说明,别名,
数据类型,长度,取值范围,取值含义,
与其他数据项的逻辑关系,
数据项之间的联系}
데이터 항목에 대한 간단한 이해는 테이블의 필드입니다.
데이터 구조
데이터 구조는 데이터 조합을 반영합니다. 데이터 구조는 여러 데이터 항목, 여러 데이터 구조 또는 여러 데이터 항목과 데이터 구조의 혼합으로 구성 될 수 있습니다.
数据结构描述={数据结构名，含义说明，组成:{数据项或数据结构}}
데이터 흐름
데이터 스트림은 데이터 구조가 시스템에서 전송되는 경로입니다.
数据流描述={数据流名,说明,数据流来源,
数据流去向,组成:{数据结构},
平均流量,高峰期流量}
- 데이터 흐름 소스 : 데이터 흐름의 출처를 나타냅니다.
- 데이터 흐름 대상 : 데이터 흐름이 이동할 프로세스를 나타냅니다.
- 평균 트래픽 : 단위 시간당 전송 횟수 (매일, 매주, 매월 등)
- 피크 트래픽 : 피크 기간 동안의 데이터 트래픽
정보 저장소
데이터 저장소는 데이터 구조가 유지되거나 저장되는 장소이며 데이터 흐름의 원본 및 대상 중 하나이기도합니다.
数据存储描述={数据存储名,说明,编号,输
入的数据流 ,输出的数据流,
组成:{数据结构},数据量,
存取频度,存取方式}
- 액세스 빈도 : 시간, 일 또는 주당 액세스 수, 매번 액세스 한 데이터 양 및 기타 정보
- 액세스 방법 : 일괄 처리 / 온라인 처리, 검색 / 업데이트, 순차 검색 / 무작위 검색
- 입력 데이터 스트림 : 데이터 소스
- 출력 데이터 흐름 : 데이터가가는 곳
방법
처리 프로세스의 특정 처리 논리는 일반적으로 결정 테이블 또는 결정 트리에 의해 설명됩니다. 데이터 사전에는 처리 프로세스를 설명하는 설명 정보 만 필요합니다.
处理过程描述={处理过程名,说明,输入:{数据流},
输出:{数据流},处理:{简要说明}}
간략한 설명 : 처리 프로세스의 기능 및 처리 요구 사항을 설명합니다.
- 기능 : 사용되는 프로세스는 무엇입니까
- 처리 요구 사항 : 단위 시간당 처리되는 트랜잭션 수, 데이터 양, 응답 시간 요구 사항 등과 같은 처리 빈도 요구 사항
- 처리 요구 사항은 후속 물리적 설계에 대한 입력 및 성능 평가 기준입니다.
3. 개념적 구조 설계
니즈 분석에서 얻은 사용자 니즈를 정보 구조 (개념적 모델)로 추상화하는 과정은 개념적 구조 설계입니다.
개념적 모델
요구 사항 분석 단계에서 얻은 애플리케이션 요구 사항은 먼저 정보 세계의 구조로 추상화되어야하며, 그런 다음 특정 데이터베이스 관리 시스템을 사용하여 이러한 요구 사항을보다 정확하고 정확하게 달성 할 수 있습니다.
개념 모델의 주요 기능 :
- 트랜잭션과 트랜잭션 간의 연결을 포함하여 실제 세계를 진정으로 완전히 반영 할 수 있고 사용자의 데이터 처리 요구 사항을 충족 할 수있는 실제 세계의 진정한 모델입니다.
- 이해하기 쉽고 컴퓨터에 익숙하지 않은 사용자와 의견을 교환 할 수 있습니다.
- 변경하기 쉽고, 수정하기 쉬우 며, 애플리케이션 환경 및 애플리케이션 요구 사항이 변경 될 때 개념 모델을 확장합니다.
- 관계, 메쉬, 계층과 같은 다양한 데이터 모델로 쉽게 변환 할 수 있습니다.
ER 모델
ER 모델은 개념적 모델을 설명하는 강력한 도구입니다.
엔티티 간의 링크
엔터티 간의 연결에는 두 엔터티 간의 연결 (이진 연결), 두 개 이상의 엔터티 간의 연결 (n-ary 연결), 단일 엔터티 간의 연결 (아버지와 자식)이 포함됩니다.
ER 图
ER 다이어그램은 엔티티 유형, 속성 및 연결을 나타내는 방법을 제공합니다.
- 엔티티 유형은 직사각형으로 표시되고 엔티티 이름은 직사각형으로 작성됩니다.
- 속성은 타원으로 표시되고 방향이 지정되지 않은 모서리는 해당 엔티티와 연결하는 데 사용됩니다.
- 연락처는 마름모로 표시되며, 연락처의 이름은 마름모로 작성되며, 방향이없는 쪽 옆에 연락처 유형 (1 : 1, 1 : n 또는 m : n)이 표시됩니다.
개념적 구조 설계
개념적 구조 설계의 첫 번째 단계는 요구 사항 분석 단계에서 수집 된 데이터를 분류 및 구성하고 엔터티의 속성, 엔터티 클래스 및 엔터티 간의 연결 유형을 결정하는 것입니다.
1. 엔티티 및 속성 분할 규칙
ER 다이어그램의 처리를 단순화하기 위해 실제 트랜잭션을 가능한 한 속성으로 처리 할 수 있습니다.
속성으로 취급되는 트랜잭션에 대해 충족되는 조건은 무엇입니까? 두 가지 규칙 :
作为属性，不能再具有需要描述的性质즉, 속성은 분할 할 수없는 속성 항목 (1NF)이어야하며 다른 속성을 포함 할 수 없습니다.属性不能与其他实体具有联系즉, ER 다이어그램은 속성과 다른 항목 또는 속성 간의 관계가 아니라 항목 간의 관계를 보여줍니다.
2. ER 다이어그램 통합
대규모 정보 시스템을 개발할 때 가장 자주 채택되는 전략은 하향식 요구 사항 분석과 상향식 개념 구조 설계입니다. 즉, 먼저 각 하위 시스템의 하위 ER 다이어그램을 디자인 한 다음 (다른 팀에서 디자인 할 수 있음)이를 통합하여 글로벌 ER 다이어그램을 얻습니다. 통합은 일반적으로 두 단계로 나뉩니다. 1. 충돌을 병합하고 해결합니다. 2. 수정 및 재구성
1. 충돌 해결을위한 병합
각 하위 시스템의 ER 다이어그램의 ER 다이어그램 간에는 속성 충돌, 이름 지정 충돌 및 구조적 충돌의 세 가지 주요 유형의 충돌이 있습니다.
① 속성 충돌
- 속성 도메인 충돌, 즉 속성 값 유형, 값 범위 또는 값 세트가 다릅니다.
- 속성 값 단위가 충돌합니다. 예를 들어, 부품의 무게는 킬로그램 또는 그램 일 수 있습니다.
② 이름 충돌 - 다른 의미를 가진 동일한 이름, 즉 다른 의미를 가진 객체가 다른 로컬 응용 프로그램에서 동일한 이름을 가짐
- 다른 이름은 동일한 의미 (하나의 의미를 가진 여러 이름)를 갖습니다. 즉, 동일한 의미를 가진 객체는 다른 로컬 응용 프로그램에서 다른 이름을 갖습니다.
③ 구조적 갈등 - 동일한 객체는 다른 응용 프로그램에서 다른 추상화를 가지고 있습니다. 예를 들어 직원은 한 부분 응용 프로그램에서는 엔티티로 취급되지만 다른 부분 응용 프로그램에서는 속성으로 취급됩니다.
- 동일한 엔티티의 서로 다른 서브 시스템의 ER 다이어그램에있는 속성 수와 속성 배열 수는 정확히 동일하지 않습니다.
- 엔티티 연결은 다른 ER 다이어그램에서 다른 유형입니다. 예를 들어, E1과 E2는 ER 다이어그램에서 다 대다 관계에 있고 다른 ER 다이어그램에서 E1, E2 및 E3은 다 대다 관계에 있습니다.
2. 불필요한 중복 제거
소위 중복성은 기본 데이터에서 파생 될 수있는 데이터를 의미합니다. 때로는 효율성을 향상시키기 위해 중복성을 제거하지 못할 수 있습니다.
4. 논리적 구조 설계
논리적 구조 설계는 개념적 구조 설계 단계에서 설계 한 기본 ER 다이어그램을 데이터베이스 관리 시스템 제품에서 지원하는 데이터 모델과 일치하는 논리적 구조로 변환하는 것입니다.
ER 다이어그램을 관계형 모델로 변환
ER 다이어그램을 관계형 모델로 변환 할 때 해결해야 할 문제는 엔티티 간의 연결을 관계형 패턴으로 변환하는 방법과 이러한 관계형 패턴의 속성 및 코드를 결정하는 방법입니다. 변환의 일반 원칙은 엔티티가 관계형 모델로 변환된다는 것입니다.
데이터 모델 최적화
데이터베이스 논리 설계의 결과는 고유하지 않습니다. 데이터베이스 응용 시스템의 성능을 더욱 향상시키기 위해서는 데이터 모델의 구조를 응용에 따라 적절하게 수정 및 조정해야합니다. 관계형 모델의 최적화는 일반적으로 세 번째 정규 형식과 같은 정규화 이론에 의해 안내됩니다. 그러나 표준화가 높을수록 관계가 더 좋습니다.
사용자 하위 패턴 디자인
개념 모델을 글로벌 로직 모델로 변환 한 후 사용자의 외부 모델은 로컬 애플리케이션 요구 사항과 특정 관계형 데이터베이스 관리 시스템의 특성에 따라 설계되어야합니다. 예를 들어 SQL 관계형 데이터베이스에서는 뷰를 사용하여 외부를 설계 할 수 있습니다. 지역 사용자의 요구를 더 잘 충족하는 모델.
외부 모드를 정의 할 때 여러 측면을 포함하여 사용자의 습관과 편의성에주의를 기울일 수 있습니다.
- 사용자 습관에 더 부합하는 별칭 사용
- 시스템의 보안을 보장하기 위해 서로 다른 레벨의 사용자에 대해 서로 다른보기를 정의 할 수 있습니다.
- 사용자의 시스템 사용을 단순화합니다.
5. 물리적 구조 설계
물리적 장치에있는 데이터베이스의 저장 구조 및 액세스 방법을 데이터베이스의 물리적 구조라고하며 선택한 데이터베이스 관리 시스템에 따라 다릅니다. 주어진 논리적 데이터 모델에 대한 애플리케이션 요구 사항에 가장 적합한 물리적 구조를 선택하는 프로세스는 데이터베이스의 물리적 설계입니다.
주로 다음 두 단계로 나뉩니다.
- 데이터베이스의 물리적 구조를 결정합니다. 관계형 데이터베이스에서는 주로 액세스 방법 및 액세스 구조를 나타냅니다.
- 시간 및 공간 효율성에 초점을 맞춘 물리적 구조 평가
데이터베이스 물리적 설계의 내용 및 방법
서로 다른 데이터베이스 제품이 제공하는 물리적 환경, 접근 방식 및 접근 구조가 매우 다르기 때문에 따라야 할 일반적인 설계 방법이 없으며 일반적인 설계 내용과 원칙 만 부여 할 수 있습니다.
일반적으로 관계형 데이터베이스의 물리적 설계의 주요 내용에는 관계형 모드의 액세스 방법 선택과 설계 관계 및 색인과 같은 데이터베이스 파일의 물리적 저장 구조가 포함됩니다 .
관계형 모드 액세스 방법 선택
데이터베이스 시스템은 다중 사용자 공유 시스템이며 다중 사용자의 다중 애플리케이션 요구 사항을 충족하려면 동일한 관계에 대해 다중 액세스 경로를 설정해야합니다. 물리적 구조 설계의 작업 중 하나는 데이터베이스 시스템의 지원에 따라 어떤 액세스 방법을 선택하는 것입니다.
일반적으로 사용되는 액세스 방법은 인덱싱 및 클러스터링입니다. B + 트리 인덱스 및 해시 인덱스는 고전적인 데이터베이스 액세스 방법이며 가장 일반적으로 사용됩니다.
1. B + 트리 인덱스 저장 방법 선택
소위 인덱스 저장 방법은 실제로 인덱싱 할 관계의 속성 열, 인덱싱 할 인덱스 열 및 응용 프로그램 요구 사항에 따라 고유하게 인덱싱 할 열을 결정하는 것입니다. 일반적으로 다음과 같습니다.
- 속성 (또는 그룹)이 쿼리 조건에 자주 나타나는 경우이 (열 또는 그룹) 속성에 대한 색인 (또는 복합 색인)을 설정하는 것이 좋습니다.
- 속성이 최대 값 및 최소값과 같은 집계 함수의 매개 변수로 자주 사용되는 경우이 속성에 대한 색인 설정을 고려하십시오.
- 속성 (또는 그룹)이 연결 또는 연결 작업의 연결 조건에 자주 나타나는 경우이 속성 (또는이 그룹)을 고려하여 인덱스를 작성하십시오.
지수의 정의는 가능한 한 많지 않으며, 더 많은 지수가있을 경우 시스템은 지수를 유지하기 위해 막대한 대가를 지불해야합니다. 예를 들어 업데이트 빈도가 높은 속성은 너무 많은 인덱스를 빌드하는 데 적합하지 않습니다.
2. 해시 인덱스 접근 방식 선택
해시 접근 방법을 선택하는 규칙은 다음과 같다. 관계의 속성이 주로 등가 연결 조건에 나타나거나 등가 비교 선택에 주로 나타나고 다음 두 가지 조건이 충족되면 해시 저장 방법을 선택할 수있다. 이 관계.
- 관계의 크기는 예측 가능하고 일정합니다.
- 관계의 크기는 동적으로 변경되지만 데이터베이스 관리 시스템은 동적 해시 저장 방법을 제공합니다.
3. 클러스터 액세스 방법 선택
특정 속성 (또는 속성 그룹)의 쿼리 속도를 향상시키기 위해이 속성 또는 이러한 속성 (클러스터링 코드라고 함)에 대해 동일한 값을 가진 튜플은 클러스터링이라는 연속 물리적 블록에 집합 적으로 저장됩니다. 이 속성 (또는 속성 그룹)을 클러스터 키라고합니다.
데이터베이스의 저장소 구조 결정
데이터베이스의 물리적 구조를 결정하는 것은 주로 관계, 인덱스, 클러스터, 로그, 백업 등의 저장 배열 및 저장 구조를 결정하고 시스템 구성을 결정하는 것을 포함하여 데이터베이스의 저장 위치 및 저장 구조를 결정하는 것을 의미합니다.
물리적 구조 평가
데이터베이스의 물리적 설계 과정에서 시간 효율성, 공간 효율성, 유지 보수 비용 및 다양한 사용자 요구 사항을 평가해야하므로 다양한 솔루션을 생산할 수 있습니다. 최상의 솔루션을 선택하십시오.
6. 데이터베이스 구현 및 유지 관리
데이터베이스의 물리적 설계를 완료 한 후 설계자는 관계형 데이터베이스 관리 시스템 및 기타 응용 프로그램에서 제공하는 데이터 정의 언어를 사용하여 데이터베이스 논리적 설계 및 물리적 설계 결과를 엄격하게 설명해야합니다.이를 관계형 데이터베이스의 허용 가능한 소스 코드라고합니다. 디버깅 후 대상 모드가 생성되고 데이터를 데이터베이스에 저장할 수 있습니다. 숫자는 데이터베이스 구현 단계입니다.
데이터베이스 운영 단계에서 데이터베이스의 정기 유지 관리는 주로 데이터베이스 관리자가 완료하며 주로 다음과 같은 측면을 포함합니다.
- 데이터베이스 덤프 및 복원
- 데이터베이스 보안 및 무결성 제어
- 데이터베이스 성능 모니터링, 분석 및 수정
- 데이터베이스의 재구성 및 재구성.