비정규 화 : 어느 정도가 너무 많습니까?

Question

저는 웹 앱을위한 데이터베이스를 설계했습니다. 저는 "책"을 만들고 있습니다. 즉, 나는했습니다 :

• 앱의 실체를 포함하는 ER 다이어그램, 속성, 관계
• 은 "노 스키마에 스키마를 번역 스키마
• 에있는 ER 다이어그램을 번역 만든 "형식으로 데이터베이스를 모델링합니다 (데이터베이스는 Cassandra (NoSQL) 데이터베이스 임).

모든 것이 잘 진행되고 있습니다 (지금까지). 이전에 비정규 화하여 큰 결과를 얻었으며 아직 비정규 화되지 않은 데이터를 사용하는 앱의 일부를 구현하고 있습니다. 이 특정 부분에 대해 이렇게하면 성능이 다소 향상 될 것입니다 (7 대신 Column_Family (관계형의 "표")에서 읽음).

그러나 너무 많이 비정규화할 수도 있습니다. 문제의 부분에 대해 그렇게 할 예정이라면 내 응용 프로그램의 Column_Family/table 수를 약 20 % 줄이고 데이터베이스의 상당 부분을 비정규 화하면 어떤 이유로 긴장하게됩니다.

응용 프로그램이 데이터베이스 디자이너 나 관리자를 선내에서 얻을 수있는 성공을 거둘 수만 있다면, 내가 수행하는 비정규 화가 필요하다는 것을 결정할 수 있기를 바랍니다. 성능 (최선의 경우) 또는 최소한 유해하지 않은 (최악의 경우) 성능을 추구합니다.

비정규 화 결정을 내릴 때주의해야 할 사항이 있습니까? 그렇게하는 것이 나쁜 것인지, 아니면 항상 유지 보수 가능성에 달려 있습니까?

Answer 1

는 매우 다르다 SQL 데이터베이스에 대한 스키마를 설계하는 것보다. SQL 데이터베이스를 사용하면 데이터가 하나의 시스템에 적합하므로 데이터베이스가 색인을 유지 관리하고 조인을 수행 할 수 있으며 SQL을 사용하여 복잡한 쿼리를 수행 할 수 있습니다. 이것들은 모두 정규화 데이터를 실용적으로 만듭니다.

데이터가 하나의 시스템에 적합하지 않아 조인을 수행 할 수 없으므로 효율적으로 수행 할 수있는 쿼리는 키의 범위를 가져 오는 것입니다. 따라서 cassandra는 제한된 인덱스 만 유지합니다. 이렇게하면 데이터를 비실용적으로 정규화 할 수 있습니다.

카산드라에서는 일반적으로 만들 쿼리를 제공하도록 스키마를 디자인하고이를 비정규 화합니다. 이것의 나의 마음에 드는 예는

For example, say someone clicks on a t.co link to blog.example.com/foo at 11:41am on 1st Feb. 
Rainbird would increment counters for: 

t.co click: com (all time) 
t.co click: com.example (all time) 
t.co click: com.example.blog (all time) 
t.co click: com.example.blog /foo (all time) 
t.co click: com (1st Feb 2011) 
t.co click: com.example (1st Feb 2011) 
t.co click: com.example.blog (1st Feb 2011) 
t.co click: com.example.blog /foo (1st Feb 2011) 
t.co click: com (11am-12 on 1st Feb) 
t.co click: com.example (11am-12 on 1st Feb) 
t.co click: com.example.blog (11am-12 on 1st Feb) 
t.co click: com.example.blog /foo (11am-12 on 1st Feb) 
t.co click: com (11:41-42 on 1st Feb) 
t.co click: com.example (11:41-42 on 1st Feb) 
t.co click: com.example.blog (11:41-42 on 1st Feb) 
t.co click: com.example.blog /foo (11:41-42 on 1st Feb) 

이 1 클릭 할 수있는 16 개 개의 쿼리를 만족시키기 위해 16 번 복사,이 post에 설명 된대로 트위터 레인 버드에 대한 자신의 통계 위해하는 것입니다.

이것은 how to do indexing in cassandra에 대한 좋은 프레젠테이션입니다.

Answer 2

일반적으로 허용 할 수있는만큼의 정규화가 필요합니다. 특히 커질 가능성이 큰 테이블과 관련하여 특히 그렇습니다. 매우 작은 데이터 세트 나 직접 관련 데이터의 표준화를 건너 뛰었지만 결코 성능상의 이유를 개선하지는 않습니다 (서버 및 ETL보고 용). 디자인에서 추가 노력을하고 아주 작고 직접 관련된, 거의 변화하지 않는 테이블에 다시 참여하는 것은 개발의 관점에서 볼 때 시간 낭비입니다.

비정규 화와 관련하여 가장 궁금한 점은 데이터 무결성과 공간 낭비 (디스크 및 메모리)의 순서입니다.

정규화에 대한 나의 관심사는 유지 관리 가능성입니다. 실제로 필요한 것보다 훨씬 단순한 무언가를 만드는 것은 일반적으로 효과가 없습니다. 정규화를위한 정규화는 내가 염려하는 한 광신적이며 Sith만이 절대적으로 거래한다.

Answer 3

성능을 위해 비정규 화하는 것은 나쁜 일이 아닙니다. 고려해야 할 사항은 응용 프로그램/데이터베이스의 목표와 정규화가 어떻게 달성 할 수 있는지입니다.

우선, 1NF에 테이블을 두는 것은 중복 데이터 또는 (Coronel, Rob 2009) "반복 그룹"을 제거하는 것을 포함합니다. 여러 위치 (다른 테이블 또는 행)에서 데이터를 제거하는 것은 좋은 일이며 유지 보수, 데이터 무결성 및 성능을 향상시키는 데 도움이됩니다.

2NF를 얻는 것은 부분적인 의존성을 제거하는 것을 포함합니다. 복합 키 (여러 키 필드로 구성된 기본 키)와 키의 일부 또는 전부에 의해 값이 결정되는 필드가있는 경우 부분 종속성이 있습니다. 일반적으로 부분 종속성을 제거하면 다 대다 관계를 처리하기 위해 만들어진 브리지 테이블을 볼 수 있습니다.

3NF는 전이 종속성 또는 키가 아닌 필드의 값에 종속 된 필드를 제거한다는 점에서 추가 단계입니다. 이 단계는 성과 이름으로 종종 협상 할 수있는 단계입니다. 전 이적 필드의 크기 또는 분산에 따라 테이블에 해당 값을 유지해야하는 어려움을 극복하고 그 빈도를 얻기 위해 얼마나 자주 JOIN 할지를 결정해야합니다.

중복 데이터 제거 및 종속 데이터 (부분 및 전이)는 좋은 방법입니다. 그러나 귀하의 응용 프로그램에 적합한 것을하지 못하게하십시오.

는 "데이터베이스 시스템 설계 구현 및 관리"

C. 코로 넬, P. 롭 (2009) , 과정 기술, 보스턴, MA 카산드라에 대한 스키마를 설계. (5 장)