데이터베이스 설계의 원칙을 요약합니다.-MySQL 튜토리얼-php.cn

원본 문서와 항목 간의 관계는 일대일, 일대다 또는 다대다일 수 있습니다. 일반적으로 이는 일대일 관계입니다. 즉, 하나의 원본 문서는 하나의 엔터티에만 해당합니다. 특별한 경우에는 일대다 또는 다대일 관계일 수 있습니다. 즉, 하나의 원본 문서가 여러 엔터티에 해당하거나 여러 원본 문서가 하나의 엔터티에 해당할 수 있습니다.

1. 원본 문서와 개체의 관계
일대일, 일대다, 다대다 관계일 수 있습니다. 일반적으로 이는 일대일 관계입니다. 즉, 하나의 원본 문서는 하나의 엔터티에만 해당합니다.
특별한 경우에는 일대다 또는 다대일 관계일 수 있습니다. 즉, 하나의 원본 문서가 여러 엔터티에 해당하거나 여러 원본 문서가 하나의 엔터티에 해당할 수 있습니다.
여기서 엔터티는 기본 테이블로 이해될 수 있습니다. 이 대응 관계를 명확히 한 후에는 입력 인터페이스를 설계하는 데 큰 도움이 될 것입니다.

〖예 1〗: 직원 이력서 정보는 인사 정보 시스템의 세 가지 기본 테이블인 직원 기본 정보 테이블, 사회적 관계 테이블, 작업 이력서 테이블에 해당합니다.
"하나의 원본 문서가 여러 개체에 해당한다"는 전형적인 예입니다.

2. 기본 키와 외래 키
일반적으로 엔터티는 기본 키와 외래 키를 모두 가질 수 없습니다. E-R 다이어그램에서 리프 위치의 엔터티는 기본 키를 정의할지 여부(후손이 없기 때문에)를 정의할 수 있지만(부모가 있기 때문에) 외래 키가 있어야 합니다.

기본 키와 외래 키의 디자인은 글로벌 데이터베이스 디자인에서 중요한 역할을 합니다. 글로벌 데이터베이스 설계가 완성된 뒤 미국의 한 데이터베이스 설계 전문가
는 "열쇠는 어디에나 있고, 열쇠 외에는 아무것도 없다"고 말했다. 이는 자신의 데이터베이스 설계 경험에 대해 말한 것이기도 하며, 이는 그가 개발한 것이기도 하다. 정보 시스템의 핵심(데이터 모델)에 대한 그의 매우 추상적인 아이디어. 왜냐하면 기본 키는 매우 추상적인 엔터티이고 기본 키와 외래 키의 쌍은 엔터티 간의 연결을 나타냅니다.

3. 기본 테이블의 속성
기본 테이블은 다음과 같은 네 가지 특성을 갖는다는 점에서 중간 테이블 및 임시 테이블과 다릅니다.
(1) 원자성. 기본 테이블의 필드는 분해할 수 없습니다. 　 (2) 원시성. 기본 테이블의 레코드는 원본 데이터(기본 데이터)의 레코드입니다.
　 (3) 연역적. 모든 출력 데이터는 기본 테이블과 코드 테이블의 데이터에서 파생될 수 있습니다.
　 (4) 안정성. 기본 테이블의 구조는 비교적 안정적이며, 테이블의 레코드를 장기간 저장해야 합니다.
기본 테이블의 성격을 이해한 후에는 데이터베이스를 설계할 때 기본 테이블과 중간 테이블, 임시 테이블을 구분할 수 있습니다.

