데이터베이스 디자인에 어떻게 접근합니까? [닫은]

저는 주로 웹 개발자이며 시작하려는 몇 가지 개인 프로젝트가 있습니다.

나를 괴롭히는 것 중 하나는 데이터베이스 디자인입니다. 나는 학교 DB 정규화와 그와 같은 것들을 겪었지만 몇 년 전에는 학교를 제외하고 관계형 데이터베이스 디자인에 대한 경험이 없었습니다.

그렇다면 웹 앱 관점에서 데이터베이스에 어떻게 접근합니까? 어떻게 시작하고 무엇을 찾아야합니까? 주의해야 할 플래그는 무엇입니까?

데이터베이스 디자인과 관련하여 내가 구입 한 최고의 책 은 Michael Hernandez ISBN : 0-201-69471-9의 Mere Mortals 를 위한 데이터베이스 디자인 이었습니다. 아마존 리스팅 나는 그가 세 번째 판을 가지고 있음을 알았습니다.

제 3 판 링크

그는 데이터베이스 설계의 전체 프로세스 (시작부터 끝까지)를 안내합니다. 이 책부터 시작하는 것이 좋습니다.

당신은 그룹이나 덩어리로 사물을 보는 법을 배워야합니다. 데이터베이스 디자인에는 프로그래밍과 마찬가지로 간단한 빌딩 블록이 있습니다. 이러한 간단한 구성 요소를 완전히 이해하면 모든 데이터베이스 디자인을 처리 할 수 ​​있습니다.

프로그래밍에는 다음이 있습니다.

• 구조하는 경우
• 그렇지 않으면
• While 루프
• 루프까지
• 사례 구성

데이터베이스를 사용하면 다음이 가능합니다.

• 데이터 테이블
• 조회 테이블
• 일대일 관계
• 일대 다 관계
• 다 대다 관계
• 기본 키
• 외래 키

간단할수록 더 좋아집니다. 데이터베이스는 데이터를 입방체 구멍에 넣는 장소에 지나지 않습니다. 이 큐비 구멍이 무엇인지, 그리고 어떤 종류의 재료를 원하는지 식별하여 시작하십시오.

처음 시도 할 때 완벽한 데이터베이스 디자인을 만들지 않을 것입니다. 이것은 사실이다. 설계 과정에서 여러 가지 개선 작업이 수행됩니다. 때로는 데이터 입력을 시작할 때까지 상황이 분명해 보이지 않으며 아아 순간이 있습니다.

웹은 고유 한 문제를 안고 있습니다. 문제가 있습니다. 무국적. 시작되었지만 완료되지 않은 프로세스에서 잘못된 데이터.

나는 객체 지향 프로그래밍과 (주로 트랜잭션이지만 일부 OLAP) 데이터베이스 디자인을 수행하며 내 환경에는 많은 반복 테마가 있습니다 (적어도 OLTP에서는).

3nf 정규화를 연습하면 단일 책임 원칙의 일부 변형을 연습 할 수 있습니다. 테이블은 시스템의 개념을 나타내야하며 개념은 현실을 모방하려는 서로 관련이 있어야합니다. 예를 들어 고객이 0 개 이상의 활동을 가질 수있는 시스템을 구축하는 경우 고객 테이블과 활동 테이블을 만듭니다. 활동 테이블은 고객 테이블과 외래 키 관계를 갖습니다. 스토어드 프로 시저를 빌드 할 때 고객이 0 개의 활동을 가질 수있는 비즈니스 요구 사항 때문에 외부 조인을 사용하여 고객 및 활동에 참여하도록해야합니다.

또한 브리지 (링크) 테이블을 사용하여 확장 가능성을 확인합니다. 예를 들어, 책에 무제한 (가변) 수의 저자가있을 수있는 비즈니스 규칙을 나타내려고하면 책 테이블, 저자 테이블 및 외부 키 참조가 모두있는 브리지 / 링크 테이블을 만듭니다. 책과 저자.

또한 모든 테이블에 대리 키를 사용합니다 (일반적으로 자동 증분 ID 열이지만 아마도 Guids-코드에서 guid와의 트레이드 오프는 단순한 정수보다 더 많은 메모리 공간을 차지한다는 것입니다). 조회 (브리지 / 링크 테이블 제외). 기본적으로 일반적인 외래 키 열에 대한 인덱스를 만들고 저장 프로 시저 / 시스템 쿼리를 수시로 검토하여 인덱싱 전략을 최적화합니다. 내가 사용하는 또 다른 인덱싱 전략은 코드에서 검색 열을 기반으로 컬렉션을 작성하고 검색 열에 적절한 인덱스를 추가하는 장소를 찾는 것입니다.

데이터베이스 스키마를 먼저 디자인 한 다음 ORM을 사용하여 개체를 만듭니다. 나는 그런 식으로 약간 오래된 학교입니다. 지능적이고 효율적인 데이터베이스 스키마를 만들려는 ORM을 신뢰하지 않습니다. 그것은 인간의 작품이며 소프트웨어 디자인 기술의 일부입니다.

