데이터베이스 설계의 기본 작업

1.1 소개

데이터베이스 설계는 Java 프로젝트의 아키텍처 설계와 다소 유사합니다. 모든 데이터를 몇 개의 테이블에 넣거나 스키마와 수십 개의 테이블에서 아름다운 데이터 구조를 구축할 수 있습니다.

다음은 개발자가 데이터베이스를 설계할 때 일반적으로 직면하는 작업입니다.

1. 필요한 모든 정보가 데이터베이스에 저장되어 있는지 확인합니다.
2. 필요한 모든 요청에 ​​대한 데이터를 얻을 수 있는 가능성을 보장합니다.
3. 데이터의 중복 및 중복을 줄입니다.
4. 데이터베이스 무결성 보장
5. 데이터 액세스 속도 최적화

기억해야 할 주요 사항은 이상적인 데이터베이스 구조를 만들 수 없다는 것입니다. 코드와 마찬가지로 지속적으로 변경됩니다. 데이터베이스 구조를 설계할 때 염두에 두어야 할 세 가지 사항이 있습니다.

1. 구조가 충분히 좋아야 합니다.
2. 다른 사람들이 이해할 수 있는 모든 것에는 논리가 있어야 합니다.
3. 성급한 최적화는 모든 악의 근원입니다.

세계 최고의 데이터베이스 구조를 만들 필요는 없습니다 . 그녀는 여전히 변할 것입니다. 귀하의 임무는 데이터베이스 구조를 20번 변경한 후 쉽게 파악할 수 있도록 하는 것입니다.

대부분 작업의 첫 해에는 처음부터 기반을 설계한다고 아무도 믿지 않을 것입니다. 기존 스키마를 변경하게 됩니다. 어떤 원칙에 따라 배열 되어 있는지 이해하고 준수해야 합니다 . 헌장으로 그들은 다른 사람의 수도원에 올라가지 않습니다.

필요할 때까지 데이터베이스를 최적화하지 마십시오 . 테이블에 수백 개의 행만 있는 경우 DBMS가 테이블을 메모리에 보관하고 쿼리를 캐시할 가능성이 높습니다.

반면에 중요한 요청의 작업 속도를 수십 또는 수백 배까지 높일 수 있어야 합니다. 그리고 그것을하는 방법을 안다면 좋을 것입니다. 고등학교 1학년 때 어떻게 말할까요? "학교에서 배운 모든 것을 잊어라..."

데이터베이스 정규화가 무엇인지 알고 있다면 서둘러 기쁘게 생각합니다. 귀하의 작업에서 비정규화를 다룰 가능성이 큽니다 . 데이터베이스의 속도보다 프로젝트의 성소에 더 중요한 것은 없습니다. 그리고 데이터베이스에서 데이터 선택 속도를 높이기 위해 200(!) 테이블을 하나로 결합해야 하는 경우(엄청난 중복성 포함) 이렇게 해야 합니다.

1.2 도서관 디자인

주제 영역에 대해 좀 더 자세히 살펴보고 일반적인 도서 라이브러리와 같은 간단한 것을 사용하여 데이터베이스 설계에 대해 생각해 봅시다.

모든 도서관의 주요 임무는 도서 기금 처리입니다. 독자, 사서, 관리자 의 세 가지 주요 시스템 사용자 그룹을 쉽게 구분할 수 있습니다 . 각각의 활동은 사용 사례 다이어그램에 표시됩니다.

이미 미래 데이터베이스의 일부 엔터티 및 관계를 구별할 수 있습니다.

이 접근 방식에서는 독자와 책을 어떻게 연결해야 할지 명확하지 않습니다. 책을 한 권으로 이해하면 현재 독자의 책 목록에 저장하면 누가 (그리고 몇 번)이 책을 더 일찍 가져 갔는지에 대한 정보를 얻을 수 없습니다.

해결책은 책을 발행하기 위한 카드와 같은 추가 개체를 도입하는 것일 수 있습니다. 책이 독자에게 발행되면 카드가 생성되고 책이 전달되면 그에 해당하는 마크가 붙습니다. 이 카드의 도움으로 각 사용자의 부채가 결정되고 책 사용에 대한 통계가 계산됩니다. 독자가 문헌을 예약할 때 카드도 발동되며, 도서가 일정 기간 내에 독자가 도서를 가져가지 않으면 카드가 파기된다. 독자가 예약할 수 있는 책의 수에는 제한이 있습니다.

문헌을 선택하면 사용자는 저자, 제목, 발행 연도별로 검색 결과를 필터링할 수 있는 문헌 목록을 볼 수 있습니다.