4. 정규형 표준
기본 테이블과 해당 필드 간의 관계는
제3 정규형을 충족하도록 노력해야 합니다. 그러나 세 번째 패러다임을 만족하는 데이터베이스 설계가 최선의 설계가 아닌 경우가 많습니다. 데이터베이스의 운영 효율성을 높이려면 패러다임 표준을 낮춰야 하는 경우가 많습니다. 즉, 공간을 시간과 교환한다는 목적을 달성하기 위해 중복성을 적절하게 늘리는 것입니다.
　〖예시 2〗: 표 1과 같이 물건을 보관하는 기본 테이블이 있습니다. "금액" 필드가 존재한다는 것은 테이블의 디자인이 제3정규형을 충족하지 않는다는 것을 의미하며,
"금액"은 "단가"에 "수량"을 곱하여 구할 수 있기 때문에 "금액"은 중복 필드. 그러나 "금액"이라는 중복 필드를 추가하면 통계 쿼리 속도가 향상될 수 있습니다. 이는 시간과 공간을 교환하는 방법입니다.
Rose 2002에는 데이터 열과 계산 열이라는 두 가지 유형의 열이 있습니다. "금액"과 같은 열을 "계산 열"이라고 하고, "단가", "수량"과 같은 열을 "데이터 열"이라고 합니다.
표 1 제품 테이블의 테이블 구조
제품명 제품 모델 단가 수량 금액
TV 세트 29인치 2,500 40 100,000

5. 세 가지 패러다임을 대중적인 방식으로 이해

세 가지 패러다임에 대한 공통된 이해는 데이터베이스 설계에 큰 이점을 줍니다. 데이터베이스 설계에 있어서 세 가지 패러다임을 더 잘 적용하기 위해서는
세 가지 패러다임을 대중적으로 이해하는 것이 필요합니다. (대중적 이해는 충분한 이해이지 가장 과학적이고 정확한 이해는 아닙니다.) 첫 번째 정규형
: 1NF는 속성에 대한 원자성 제약 조건으로, 속성은 원자성이고 분해될 수 없습니다.
　
두 번째 정규형 : 2NF는 레코드에 대한 고유성 제약 조건입니다. 레코드에는 고유 식별자, 즉 엔터티의 고유성이 있어야 합니다. 세 번째 정규형: 3NF는 필드 중복에 대한 제약 조건입니다. 즉, 어떤 필드도 다른 필드에서 파생될 수 없으며 필드가 다음과 같아야 합니다. 중복되지 않습니다.
중복된 데이터베이스 설계로는 이를 수행할 수 없습니다. 그러나 중복성이 없는 데이터베이스는 최고의 데이터베이스가 아닐 수도 있습니다. 때로는 운영 효율성을 높이기 위해 패러다임 표준을 낮추고 중복된 데이터를 적절하게 보관해야 할 수도 있습니다. 구체적인 접근 방식은 개념적 데이터 모델을 설계할 때 세 번째 패러다임을 준수하고, 물리적 데이터 모델을 설계할 때 패러다임 표준을 낮추는 작업을 고려하는 것입니다. 정규형을 낮추는 것은 필드를 추가하고 중복성을 허용하는 것을 의미합니다.

6. 다대다 관계를 식별하고 올바르게 처리하는 데 능숙하세요.

두 개체 간에 다대다 관계가 있는 경우 이 관계를 제거해야 합니다. 해결책은 둘 사이에 세 번째 엔터티를 추가하는 것입니다. 이렇게 해서
하나의 다대다 관계는 이제 두 개의 일대다 관계가 됩니다. 원래의 두 엔터티의 속성을 세 엔터티에 합리적으로 분배하는 것이 필요합니다. 여기서 세 번째
엔터티는 본질적으로 기본 테이블에 해당하는 더 복잡한 관계입니다. 일반적으로 데이터베이스 설계 도구는 다대다 관계를 인식할 수 없지만
다대다 관계를 처리할 수 있습니다.

〖예 3〗: "도서관 정보 시스템"에서 "책"도 개체이고 "독자"도 개체입니다. 이 두 엔터티 간의 관계는 일반적인 다대다 관계입니다. 책은 여러 독자가 서로 다른 시간에 빌릴 수 있고 독자는 여러 권의 책을 빌릴 수 있습니다. 이를 위해 두
사이에 세 번째 엔터티를 추가해야 합니다. 이 엔터티의 이름은 "도서 대출 및 반납"입니다. 해당 속성은 대출 및 반납 시간, 대출 및 반납 플래그입니다(0은 책을 빌리는 것을 의미함). 책 반환), 추가로
두 개의 외래 키("Book"의 기본 키, "Reader"의 기본 키)도 있어야 "Book"과 연결될 수 있습니다. "리더".

