2.1. 컨셉 디자인
데이터베이스 설계는 세 단계로 수행됩니다.
- 컨셉 디자인;
- 논리적 설계;
- 물리적 디자인.
개념 설계 단계 의 목적은 주제 영역에 대한 사용자의 아이디어를 기반으로 개념 데이터 모델을 생성하는 것입니다. 이를 달성하기 위해 일련의 순차적 절차가 수행됩니다. 엔터티(개념적) 스키마의 예:
1. 엔티티의 정의 및 해당 문서. 엔터티를 식별하기 위해 다른 개체와 독립적으로 존재하는 개체를 정의합니다. 이러한 개체는 엔터티입니다. 각 엔터티에는 사용자가 이해할 수 있는 의미 있는 이름이 지정됩니다. 엔터티의 이름과 설명은 데이터 사전에 입력됩니다. 가능한 경우 각 엔터티의 예상 인스턴스 수를 설정합니다.
2. 엔티티와 해당 문서 간의 관계 결정. 데이터베이스 디자인 요구 사항을 충족하는 데 필요한 엔터티 간의 관계만 정의됩니다. 각각의 유형이 설정됩니다. 엔터티의 멤버십 클래스가 공개됩니다. 링크에는 동사로 표현되는 의미 있는 이름이 할당됩니다. 연결에 참여하는 엔터티의 유형 및 소속 클래스를 나타내는 각 연결에 대한 자세한 설명이 데이터 사전에 입력됩니다.
3. 주제 영역의 ER 모델 생성. ER 다이어그램은 엔터티와 엔터티 간의 관계를 나타내는 데 사용됩니다. 이를 기반으로 모델링된 주제 영역의 단일 시각적 이미지(주제 영역의 ER 모델)가 생성됩니다.
4. 속성 정의 및 문서화. 생성된 ER 모델의 엔터티를 설명하는 모든 속성이 표시됩니다. 각 속성에는 사용자가 이해할 수 있는 의미 있는 이름이 지정됩니다. 다음 정보는 각 속성에 대한 데이터 사전에 저장됩니다.
- 속성 이름 및 설명
- 값의 유형 및 차원
- 속성의 기본값(있는 경우).
- 속성이 NULL 값을 가질 수 있는지 여부;
- 속성이 복합인지 여부, 복합인 경우 구성되는 단순 속성. 예를 들어 "클라이언트의 전체 이름" 속성은 "성", "이름", "성명"이라는 단순한 속성으로 구성되거나 "Sidorsky Evgeniy Mikhailovich"와 같이 단일 값을 포함하는 단순한 속성일 수 있습니다. 사용자가 "이름"의 개별 요소에 액세스할 필요가 없는 경우 속성은 단순하게 표시됩니다.
- 속성이 계산되는지 여부 및 계산되는 경우 해당 값이 계산되는 방법.
5. 속성 값의 정의 및 해당 문서. ER 모델에 참여하는 엔티티의 각 속성에 대해 유효한 값 세트가 결정되고 이름이 지정됩니다. 예를 들어 "계정 유형" 속성은 "예금", "현재", "주문형", "카드 계정" 값만 가질 수 있습니다. 속성과 관련된 데이터 사전 항목은 속성 값 세트의 이름으로 업데이트됩니다.
6. 엔티티의 기본 키 정의 및 해당 문서. 이 단계는 인스턴스의 고유한 식별을 허용하는 엔터티의 속성 또는 속성 집합인 기본 키의 정의에 따라 안내됩니다. 기본 키 정보는 데이터 사전에 배치됩니다.
7. 최종 사용자와 개념적 데이터 모델에 대한 토론. 개념적 데이터 모델은 개발된 데이터 모델에 대한 설명이 포함된 문서와 함께 ER 모델로 표현됩니다. 도메인 불일치가 발견되면 사용자가 제안한 모델이 개인 견해를 적절하게 반영하는지 사용자가 확인할 때까지 모델을 변경합니다.
2.2 로직 설계
논리적 설계 단계의 목적은 선택된 데이터 모델을 기반으로 한 개념적 모델을 추후 데이터베이스의 물리적 구현을 위해 사용되는 DBMS의 기능과 독립적인 논리적 모델로 변환하는 것입니다. 이를 달성하기 위해 다음 절차가 수행됩니다.
논리적 데이터베이스 스키마의 예입니다.
1. 데이터 모델 선택. 대부분의 경우 관계형 데이터 모델은 데이터 표 형식의 명확성과 작업 편의성으로 인해 선택됩니다.
2. ER 모델을 기반으로 테이블 집합을 정의하고 문서화합니다. ER 모델의 각 엔터티에 대해 테이블이 생성됩니다. 엔터티 이름은 테이블의 이름입니다. 테이블 간의 관계는 기본 및 외래 키 메커니즘을 통해 설정됩니다. 테이블의 구조와 이들 사이의 확립된 관계가 문서화됩니다.
3. 테이블의 정규화. 정규화를 제대로 수행하려면 디자이너가 데이터의 의미와 사용 패턴을 깊이 이해해야 합니다. 이 단계에서 정규화 절차를 테이블에 적용하여 이전 단계에서 생성한 테이블 구조의 정확성을 확인합니다. 각 테이블을 적어도 세 번째 NF로 가져오는 것으로 구성됩니다. 정규화의 결과 매우 유연한 데이터베이스 디자인이 얻어지므로 필요한 확장을 쉽게 만들 수 있습니다.
4. 사용자가 제공하는 모든 트랜잭션 수행 가능성에 대한 논리적 데이터 모델 확인. 트랜잭션은 개별 사용자 또는 응용 프로그램이 데이터베이스의 내용을 변경하기 위해 수행하는 작업 집합입니다. 따라서 BANK 프로젝트에서 트랜잭션의 예는 특정 고객의 계정 관리 권한을 다른 고객에게 양도하는 것일 수 있습니다. 이 경우 한 번에 여러 데이터베이스를 변경해야 합니다. 트랜잭션 중에 컴퓨터가 충돌하면 일부 변경 사항은 이미 적용되었고 다른 변경 사항은 적용되지 않았기 때문에 데이터베이스는 일관성 없는 상태가 됩니다. 따라서 데이터베이스를 이전의 일관된 상태로 되돌리려면 모든 부분 변경을 실행 취소해야 합니다.
트랜잭션 목록은 주제 영역에서 사용자의 작업에 따라 결정됩니다. ER 모델, 데이터 사전 및 기본 키와 외래 키 사이의 확립된 관계를 사용하여 필요한 모든 데이터 액세스 작업을 수동으로 수행하려고 시도합니다. 수동 작업이 실패하면 컴파일된 논리적 데이터 모델이 부적절하고 제거해야 하는 오류가 포함된 것입니다. 아마도 엔터티, 관계 또는 특성 모델의 차이와 관련이 있을 수 있습니다.
5. 데이터 무결성 지원 요구 사항 및 해당 문서의 결정. 이러한 요구 사항은 충돌하는 데이터가 데이터베이스에 입력되는 것을 방지하기 위해 적용되는 제한 사항입니다. 이 단계에서는 구현의 특정 측면에 관계없이 데이터 무결성 문제를 다룹니다. 다음 유형의 제한 사항을 고려해야 합니다.
- 필요한 데이터. NULL 값을 가질 수 없는 속성이 있는지 확인합니다.
- 속성 값에 대한 제한. 속성의 유효한 값이 정의됩니다.
- 엔티티 무결성. 엔터티의 기본 키에 NULL 값이 포함되어 있지 않으면 달성됩니다.
- 참조 무결성. 외래 키 값은 상위 엔터티에 대한 테이블 행 중 하나의 기본 키에 있어야 합니다.
- 비즈니스 규칙에 의해 부과된 제한. 예를 들어 BANK 프로젝트의 경우 클라이언트가 세 개 이상의 계정을 관리하지 못하도록 하는 규칙을 채택할 수 있습니다.
설정된 모든 데이터 무결성 제약 조건에 대한 정보는 데이터 사전에 배치됩니다.
6. 논리적 데이터 모델의 최종 버전 생성 및 사용자와의 토론. 이 단계는 논리적 데이터 모델을 나타내는 ER 모델의 최종 버전을 준비합니다. 모델 자체와 업데이트된 문서(데이터 사전 및 관계형 테이블 링크 스키마 포함)는 주제 영역을 정확하게 나타내는지 확인해야 하는 사용자의 검토 및 분석을 위해 제공됩니다.
2.3. 물리적 디자인
물리적 설계 단계의 목적은 컴퓨터의 외부 메모리에 있는 데이터베이스의 특정 구현을 설명하는 것입니다. 이것은 데이터 저장소 구조와 데이터베이스 데이터에 액세스하는 효율적인 방법에 대한 설명입니다. 논리적 설계에서는 무엇을 해야 하는지에 대한 질문에 답하고 물리적 설계에서는 이를 수행하는 방법을 선택합니다. 물리적 설계 절차는 다음과 같습니다.
1. 선택된 DBMS를 사용하여 데이터베이스 테이블을 설계합니다. 머신 미디어에서 호스팅되는 데이터베이스를 생성하는 데 사용할 관계형 DBMS가 선택되었습니다. 테이블 디자인을 위한 기능이 깊이 연구되었습니다. 그런 다음 DBMS 환경에서 테이블 설계 및 연결 체계가 수행됩니다. 준비된 데이터베이스 프로젝트는 함께 제공되는 문서에 설명되어 있습니다.
2. 선택된 DBMS의 환경에서 비즈니스 규칙 구현. 테이블의 정보 업데이트는 비즈니스 규칙에 의해 제한될 수 있습니다. 구현 방식은 선택한 DBMS에 따라 다릅니다. 주제 영역의 요구 사항을 구현하기 위한 일부 시스템은 더 많은 기능을 제공하고 다른 시스템은 덜 제공합니다. 일부 시스템에서는 비즈니스 규칙 구현을 전혀 지원하지 않습니다. 이 경우 응용 프로그램은 제한 사항을 구현하기 위해 개발됩니다.
도메인 비즈니스 규칙의 구현과 관련하여 내려진 모든 결정은 함께 제공되는 문서에 자세히 설명되어 있습니다.
3. 데이터베이스의 물리적 구성 설계. 이 단계에서는 테이블에 가장 적합한 파일 구성을 선택합니다. 설계 중인 데이터베이스에서 수행될 트랜잭션이 식별되고 가장 중요한 트랜잭션이 강조 표시됩니다. 트랜잭션 처리량 - 주어진 시간 간격으로 처리할 수 있는 트랜잭션 수 및 응답 시간 - 하나의 트랜잭션을 완료하는 데 필요한 시간을 분석합니다. 트랜잭션 처리량을 늘리고 응답 시간을 줄이기 위해 노력합니다.
이러한 지표를 기반으로 데이터베이스에서 데이터 선택 속도를 높이는 테이블에 인덱스를 정의하거나 테이블 정규화 수준에 대한 요구 사항을 줄임으로써 데이터베이스 성능을 최적화하기 위한 결정이 내려집니다. 생성된 데이터베이스를 수용하는 데 필요한 디스크 공간이 예상됩니다. 최소화하기 위해 노력합니다.
위의 문제에 대한 결정은 문서화됩니다.
4. 데이터베이스 보호 전략 개발. 데이터베이스는 귀중한 기업 리소스이며 보호에 많은 주의를 기울입니다. 이를 위해 설계자는 선택한 DBMS가 제공하는 모든 보호 기능을 완전하고 명확하게 이해해야 합니다.
5. 데이터베이스 기능 모니터링 구성 및 조정. 데이터베이스의 물리적 프로젝트 생성 후 기능에 대한 지속적인 모니터링이 구성됩니다. 데이터베이스의 성능 수준에 대한 결과 정보는 이를 조정하는 데 사용됩니다. 이를 위해 선택된 DBMS의 수단도 관련됩니다.
작동하는 데이터베이스를 변경하기 위한 결정은 철저히 고려하고 평가해야 합니다.