Bill Karwin의 저서 인 SQL Antipatterns 는 데이터베이스 계획에 실제로 유용한 것으로 나타났습니다 . 가장 포괄적 인 요점은 데이터베이스가 데이터의 무결성과 의미를 보호 할 수있는 많은 기회를 제공한다는 것과 디자이너가 다양한 유혹의 이유로 이러한 기능을 무시하는 것은 흔한 실수라는 것입니다. 처음부터 이러한 문제를 고려하여 전체 디자인에 알릴 수있게하는 것은 가치가 있으며 나중에 균열을 극복하려고 노력하는 것을 능가합니다.

데이터베이스 수준에서 비즈니스 논리와 무결성을 강화하기 위해 포괄적 인 제약이있는 데이터베이스를 사용하는 것을 선호합니다. 종종 데이터베이스를 응용 프로그램으로 간주하고 단순한 인터페이스로 액세스하는 모든 것을 봅니다. 이로 인해 다른 "인터페이스"를보다 즐겁고 간단한 경험으로 추가 할 수 있으며 보안에 긍정적 인 이점이 있습니다.

또한 데이터베이스 구조를 다른 엔티티를 시작하기 전에 마무리하고 봉인해야한다고 가정하는 대신 변경 엔티티로 간주하는 것이 중요하다고 생각합니다. 버전 관리 시스템에서 변경을 계획하고 DB를 수용해야합니다. Martin Fowler & Pramod Sadalage의 진화 데이터베이스 디자인 (또한 필자가 읽지 않았지만 Sadalage의 주제에 대한 전체 책)에 대한 좋은 에세이 가 있습니다.

마지막으로, 사용자 계정 / 역할의 주변 문제, 하드웨어 / 위치 / 호스트 연결 등이 중요하며 간과되는 경우가 있습니다. 계획 할 때 이것도 명심하십시오.

데이터 사용 방법을 고려하지 않고는 데이터베이스 설계를 완전히 수행 할 수 없으므로 다음과 같은 간단한 단계 목록이 있습니다.

• 엔티티 간의 관계를 포착하는 짧은 문장을 작성
• 문장을 나타내는 실체 관계 다이어그램을 그리십시오
• ER 다이어그램에서 표준화 된 논리 데이터 모델 작성
• 응용 프로그램 및 엔터티에 대한 CRUD 매트릭스 만들기
• 매트릭스를 사용하여 각 엔티티의 수명주기의 적용 범위를 확인하십시오.
• 각 응용 프로그램에 대한 하위 스키마 추출
• 각 주요 / CRUD 작업에 대한 하위 스키마를 통한 탐색 경로를 검사합니다.
• 필요한 보고서를 고려하십시오
• 위의 모든 것을 기반으로 실제 데이터 모델을 설계합니다. 적절한 경우 스타 스키마를 비정규 화, 분할 및 사용

데이터베이스를 성공적으로 디자인하려면 먼저 몇 가지 사항을 고려해야합니다.

• 어떤 데이터를 저장해야하는지 그리고 내가 저장 한 다른 데이터와 어떤 관련이 있습니까? 이 데이터는 시간이 지남에 따라 어떻게 변해야합니까? 시간에 맞춰 스냅 샷을 볼 수 있어야합니까 (2009 년 순서) 또는 현재 상태 인 스냅 샷 만 필요합니까 (활성 사용자 만)?
• 내 데이터가 의미 있고 시간이 지남에 따라 의미를 유지하도록하려면 어떻게해야합니까 (데이터 무결성)?
• 데이터 액세스가 빠른지 어떻게 확인할 수 있습니까?
• 데이터 보안을 유지하려면 어떻게해야합니까?

따라서 데이터베이스 설계를 시작하기 전에 먼저 데이터 무결성을 유지하는 데 사용되는 정규화 및 데이터베이스 기능에 대해 알아야합니다.

그런 다음 성능 조정을 이해해야합니다. 이는 초기 단계가 아니며 성능은 대부분의 데이터베이스에서 중요한 실패 지점이며 수백만 개의 레코드가 있으면 수정하기가 매우 어렵습니다.

마지막으로 데이터를 보호하는 방법과 보호해야 할 데이터 및 데이터가 악의적으로 변경되지 않도록하기 위해 필요한 내부 제어 기능과 시간이 지남에 따라 변경 사항을 추적하여 누가 언제 언제인지 확인할 수 있도록 필요한 내부 제어 기능을 이해해야합니다. 변경되어 이전 버전으로 되돌릴 수 있습니다.

나중에 리팩토링해야하므로 시작하기 전에 데이터베이스 리팩토링에 대해 조금 읽어 보는 것이 좋으며 가능한 한 쉽게 리팩토링 할 수 있도록 설정하는 방법을 아는 것이 도움이됩니다.

일반적으로 데이터는 수년 동안 애플리케이션보다 수명이 오래 걸리므로 애플리케이션의 핵심이며 대부분 관련이없는 바보 같은 데이터 저장소로 간주되어서는 안됩니다.