7. 기본 키 PK의 값 방식
PK는 프로그래머를 위한 테이블 간 연결 도구로 물리적 의미가 없는 디지털 문자열일 수 있으며 프로그램이 자동으로 실행됩니다. 달성하려면 1을 더합니다. 필드 이름일 수도 있고 물리적 의미가 있는 필드 이름의 조합일 수도 있습니다. 하지만 전자가 후자보다 낫다. PK가 필드 이름의 조합인 경우 필드를 너무 많이 포함하지 않는 것이 좋습니다. 필드가 너무 많으면
인덱스가 많은 공간을 차지할 뿐만 아니라 속도도 느려집니다.

8. 데이터 중복에 대한 올바른 이해 여러 테이블에서 기본 키와 외래 키가 반복되는 것은 데이터 중복이 아니라는 사실을 많은 분들이 잘 모르실 겁니다. 아직. 키가 아닌 필드
의 반복 발생은 데이터 중복입니다! 그리고 그것은 일종의 저수준 중복성, 즉 반복적 중복성이다. 높은 수준의 중복성은 필드의 반복 발생이 아니라 파생된 필드 발생입니다.

〖예 4〗: 상품에 "단가, 수량, 금액"의 세 가지 필드가 있습니다. "금액"은 "단가"에 "수량"을 곱한 값으로 중복됩니다.
그리고 그것은 높은 수준의 중복성입니다. 중복의 목적은 처리 속도를 높이는 것입니다. 동일한 데이터가 다른 시간, 위치, 역할에서 여러 번 입력될 수 있기 때문에 낮은 수준의 중복만 데이터 불일치를 증가시킵니다. 따라서 우리는 높은 수준의 중복성(파생 중복성)을 옹호하고 낮은 수준의 중복성(반복적 중복성)에 반대합니다.

9. E-R 다이어그램에는 표준 답이 없습니다.
정보 시스템의 E-R 다이어그램에는 설계 및 작성 방법이 다르기 때문에 표준 답이 없습니다. 시스템 요구사항의 사업 범위와 기능적 내용을 포괄한다면 가능합니다. 그렇지 않으면 E--R 다이어그램을 수정하십시오. 하나의 표준적인 답이 있는 것은 아니지만 마음대로 설계할 수 있다는 뜻은 아니다. 좋은 E-R 다이어그램의 기준은 다음과 같습니다.
명확한 구조, 간결한 연관, 적절한 수의 엔터티, 합리적인 속성 할당 및 낮은 수준의 중복 없음.

10. 뷰 기술은 데이터베이스 설계에 매우 유용합니다
뷰는 기본 테이블, 코드 테이블, 중간 테이블과 달리 실제 테이블에 의존하는 가상 테이블입니다. 그리고 존재합니다. 뷰는 프로그래머가 데이터베이스를 사용할 수 있는 창으로, 기본 테이블 데이터를 합성하는 형태이자 데이터 처리 방법이며 사용자 데이터를 기밀로 유지하는 수단입니다. 복잡한 처리를 수행하고
컴퓨팅 속도를 향상시키고 저장 공간을 절약하려면 뷰의 정의 깊이가 일반적으로 3레벨을 초과해서는 안 됩니다. 3계층 뷰가 여전히 충분하지 않다면 뷰에 임시 테이블을 정의한 다음 임시 테이블에 뷰를 정의해야 합니다. 이런 식으로 정의를 반복적으로 겹쳐서 보면 뷰의 깊이가 제한되지 않습니다.
국가의 정치, 경제, 기술, 군사 및 안보 이익과 관련된 특정 정보 시스템의 경우 견해의 역할이 더욱 중요합니다. 이러한 시스템의 기본 테이블이 물리적으로 설계되면 기본 테이블에 첫 번째 수준 뷰가 즉시 생성됩니다. 이 뷰 계층의 수와 구조는 기본 테이블의 수 및 구조와 정확히 동일합니다.
또한 모든 프로그래머는 뷰에 대해서만 작업을 수행할 수 있도록 규정되어 있습니다. 여러 사람이 공유하는 '보안 키'를 가진 데이터베이스 관리자만이 기본 테이블에 대해 직접 작업할 수 있습니다. 독자들은 다음과 같이 생각해 보아야 합니다. 이것이 왜인가?

