관계형 데이터베이스 디자인(RDD) 모델의 정보와 데이터를 행과 열이 있는 테이블 세트로 만듭니다. 관계/테이블의 각 행은 레코드를 나타내고 각 열은 데이터의 속성을 나타냅니다. SQL(Structured Query Language)은 관계형 데이터베이스를 조작하는 데 사용됩니다. 관계형 데이터베이스의 디자인은 데이터가 관련 테이블 세트로 모델링되는 4단계로 구성됩니다. 단계는 -
- 관계/속성 정의
- 기본 키 정의
- 관계 정의
- 정규화
관계형 데이터베이스는 데이터를 구성하고 트랜잭션을 수행하는 접근 방식이 다른 데이터베이스와 다릅니다. RDD에서 데이터는 테이블로 구성되며 모든 유형의 데이터 액세스는 제어된 트랜잭션을 통해 수행됩니다. 관계형 데이터베이스 설계는 데이터베이스 설계에서 요구하는 ACID(원자성, 일관성, 무결성, 내구성) 속성을 만족합니다. 관계형 데이터베이스 설계에서는 데이터 관리 문제를 처리하기 위해 애플리케이션에서 데이터베이스 서버를 사용해야 합니다.
관계형 데이터베이스 설계 프로세스
데이터베이스 디자인은 많은 결정을 내려야 하기 때문에 과학보다 예술에 가깝습니다. 데이터베이스는 일반적으로 특정 응용 프로그램에 맞게 사용자 정의됩니다. 두 개의 사용자 정의 응용 프로그램이 동일하지 않으므로 두 개의 데이터베이스가 동일하지 않습니다. 이러한 디자인 결정을 내릴 때 지침(일반적으로 무엇을 해야 하는지 대신에 하지 말아야 할 사항)이 제공되지만 선택은 궁극적으로 디자이너에게 달려 있습니다.
1단계 - 데이터베이스의 목적 정의(요구사항 분석)
- 요구사항을 수집하고 데이터베이스의 목적을 정의하십시오.
- 샘플 입력 양식, 쿼리 및 보고서의 초안을 작성하면 종종 도움이 됩니다.
2단계 - 데이터 수집, 테이블 구성 및 기본 키 지정
- 데이터베이스의 용도를 결정했으면 데이터베이스에 저장하는 데 필요한 데이터를 수집합니다. 데이터를 주제 기반 테이블로 나눕니다.
- 각 행을 고유하게 식별하는 소위 기본 키로 하나의 열(또는 몇 개의 열)을 선택합니다.
3단계 - 테이블 간의 관계 생성
독립적이고 관련이 없는 테이블로 구성된 데이터베이스는 거의 용도가 없습니다(대신 스프레드시트 사용을 고려할 수 있음). 관계형 데이터베이스의 힘은 테이블 간에 정의할 수 있는 관계에 있습니다. 관계형 데이터베이스를 설계할 때 가장 중요한 측면은 테이블 간의 관계를 식별하는 것입니다. 관계 유형은 다음과 같습니다.
- 일대다
- 다대다
- 일대일
일대다
"수업 명단" 데이터베이스에서 교사는 0개 이상의 수업을 가르칠 수 있지만 수업은 한 명의 교사가 가르칩니다. "회사" 데이터베이스에서 관리자는 0명 이상의 직원을 관리하는 반면 직원은 한 명의 관리자가 관리합니다. "제품 판매" 데이터베이스에서 고객은 많은 주문을 할 수 있습니다. 한 특정 고객이 주문하는 동안. 이러한 종류의 관계를 일대다 관계라고 합니다.
일대다 관계는 단일 테이블에 나타낼 수 없습니다. 예를 들어, "수업 명단" 데이터베이스에서 교사에 대한 정보(예:이름, 사무실, 전화 및 이메일)를 저장하는 Teacher라는 테이블로 시작할 수 있습니다. 각 교사가 가르친 수업을 저장하기 위해 class1, class2, class3 열을 만들 수 있지만 만들 열 수에 즉시 문제가 발생합니다. 반면에 수업에 대한 정보를 저장하는 Classes라는 테이블로 시작하는 경우 (이름, 사무실, 전화 및 이메일과 같은) 교사에 대한 정보를 저장하기 위해 추가 열을 생성할 수 있습니다. 그러나 교사는 많은 수업을 가르칠 수 있으므로 해당 데이터는 수업 테이블의 여러 행에 복제됩니다.
일대다 관계를 지원하려면 두 개의 테이블을 설계해야 합니다. 기본 키로 classID를 사용하여 클래스에 대한 정보를 저장하는 테이블 Classes; 및 교사 ID를 기본 키로 사용하여 교사에 대한 정보를 저장하는 교사 테이블. 그런 다음 테이블 클래스("다"-끝 또는 자식 테이블), 아래 그림과 같습니다.
자식 테이블 Classes의 teacherID 열을 외래 키라고 합니다. 하위 테이블의 외래 키는 상위 테이블을 참조하는 데 사용되는 상위 테이블의 기본 키입니다.
다대다
"제품 판매" 데이터베이스에서 고객의 주문에는 하나 이상의 제품이 포함될 수 있습니다. 제품은 많은 주문에 나타날 수 있습니다. "서점" 데이터베이스에서 책은 한 명 이상의 저자가 작성합니다. 저자는 0개 이상의 책을 쓸 수 있습니다. 이러한 종류의 관계를 다대다 관계라고 합니다.
"제품 판매" 데이터베이스로 설명하겠습니다. 제품 및 주문이라는 두 개의 테이블로 시작합니다. 제품 테이블에는 productID를 기본 키로 사용하여 제품에 대한 정보(예:이름, 설명 및 수량 InStock)가 포함됩니다. 테이블 주문에는 고객의 주문(customerID, dateOrdered, dateRequired 및 상태)이 포함됩니다. 다시 말하지만, 항목에 대해 예약할 열의 수를 모르기 때문에 Orders 테이블 안에 주문한 항목을 저장할 수 없습니다. 또한 제품 테이블에 주문 정보를 저장할 수 없습니다.
다대다 관계를 지원하려면 각 행이 특정 주문의 항목을 나타내는 OrderDetails(또는 OrderLines)와 같은 세 번째 테이블(접합 테이블이라고 함)을 만들어야 합니다. OrderDetails 테이블의 경우 기본 키는 각 행을 고유하게 식별하는 orderID 및 productID의 두 열로 구성됩니다. OrderDetails 테이블의 orderID 및 productID 열은 Orders 및 Products 테이블을 참조하는 데 사용되므로 OrderDetails 테이블의 외래 키이기도 합니다.
다대다 관계는 실제로 접합 테이블의 도입과 함께 두 개의 일대다 관계로 구현됩니다.
주문의 OrderDetails에는 많은 항목이 있습니다. OrderDetails 항목은 하나의 특정 주문에 속합니다.
제품은 많은 OrderDetails에 나타날 수 있습니다. 각 OrderDetails 항목은 하나의 제품을 지정했습니다.
일대일
"제품 판매" 데이터베이스에서 제품에는 이미지, 추가 설명 및 설명과 같은 선택적 추가 정보가 있을 수 있습니다. 제품 테이블 내부에 보관하면 많은 빈 공간이 생깁니다(이러한 선택적 데이터가 없는 레코드에서). 또한 이러한 대용량 데이터는 데이터베이스 성능을 저하시킬 수 있습니다.
대신 선택적 데이터를 저장하기 위해 다른 테이블(예:ProductDetails, ProductLines 또는 ProductExtras)을 만들 수 있습니다. 선택적 데이터가 있는 제품에 대해서만 레코드가 생성됩니다. 두 테이블, Products 및 ProductDetails는 일대일 관계를 나타냅니다. 즉, 상위 테이블의 모든 행에 대해 하위 테이블에는 최대 하나의 행(0일 수도 있음)이 있습니다. 동일한 열 productID를 두 테이블의 기본 키로 사용해야 합니다.
일부 데이터베이스는 테이블 내부에 생성할 수 있는 열의 수를 제한합니다. 일대일 관계를 사용하여 데이터를 두 개의 테이블로 분할할 수 있습니다. 일대일 관계는 특정 민감한 데이터를 보안 테이블에 저장하고 중요하지 않은 데이터를 기본 테이블에 저장하는 데에도 유용합니다.
열 데이터 유형
각 열에 대해 적절한 데이터 유형을 선택해야 합니다. 일반적으로 데이터 유형에는 정수, 부동 소수점 숫자, 문자열(또는 텍스트), 날짜/시간, 바이너리, 컬렉션(예:열거 및 집합)이 포함됩니다.
4단계 - 디자인 수정 및 표준화
예를 들어,
- 열 추가,
- 일대일 관계를 사용하여 선택적 데이터에 대한 새 테이블 만들기
- 큰 테이블을 두 개의 작은 테이블로 분할
- 다른 방법.
정규화
소위 정규화 규칙을 적용하여 데이터베이스가 구조적으로 정확하고 최적인지 확인하십시오.
제1정규형(1NF): 모든 셀에 값 목록이 아닌 단일 값이 포함된 경우 테이블은 1NF입니다. 이 속성을 원자라고 합니다. 1NF는 item1, item2, itemN과 같은 열의 반복 그룹도 금지합니다. 대신 일대다 관계를 사용하여 다른 테이블을 만들어야 합니다.
제2정규형(2NF) - 테이블이 1NF이고 키가 아닌 모든 열이 기본 키에 완전히 종속되어 있으면 테이블은 2NF입니다. 또한 기본 키가 여러 열로 구성된 경우 키가 아닌 모든 열은 일부가 아닌 전체 집합에 종속되어야 합니다.
예를 들어 orderID 및 productID로 구성된 OrderDetails 테이블의 기본 키입니다. unitPrice가 productID에만 의존하는 경우 OrderDetails 테이블(그러나 Products 테이블)에는 유지되지 않습니다. 반면에 단가가 특정 주문뿐만 아니라 제품에 따라 달라지는 경우에는 OrderDetails 테이블에 유지됩니다.
제3정규형(3NF) - 테이블이 2NF이고 키가 아닌 열이 서로 독립적인 경우 테이블은 3NF입니다. 즉, 키가 아닌 열은 기본 키에 종속되고 기본 키에만 종속되고 다른 것은 없습니다. 예를 들어, productID(기본 키), name 및 unitPrice 열이 있는 Products 테이블이 있다고 가정합니다. 할인율 열은 기본 키의 일부가 아닌 unitPrice에도 종속되는 경우 Products 테이블에 속하지 않습니다.
고급 정규형: 3NF는 이 튜토리얼의 범위를 벗어나는 Boyce/Codd Normal Form, Fourth Normal Form(4NF) 및 Fifth Normal Form(5NF)과 같은 더 높은 Normal Form으로 이어지는 부적절함이 있습니다.
때때로 성능상의 이유로 일부 정규화 규칙을 위반하기로 결정할 수 있습니다(예:orderDetails 레코드에서 파생될 수 있는 Orders 테이블에 totalPrice라는 열 만들기). 또는 최종 사용자가 요청했기 때문입니다. 이를 완전히 인식하고, 이를 처리할 프로그래밍 논리를 개발하고, 결정을 적절하게 문서화해야 합니다.
청렴 규칙
또한 무결성 규칙을 적용하여 디자인의 무결성을 확인해야 합니다. −
1. 엔티티 무결성 규칙 - 기본 키는 NULL을 포함할 수 없습니다. 그렇지 않으면 행을 고유하게 식별할 수 없습니다. 여러 열로 구성된 복합 키의 경우 어떤 열에도 NULL이 포함될 수 없습니다. 대부분의 RDBMS는 이 규칙을 확인하고 시행합니다.
2.참조 무결성 규칙 - 각 외래 키 값은 참조된 테이블(또는 상위 테이블)의 기본 키 값과 일치해야 합니다.
부모 테이블에 값이 있는 경우에만 자식 테이블에 외래 키가 있는 행을 삽입할 수 있습니다.
부모 테이블에서 키 값이 변경되면(예:행 업데이트 또는 삭제), 자식 테이블에서 이 외래 키가 있는 모든 행은 그에 따라 처리되어야 합니다. 귀하는 (a) 변경을 허용하지 않을 수 있습니다. (b) 그에 따라 하위 테이블에서 변경 사항을 계단식으로 배열(또는 레코드 삭제)합니다. (c) 자식 테이블의 키 값을 NULL로 설정합니다.
대부분의 RDBMS는 지정된 방식으로 검사를 수행하고 참조 무결성을 보장하도록 설정할 수 있습니다.
3.비즈니스 로직 무결성 - 위의 두 가지 일반 무결성 규칙 외에도 비즈니스 논리와 관련된 무결성(검증)이 있을 수 있습니다. 예를 들어 우편 번호는 특정 범위 내에서 5자리여야 하고 배달 날짜 및 시간은 영업 시간에 속해야 합니다. 주문 수량은 재고 수량 등과 같거나 작아야 합니다. 이는 무효화 규칙(특정 열에 대해) 또는 프로그래밍 논리를 수행할 수 있습니다.
열 인덱싱
선택한 열에 인덱스를 만들어 데이터 검색 및 검색을 용이하게 할 수 있습니다. 인덱스는 SELECT에 대한 데이터 액세스 속도를 높이지만 INSERT, UPDATE 및 DELETE 속도를 늦출 수 있는 구조화된 파일입니다. 인덱스 구조 없이 일치하는 기준(예:SELECT * FROM Customers WHERE name='Tan Ah Teck')으로 SELECT 쿼리를 처리하려면 데이터베이스 엔진이 테이블의 모든 레코드를 비교해야 합니다. 특수 인덱스(예:BTREE 구조)는 모든 레코드를 비교하지 않고 레코드에 도달할 수 있습니다. 그러나 레코드가 변경될 때마다 인덱스를 다시 작성해야 하므로 인덱스 사용과 관련된 오버헤드가 발생합니다.
인덱스는 단일 열, 열 집합(연결된 인덱스라고 함) 또는 열의 일부(예:VARCHAR(100)의 처음 10자)(부분 인덱스라고 함)에 정의될 수 있습니다. . 테이블에 둘 이상의 인덱스를 작성할 수 있습니다. 예를 들어, customerName 또는 전화번호를 사용하여 고객을 자주 검색하는 경우, customerName 및 phoneNumber 열에 대한 색인을 작성하여 검색 속도를 높일 수 있습니다. 대부분의 RDBMS는 기본 키에 대한 인덱스를 자동으로 구축합니다.