도서관에 있는 모든 책에 대한 통계를 계산할 수 있으며 주어진 기간 동안의 책 발행 부수를 계산할 수 있습니다. 계산이 수행되는 최소 책 인스턴스 수를 설정할 수도 있습니다. 이러한 통계에 따라 미사용 도서는 도서관에서 폐기됩니다.

주제 영역의 다음 주요 엔터티를 구분할 수 있습니다.

• 사용자 (사서 및 관리자);
• 리더;
• 독서실;
• 책;
• 도서 발행 카드;
• 예약카드.

데이터베이스의 수정된 ER 다이어그램이 그림에 표시됩니다.

그림 1에 표시된 사용 사례에 따르면 데이터베이스는 다음 쿼리를 구현해야 합니다(전체 목록이 아님).

• 지정된 조건과 일치하는 책을 표시합니다.
• 정시에 닫히지 않은 책 발행 카드를 가진 사용자를 표시합니다 (사서는 채무자를 찾고 있습니다).
• 제 시간에 닫히지 않은 주어진 사용자의 책 대출 카드에 해당하는 모든 책을 표시합니다 (사용자가 새 책을 위해 도서관에 왔습니다-그가 채무자인지 확인하고 그에 대해 알려야 함)
• N초 전에 생성된 모든 예약 카드를 삭제합니다.
• 지정된 사용자의 미완성 도서 예약 카드에 해당하는 모든 도서를 표시합니다(독자가 도서를 주문하고 도서관에 옴 - 사서가 이 목록을 제공하려면 이 목록을 가져와야 함).

1.3 스키마 형성

데이터 스키마를 구성하려면 먼저 엔터티의 세부 정보로 ER 다이어그램을 보완(정제)해야 합니다. 때로는 동시에 ER 다이어그램을 구성하는 오류를 찾을 수 있습니다. 이 작업에서 책이 도서관 홀과 "어떻게든" 연결될 필요가 있음을 발견했습니다.

이는 필요한 "홀 번호"를 책에 배치하여 수행할 수 있지만 이 접근 방식을 사용하면 동일한 책이 데이터베이스에 여러 번 설명되어야 합니다(서로 다른 홀에서 발생하는 경우). 보다 정확한 접근 방식은 추가 엔터티 "도서 배치"를 도입하는 것입니다. 그림은 엔터티와 소품이 추가된 ER 다이어그램을 보여줍니다.

위의 ER 다이어그램은 기본 테이블, 관계 및 속성을 반영하며 이를 기반으로 데이터베이스 모델을 구축할 수 있습니다. ER 다이어그램에 대한 표준은 없지만 많은 표기법(Chen, IDEFIX, Martin 등)이 있지만 도메인 모델에 대한 표준도 표기법도 찾을 수 없습니다. 그러나 이러한 다이어그램을 구성하는 과정에서 키 필드(외부 및 내부)가 반드시 강조 표시되며 때로는 인덱스 및 데이터 유형이 표시됩니다.

이 경우 다음 다이어그램에서:

• 링크의 경우 Martin의 표기법("까마귀 발"이 사용됨);
• 테이블은 3개 섹션으로 나누어진 직사각형으로 표시됩니다.
• 테이블 이름;
• 내부 키(마커로 표시됨)
• 나머지 필드는 필수 필드에 마커로 표시됩니다.

이 모델을 개발할 때 관리자 테이블을 사서 테이블과 조인하려는 욕구가 있었습니다. 그러나 사용자 테이블을 추가하십시오.

• 관리자가 특정 회의실과 연결되어 있지 않습니다(해당 필드를 null 값으로 채워야 함).
• 이는 액세스 권한의 분배를 복잡하게 만들 수 있습니다. 이제 데이터베이스 관리자(특수 DBMS 패널을 통해 작업하고 개발 중인 시스템에 계정이 없음)만 관리자 테이블에 액세스할 수 있습니다. 그러나 테이블을 조인할 때 사용자 쿼리에는 새 테이블에 대한 액세스 권한이 필요합니다.

librarians_rooms이 다이어그램을 구성할 때 ER 다이어그램의 결함이 발견되어 수정되었습니다. 사서와 홀을 통합하는 테이블이 추가되었습니다 . 한 명의 사서가 여러 방에서 일할 수 있지만 여러 사서가 같은 방에서 일할 수 있기 때문에 필요합니다.

데이터베이스를 설계할 때 적어도 위의 예처럼 추론할 수 있어야 합니다. 당신이 성공했다고 생각한다면 더 나아가 보자. 더 많은 이론.