11. 중간 테이블, 보고서 및 임시 테이블

중간 테이블은 데이터 웨어하우스, 출력 보고서 또는 쿼리 결과를 저장하는 테이블입니다. 기본 키와 외래 키가 없습니다(데이터 웨어하우스
라이브러리 제외). 임시 테이블은 개인 용도로 임시 레코드를 저장하기 위해 프로그래머가 설계했습니다. 기본 테이블과 중간 테이블은 DBA가 관리하고, 임시 테이블은 프로그래머
가 직접 관리합니다.
12. 무결성 제약 조건은 세 가지 측면으로 표현됩니다.

도메인 무결성: Check를 사용하여 제약 조건을 구현하고 데이터베이스 설계 도구에서 필드의 값 범위를 정의합니다. 버튼을 통해 필드의 값을 정의합니다.
참조 무결성: PK, FK 및 테이블 수준 트리거를 사용하여 구현됩니다.
사용자 정의 무결성: 저장 프로시저와 트리거를 사용하여 구현되는 일부 비즈니스 규칙입니다.

13. 데이터베이스 설계 패치를 방지하는 방법은 '3가지 원칙'입니다 (1) 데이터베이스의 테이블 수가 적을수록 좋습니다. 테이블의 수가 줄어들어야 시스템의 E-R 다이어그램이 작고 정확하다는 것을 알 수 있으며, 반복적이고 중복되는
개체를 제거하고 객관적 세계에 대한 높은 추상화 수준을 형성하며 체계적인 데이터 통합을 수행합니다. 문제를 방지하려면
(2) 테이블의 결합된 기본 키 필드 수가 적을수록 좋습니다. 기본키의 역할 때문에 하나는 기본키 인덱스를 구축하는 것이고, 다른 하나는 하위 테이블의 외래키 역할을 하기 때문에 기본키를 결합하는 필드의 수가 줄어들 뿐만 아니라 실행 시간을 절약할 뿐만 아니라 인덱스 저장 공간도 절약합니다.
(3) 테이블의 필드 수가 적을수록 좋습니다. 필드 수가 줄어드는 경우에만 시스템에 데이터 중복이 없으며 중복 데이터가 거의 없음을 의미할 수 있습니다. 더 중요한 것은 독자가 "열을 행으로 변경"하는 방법을 배워야 한다는 것입니다. -테이블이 행으로 변경되지 않습니다. 필드가 기본 테이블로 가져와서 기본 테이블에 많은
빈 필드가 남습니다. 소위 "열 대 행"은 기본 테이블에서 내용의 일부를 가져와 별도의 하위 테이블을 만드는 것입니다. 이 방법은 매우 간단합니다
. 하지만 일부 사람들은 익숙하지 않고, 채택하지 않고, 구현하지 않습니다.
데이터베이스 설계의 실제 원칙은 데이터 중복성과 처리 속도 사이의 적절한 균형을 찾는 것입니다. '세 청년 거장'은 종합적인 개념이자 종합적인 견해입니다.
하나의 원칙은 분리될 수 없습니다. 이 원칙은 절대적인 것이 아니라 상대적인 것입니다. "3개 더" 원칙은 확실히 잘못된 것입니다. 상상해 보십시오. 시스템의 동일한 기능이 다루어지면 100개 개체(총 1000개 속성)의 E-R 다이어그램이 200개 개체(총 2000개 속성)의 E-R 다이어그램보다 확실히 더 나을 것입니다. 훨씬 나아졌습니다.
"Three Less" 원칙을 장려하는 것은 독자들에게 체계적인 데이터 통합을 위해 데이터베이스 설계 기술을 사용하도록 가르치는 것입니다. 데이터 통합 단계는 파일 시스템
을 응용 데이터베이스로 통합하고, 응용 데이터베이스를 주제 데이터베이스로 통합하고, 주제 데이터베이스를 글로벌 종합 데이터베이스로 통합하는 것입니다. 통합 정도가 높을수록 데이터 공유는 더욱 강력해지고
전체 기업 정보 시스템의 글로벌 ER 다이어그램에서 개체 수, 기본 키 수 및 속성 수는 줄어듭니다.
더 적을 겁니다.
"Three Less" 원칙을 옹호하는 목적은 독자가 패치 기술을 사용하여 데이터베이스를 지속적으로 추가, 삭제 및 수정하여 엔터프라이즈 데이터베이스를 데이터베이스 테이블 또는 데이터베이스를 무작위로 설계하는 "쓰레기 더미"로 만드는 것을 방지하는 것입니다. '대형 마당'으로 인해 결국 데이터베이스에 수많은 기본 테이블, 코드 테이블, 중간 테이블, 임시 테이블
이 생겨 기업과 기관의 정보 시스템을 유지 관리할 수 없게 되고 마비되었습니다.
"패치 방식"을 이용한 데이터베이스 설계의 비뚤어진 이론인 "Three More" 원칙은 누구나 할 수 있습니다. "3개 적게" 원칙은 더 적지만 더 좋다는 원칙입니다
. 높은 데이터베이스 설계 기술과 기술이 필요합니다. 왜냐하면 이 원칙은 "패치 방법"의 사용을 없애기 위한 것이기 때문입니다
. 데이터베이스 설계용.