일반적으로 좋은 데이터베이스 디자인은 좋은 데이터베이스 디자인입니다. 웹 사용에 대한 더 큰 문제는 데이터에 액세스하고 기본적으로 웹에없는 상태가 필요한 것으로 간주하는 것을 관리하는 방법입니다.

그것에 대해 생각할 때, 나의 접근 방식은 실제로 많은 경험을 기반으로합니다 ...하지만 스키마 또는 객체로 시작하든 실제로 동일한 작업을 수행하려고합니다. 즉 사용 가능한 데이터 모델을 구축하십시오. 프로젝트는 모델과 스키마 사이에 상당히 직접적인 관계가있을 가능성이 있기 때문에 (모든 경우에, 그리고 아마도 모든 테이블 / 객체에 대해는 아님) 실제로 편안하고 거기서 일하는 어느 곳에서나 괜찮은 모델을 만드는 문제입니다.

괜찮은 모델을 구축하는 측면에서 @Tim은 데이터베이스를 위해 다운되었으며, 기본적으로 객체 모델을 구축하는 것은 매우 독창적이며, 계층 구조는 무엇이며, 관계는 많고 많은 관계가 있습니다. 데이터베이스에 접속하여 모든 좋은 일을하는지 확인하십시오.

또한 스키마를 처음부터 새로 작성하고 변경할 때 업데이트 할 수 있도록 코드에 스크립트 또는 ddl이 있는지 확인하십시오 (코드에서 ddl이 선호되는 방법입니다-시스템이 있으며 작동합니다).

큰 화이트 보드와 여러 가지 색상의 펜으로 시작합니다. 다른 색은 다른 것을 의미합니다. 그리고 난 그냥 그리기 시작합니다. 보통 나는 검은 색으로 명확한 것, 푸른 색으로 보일 수있는 것, 초록색이 아닌 것 같은 것을 그립니다. 빨간색은 중요한 메모입니다. 나는 잘 지내고 다시 그립니다. 어떤 종류의 쿼리를해야하는지 생각하고 모델이이를 지원하는지 확인합니다. 그렇지 않으면 내가 할 때까지 조정할 것입니다.

결국 모델이 너무 커지면 Visio로 옮기고 화이트 보드에서 다시 작업합니다.

마지막으로 확장 점에 대해 생각합니다. 내가 대부분의 사람들이 저지르는 가장 큰 실수는 데이터베이스를 디자인 한 다음 "데이터베이스로 끝났습니다"라고 말하고 계속 진행하는 것입니다. 당신은 데이터베이스를 다한 적이 없습니다. 귀하가받는 모든 단일 변경 요청은 해당 수준까지 내려갈 것입니다. 그것에 추가하는 방법에 대해 생각하십시오. 어떤 종류의 요청이 있을지 생각해보고이를 연결할 수 있는지 확인하십시오. 확장성에 대해 전혀 생각하지 않으면 이러한 변경 요청이있을 때 주요 디자인 부채가 발생합니다.

"SQL then ORM"의 경우는 그 반대입니다. 모델이 먼저 좋은 기초가되도록하십시오.

먼저 객체를 디자인 한 다음 ORM (예 : nHibernate)을 사용하여 스키마를 만듭니다. 그것은 반전을하는 것보다 훨씬 더 유연성을줍니다.

다음 단계는 생성 된 스키마의 최적화입니다.

데이터베이스 테이블이 처음 설계된 프로젝트를 본 지 오래되었습니다.

다른 사람들이 지금까지 명시 적으로 언급하지 않은 것은 거의 없습니다.

• 데이터베이스 디자인은 전문가가 수행하는 것이 가장 좋습니다. 물론 배우는 것은 좋지만 모델링 또는 데이터베이스 디자인에 정통하지 않은 중간 또는 큰 모델을 작성하는 것은 권장하지 않습니다. 그 이유는 잘못된 설계 비용이 일반적으로 매우 높기 때문입니다.

• 시스템 목표와 사용자 요구 사항을 잘 알고 있어야합니다. 요구 사항을 모르면 올바른 데이터 모델을 설계 할 수 없습니다.

• 프로그램에서 수행 할 코드와 DB가 처리 할 코드를 알고 있어야합니다. 이것은 데이터 열의 null이 아닌 null 등을 올바르게 설정하기 위해 필요합니다. 또한 RI를 올바르게 지정하기 위해 필요합니다.

• 기본 키를 잘 결정하십시오. 가능하면 간단한 키를 찾으십시오.

• 다른 응용 프로그램과의 통합 요구를 고려하십시오.

• 범용 데이터 모델 사용을 고려하고 명명 및 데이터 열 크기에서 산업 표준을 따르십시오.

• 미래의 요구를 생각하십시오 (알고있을 때와 해당 될 때)

• 다른 사람들이 모드를 검토하도록하십시오.

• 모델링 도구-ERD 도구 또는 UML 도구를 사용하십시오.

• 생성 된 DDL 코드를 검토하고 이해하십시오. 당연한 것으로 여기지 마십시오.