데이터베이스 설계는 주어진 애플리케이션 환경에 대한 포인터로 최적의 데이터베이스 모델을 구축하고 데이터베이스와 해당 애플리케이션 시스템을 구축하여 다양한 사용자의 애플리케이션 요구 사항 (정보 및 처리 요구 사항) 을 효과적으로 저장할 수 있도록 합니다. 데이터베이스 영역에서 데이터베이스를 사용하는 다양한 시스템을 총체적으로 데이터베이스 설계라고 하며, 지정된 애플리케이션 환경에 가장 적합한 데이터베이스 모델을 구축하고, 데이터베이스 및 애플리케이션 시스템을 구축하여 다양한 사용자의 애플리케이션 요구 사항 (정보 및 처리 요구 사항) 을 효과적으로 저장할 수 있도록 합니다. 데이터베이스 영역에서 데이터베이스를 사용하는 다양한 시스템을 데이터베이스 애플리케이션 시스템이라고 합니다. 1. 데이터베이스 및 정보 시스템 (1) 데이터베이스는 정보 시스템의 핵심이자 기초입니다. 정보 시스템의 대량의 데이터를 특정 모델에 따라 구성하고 데이터를 저장, 유지 관리 및 검색할 수 있는 기능을 제공하여 정보 시스템이 데이터베이스에서 필요한 정보를 쉽고 시기 적절하며 정확하게 얻을 수 있도록 합니다. (2) 데이터베이스는 정보 시스템의 각 부분이 어떻게 밀접하게 결합될 수 있는지의 관건이다. (3) 데이터베이스 설계는 정보 시스템 개발 건설의 중요한 구성 요소이다. (4) 데이터베이스 디자이너가 갖추어야 할 기술과 지식: 데이터베이스 및 데이터베이스 설계 기술의 기초, 컴퓨터 과학의 기초 및 프로그래밍 방법 및 기술, 소프트웨어 공학의 원리와 방법, 응용 분야의 지식. 둘째, 데이터베이스 설계의 특징. 데이터베이스 구축은 하드웨어, 소프트웨어, 건조물의 조합, 3 점 기술, 7 점 관리입니다. 기본 데이터 기술 및 관리 인터페이스를 "작업" 이라고 합니다. 데이터베이스 설계는 응용 시스템 설계와 결합되어야 합니다. 구조 (데이터) 설계: 데이터베이스 프레임워크 또는 데이터베이스 구조 동작 (처리) 설계: 응용 프로그램, 트랜잭션 등의 구조가 동작과 분리된 설계입니다. 전통적인 소프트웨어 엔지니어링은 응용 프로그램에서 데이터 의미의 분석과 추상화를 무시합니다. 가능한 한 데이터 구조 설계 결정을 연기합니다. 초기 데이터베이스 설계는 데이터 모델 및 모델링 방법 연구에 주력했으며, 동작 설계는 그림 3 에 나와 있습니다. 데이터베이스 설계 방법 소개 수동 시험 방법의 설계 품질은 설계자의 경험과 수준과 직접적인 관련이 있습니다. 과학 이론과 공사 방법의 지지가 없으면 공사의 품질을 보장하기 어렵다. 데이터베이스를 일정 기간 실행한 후 다양한 문제를 다양한 정도로 발견하는 경우가 많습니다. 유지 보수 비용 표준 설계 방법 추가 수공 디자이너의 기본적인 사고 과정은 반복적이고 점진적으로 다듬어지는 것이다. 표준설계법 (계속) 일반법: (1) 뉴올리언스법: 데이터베이스 설계는 4 단계로 나뉜다. S.b.yao 방법: 데이터베이스 설계는 5 단계로 나뉩니다. I.r.palmer 메서드: 데이터베이스 설계를 단계별 프로세스로 처리합니다. (2) 컴퓨터 지원 설계 Oracle designer 2000 Sybase powerdesigner iv. 데이터베이스 설계의 기본 단계 데이터베이스 설계 프로세스 (6 단계) 1. 수요 분석 단계에서는 데이터 및 처리를 포함한 사용자 요구 사항을 정확하게 이해하고 분석하는 것이 전체 설계 프로세스의 기초입니다. 이것은 가장 어렵고 시간이 많이 걸리는 단계이다. 개념 구조 설계 단계는 전체 데이터베이스 설계의 핵심입니다. 사용자 요구에 대한 통합, 요약 및 추상화를 통해 특정 DBMS 와 독립적인 개념 모델을 형성합니다. 3. 논리적 구조 설계 단계에서 개념 구조를 DBMS 가 지원하는 데이터 모델로 변환하여 최적화합니다. 4. 데이터베이스 물리적 설계 단계에서 논리적 데이터 모델에 대해 애플리케이션 환경에 가장 적합한 물리적 구조 (스토리지 구조 및 액세스 방법 포함) 중 하나를 선택합니다. 5. 데이터베이스 구현 단계에서 DBMS 가 제공하는 데이터 언어, 도구 및 숙주 언어를 사용합니다. 논리적 설계와 물리적 설계의 결과에 따라 데이터베이스 구축, 디버깅 애플리케이션 작성, 데이터 저장, 시운전 등을 수행합니다. 데이터베이스 시스템 운영 과정에서 우리는 지속적으로 설계 특징을 평가, 조정 및 수정해야 합니다. 즉, 설계 과정에서 데이터베이스의 설계와 데이터베이스의 데이터 처리 설계가 긴밀하게 결합되어 있습니다. 이 두 가지 측면의 요구 사항 분석, 추상화, 설계 및 구현은 각 단계에서 동시에 진행되며 상호 참조 및 보완됩니다. 설계 프로세스의 각 단계에 대한 설계 설명을 개선하기 위해 그림 5 와 같이 두 가지 측면으로 나뉩니다. 모든 수준의 데이터베이스 모델 형성 프로세스 1 수요 분석 단계: 각 사용자의 애플리케이션 수요를 통합합니다. 2. 개념 설계 단계: 기계 특성 및 DBMS 제품과 독립적인 개념 모델을 형성합니다 (e-r 다이어그램). 3. 논리적 설계 단계: 먼저 e-r 그래프를 특정 데이터베이스 제품이 지원하는 데이터 모델 (예: 관계형 모델) 으로 변환합니다. 그런 다음 사용자의 처리 요구 사항 및 보안 고려 사항에 따라 기본 테이블을 기반으로 필요한 뷰를 설정하여 데이터의 외부 패턴을 형성합니다. 4. 물리적 설계 단계: 데이터베이스 관리 시스템의 특성과 처리 요구에 따라 물리적 스토리지 배치를 수행하고 인덱스를 작성하여 데이터베이스의 내부 패턴을 형성합니다. 6. 데이터베이스 설계 기술 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() srecordcreator 이고 기본값은 SQL server 아래의 not null default? 사용자 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) 무결성 구현 메커니즘: 엔티티 무결성: 기본 키 참조 무결성: 상위 테이블에서 데이터 삭제: 계단식 삭제; 제한적 삭제 빈 상위 테이블에 데이터 삽입: 제한적 삽입 업데이트 데이터를 상위 테이블에 재귀적으로 삽입: 업데이트 계단식; 제한된 업데이트 NULDBMS 는 외래 키 구현 메커니즘 (제약 규칙) 과 트리거 구현 메커니즘 사용자 정의 무결성의 두 가지 방법으로 참조 무결성을 구현할 수 있습니다. 비 null；; 을 눌러 섹션을 인쇄할 수도 있습니다 검사; 트리거 2) 비즈니스 규칙 대신 제약 조건을 사용하여 데이터 무결성을 강제하고 데이터베이스 시스템을 사용하여 데이터 무결성을 달성합니다. 여기에는 표준화를 통한 무결성뿐만 아니라 데이터의 기능도 포함됩니다. 또한 데이터를 쓸 때 트리거를 추가하여 데이터의 정확성을 보장할 수 있습니다. 데이터 무결성을 보장하기 위해 비즈니스 계층에 의존하지 않습니다. 테이블 (외래 키) 간의 무결성을 보장하지 않으므로 다른 무결성 규칙에 적용할 수 없습니다. 3) 유해 데이터가 데이터베이스에 들어가기 전에 강제 무결성 지침에 따라 유해 데이터를 제거합니다. 데이터베이스 시스템에 표시된 무결성 기능을 활성화합니다. 이를 통해 데이터를 깔끔하게 유지하고 개발자가 오류 상황을 처리하는 데 더 많은 시간을 할애할 수 있습니다. 4) 검색을 사용하여 데이터 무결성을 제어하고 데이터 무결성을 제어하는 가장 좋은 방법은 사용자의 선택을 제한하는 것입니다. 가능한 경우 선택할 수 있는 명확한 값 목록을 사용자에게 제공해야 합니다. 이렇게 하면 코드를 입력할 때 실수와 오해가 줄어들고 데이터 일관성이 제공됩니다. 일부 공개 데이터는 국가 코드, 상태 코드 등 검색에 특히 적합합니다. 5) 뷰 사용 데이터베이스와 응용 프로그램 코드 간에 또 다른 수준의 추상화를 제공하기 위해 응용 프로그램이 데이터 테이블에 직접 액세스할 필요 없이 응용 프로그램에 대한 특수 뷰를 설정할 수 있습니다. 이렇게 하면 데이터베이스 변경 작업을 보다 자유롭게 수행할 수 있습니다. 5. 기타 디자인 팁 1) 트리거 사용을 방지하는 기능은 일반적으로 다른 방법으로 수행할 수 있습니다. 프로그램을 디버깅할 때 트리거가 간섭이 될 수 있습니다. 만약 네가 정말로 트리거를 사용해야 한다면, 너는 그것을 기록하는 데 집중하는 것이 좋겠다. 2) 인코딩 대신 일반 영어 (또는 기타 언어) 를 사용합니다. 드롭다운 메뉴, 목록 및 보고서를 생성할 때는 영어 이름으로 정렬하는 것이 좋습니다. 인코딩이 필요한 경우 사용자가 알고 있는 영어를 인코딩에 첨부할 수 있습니다. 3) 한 테이블에 일반 데이터베이스 정보를 저장할 수 있도록 자주 사용하는 정보를 저장하는 것이 유용합니다. 이 테이블에는 데이터베이스의 현재 버전, 최신 검사/서비스 (액세스용), 관련 설계 문서의 이름, 고객 및 기타 정보가 저장됩니다. 이를 통해 데이터베이스를 추적하는 간단한 메커니즘을 구현할 수 있으며, 고객이 데이터베이스가 원하는 요구 사항을 충족하지 못한다고 불평하고 연락할 때 특히 클라이언트/서버 환경이 아닌 경우에 유용합니다. 4) 데이터베이스에 버전 관리 메커니즘을 도입하여 사용 중인 데이터베이스의 버전을 결정합니다. 시간이 지남에 따라 사용자의 요구는 항상 변한다. 결국 데이터베이스 구조를 수정해야 할 수도 있습니다. 버전 정보를 데이터베이스에 직접 저장하는 것이 더 편리합니다. 5) 모든 바로 가기, 명명 규칙, 제한 사항 및 기능을 기록합니다. 데이터베이스 도구를 사용하여 테이블, 열, 트리거 등에 주석을 답니다. 변경 사항을 개발, 지원 및 추적하는 데 유용합니다. 데이터베이스를 기록하거나 데이터베이스 내부 또는 별도로 문서를 작성합니다. 이렇게 1 년여 후에 네가 다시 두 번째 버전을 찾아갈 때, 실수할 확률이 크게 낮아질 것이다. 6) 테스트, 테스트, 반복 테스트 데이터베이스 구축 또는 수정 후 데이터 필드는 사용자가 새로 입력한 데이터로 테스트해야 합니다. 가장 중요한 것은 사용자가 테스트하고 사용자와 함께 작업하여 선택한 데이터 유형이 비즈니스 요구 사항을 충족하는지 확인하는 것입니다. 새 데이터베이스를 실제 서비스에 투입하기 전에 테스트를 완료해야 합니다. 7) 설계 검사 개발 중 데이터베이스 설계를 검사하는 일반적인 기술은 데이터베이스가 지원하는 애플리케이션 프로토타입을 통해 데이터베이스를 검사하는 것입니다. 즉, 데이터를 최종적으로 표현하는 각 프로토타입 응용프로그램에 대해 데이터 모형을 검토하고 데이터 추출 방법을 이해해야 합니다.