14. 데이터베이스 운영 효율성을 향상시키는 방법

주어진 시스템 하드웨어 및 시스템 소프트웨어 조건에서 데이터베이스 시스템의 운영 효율성을 향상시키는 방법은 다음과 같습니다. 🎜> (1) 데이터베이스의 물리적 설계에서는 패러다임을 낮추고, 중복성을 높이고, 트리거를 덜 사용하고, 저장 프로시저를 더 많이 사용합니다.
　 (2) 계산이 매우 복잡하고 레코드 수가 매우 많은 경우(예: 1,000만 개) 파일 시스템의 데이터베이스 외부에서 복잡한 계산을 수행해야 합니다 마지막으로 에 추가됩니다. 데이터베이스를 생성하고 테이블에 추가했습니다. 통신과금시스템 설계 경험입니다. (3) 특정 테이블에 레코드가 너무 많은 경우(예: 1,000만 개 이상) 테이블을 가로로 분할해야 합니다. 수평 분할 방법은 테이블의 기본 키
PK의 특정 값을 경계로 사용하여 테이블의 레코드를 두 개의 테이블로 수평 분할하는 것입니다. 테이블에 너무 많은 필드(예: 80개 이상)가 있는 것으로 확인되면
테이블을 수직으로 분할하고 원본 테이블을 두 개의 테이블로 분해합니다.
(4) 데이터베이스 관리 시스템 DBMS의 시스템 최적화, 즉 버퍼 수와 같은 다양한 시스템 매개 변수를 최적화합니다.
(5) 프로그래밍에 데이터 중심 SQL 언어를 사용할 때는 최적화 알고리즘을 채택해 보세요.

위의 14가지 스킬은 수많은 데이터베이스 분석과 디자인 실습을 통해 많은 사람들에 의해 점차적으로 정리됩니다. 이러한 경험의 적용에 있어서 독자는 기계적으로 암기하고 암기하는 것이 아니라, 그것을 소화하고 이해하며, 사실에서 진실을 찾고, 유연하게 숙달해야 한다. 그리고 점차적으로 달성하십시오: 응용 프로그램에서 개발하고 개발에 적용하십시오.

다른 원칙을 살펴보겠습니다.

1) 데이터베이스 설계는 전체 시스템에 대해 수행하는 것이 아니라, 시스템 아키텍처 내 컴포넌트 분할을 기반으로 해야 하며, 컴포넌트 단위의 데이터베이스 설계는 각 컴포넌트가 처리하는 업무에 따라 수행해야 한다. 서로 다른 구성 요소 간의 해당 데이터베이스 테이블은 가능한 한 최소화되어야 합니다. 서로 다른 구성 요소 간의 테이블에 외래 키 연결이 필요한 경우 외래 키 연결을 만들지 말고 대신 관련 테이블의 기본 키를 기록하세요. 구성 요소에 해당하는 테이블 간의 독립성을 보장하고 리팩토링이 가능성을 제공하도록 합니다.

2) 데이터베이스 설계에 도메인 모델 중심 접근 방식과 하향식 접근 방식을 채택합니다. 먼저 시스템 비즈니스를 분석하고 책임에 따라 개체를 정의합니다. 객체는 캡슐화의 특성을 준수해야 하며 책임과 관련된 데이터 항목이 객체 내에 정의되어 있는지 확인해야 합니다. 이러한 데이터 항목은 책임을 완전히 설명할 수 있으며 책임 설명이 누락되지 않습니다. 그리고 객체가 하나의 책임만을 갖고 있다면, 객체가 둘 이상의 책임을 담당한다면 분할되어야 합니다.

3) 설정된 도메인 모델에 따라 데이터베이스 테이블을 매핑합니다. 이때 데이터베이스 설계의 두 번째 패러다임을 참조해야 합니다. 테이블의 키워드가 아닌 모든 속성은 전체 키워드에 따라 달라집니다. 키워드는 속성일 수도 있고 여러 속성의 컬렉션일 수도 있습니다. 두 경우 모두 키워드는 고유해야 합니다. 키워드를 결정할 때 해당 키워드가 비즈니스에 참여하지 않고 업데이트 예외가 발생하지 않는지 확인해야 합니다. 이 경우 최적의 솔루션은 자동 증가 숫자 속성 또는 임의의 문자열을 키워드로 사용하는 것입니다. 테이블.

4) 데이터베이스 테이블 구조는 첫 번째 포인트에서 언급한 것처럼 도메인 모델 중심으로 설계되었기 때문에 도메인 모델의 각 개체는 하나의 책임만 가지므로 개체의 데이터 항목은 전이적 종속성, 따라서 이 아이디어의 데이터베이스 테이블 구조 설계는 처음부터 세 번째 정규형을 만족합니다. 테이블은 두 번째 정규형을 만족해야 하며 속성 간에 전이적 종속성이 없습니다.

5) 마찬가지로 객체 책임의 통일성과 객체 간 관계는 비즈니스 로직 간의 관계를 반영하므로 도메인 모델의 객체는 마스터 객체와 슬레이브 객체로 구분되는 비즈니스 로직입니다. 1-N 또는 N-N 관점에서 기본 개체이므로 개체 및 개체 관계에서 매핑된 테이블 및 테이블 연결에 삭제 및 삽입 예외가 없습니다.

6) 매핑 후 얻은 데이터베이스 테이블 구조는 다중 값 종속성이 없도록 네 번째 정규형에 따라 추가로 수정되어야 합니다. 이때 리버스 엔지니어링 아이디어를 바탕으로 도메인 모델에 피드백을 주어야 한다. 테이블 구조에 다중 값 종속성이 있는 경우 도메인 모델의 개체에 최소한 두 가지 이상의 책임이 있음을 증명하며 첫 번째 기사에 따라 디자인을 수정해야 합니다. 네 번째 정규형: 테이블이 BCNF를 충족하면 다중 값 종속성이 없어야 합니다.

7) 분석 결과 모든 테이블이 두 번째, 세 번째, 네 번째 정규형을 충족하는 것으로 확인되었습니다. 테이블 구조. 더욱이 데이터베이스의 테이블은 특정 시간, 특정 조건에서 객체 인스턴스의 상태를 유지하는 데 사용되는 저장 매체일 뿐이므로 비즈니스를 표현하기 위해 테이블 간의 강력한 연관성이 없어야 한다고 생각합니다. 데이터 일관성) 이 책임은 시스템의 논리적 계층에서 보장되어야 하며, 이 접근 방식은 잘못된 데이터(더티 데이터)와 시스템의 호환성도 보장합니다. 물론, 전체 시스템의 관점에서 볼 때 우리는 시스템이 더티 데이터를 생성하지 않도록 최선을 다해야 합니다. 다른 관점에서 보면 더티 데이터의 생성은 어느 정도 불가피하며, 또한 보장해야 합니다. 시스템은 이 상황에 대한 내결함성을 생성하지 않습니다. 이것은 타협입니다.

8) 모든 테이블의 기본 키와 외래 키에 대해 인덱스를 설정하고, 결합된 속성에 대한 인덱스를 타겟 방식(일부 대용량 데이터 및 일반적인 검색 방법의 경우)으로 설정하여 검색 성능을 향상시켜야 합니다. 능률. 인덱스를 구축하면 일부 시스템 리소스가 소모되지만, 특히 테이블의 데이터 양이 많을 때 검색 시 전체 테이블의 데이터를 검색할 때 성능에 미치는 영향과 인덱스가 없을 때 정렬 작업의 성능에 미치는 영향을 비교합니다. . , 이 접근 방식은 여전히 옹호할 가치가 있습니다.

9) 저장 프로시저를 최대한 적게 사용하여 "객체/관계형 매핑" 등 저장 프로시저의 기능을 대체할 수 있는 기술이 많이 있습니다. 버전 제어, 개발 및 배포, 데이터베이스 마이그레이션은 큰 영향을 미칩니다. 그러나 저장 프로시저가 성능상의 이점을 가지고 있다는 것은 부인할 수 없습니다. 따라서 시스템에서 사용할 수 있는 하드웨어가 향상되지 않고 성능이 매우 중요한 품질 속성인 경우 균형 잡힌 고려를 통해 저장 프로시저를 선택할 수 있습니다.

10) 테이블 간의 연관 제약 조건을 처리하는 비용(종종 사용성 비용)이 수정, 삭제, 변경 예외가 발생하지 않도록 보장하는 비용을 초과하는 경우, 데이터 중복성도 그렇지 않은 경우 중요한 문제는 테이블 디자인이 네 가지 정규 형식을 따를 필요가 없다는 것입니다. 4가지 패러다임은 예외가 발생하지 않도록 보장하지만 지나치게 순수한 디자인으로 이어질 수 있어 테이블 구조를 사용하기 어렵게 만들 수 있으므로 디자인 시 종합적인 판단이 필요하지만 먼저 4가지 패러다임을 준수하는지 확인하고, 그런 다음 이를 다듬고 수정하세요. 이는 데이터베이스 디자인 분야에 막 입문했을 때 취할 수 있는 최선의 접근 방식입니다.

11) 설계된 테이블은 사용성이 좋아야 하며, 주로 쿼리 중에 여러 테이블을 연결하고 복잡한 SQL 기술을 사용해야 하는지 여부가 반영됩니다.

12) 설계된 테이블은 데이터의 정확성을 보장하기 위해 데이터 중복성을 최대한 줄여야 하며, 중복성을 효과적으로 제어하면 데이터베이스 성능이 향상됩니다. (물론 패러다임을 낮춰야 할 때도 있습니다)

2. 무료 mysql 온라인 비디오 튜토리얼

3.데이터베이스 디자인 그런 것

위 내용은 데이터베이스 설계의 원칙을 요약합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!