고성능 앱을 위한 데이터베이스 설계 모범 사례

응용 프로그램이 좋은 성능을 발휘하려면 강력한 응용 프로그램 서버, 보장된 충분한 대역폭, 잘 수행된 프로그래밍 작업이 필요합니다. 그러나 항상 고려되지 않고 일반적으로 모든 애플리케이션의 성능에 큰 영향을 미치는 한 가지 측면이 있습니다. 바로 데이터베이스 설계 입니다.

이제 데이터 액세스가 애플리케이션 성능에 부정적인 영향을 미치는 병목 현상이 아닌지 확인하기 위해 데이터베이스 설계 모범 사례를 살펴보겠습니다.

좋은 데이터베이스 디자인의 목적은 무엇입니까?

데이터 액세스 성능을 향상시키는 것 외에도 좋은 디자인은 데이터 일관성, 정확성 및 안정성을 유지하고 중복을 제거하여 저장 공간을 줄이는 것과 같은 다른 이점을 제공합니다. 좋은 디자인의 또 다른 이점은 데이터베이스를 사용하고 유지 관리하기가 더 쉽다는 것입니다. 이를 관리해야 하는 사람은 ERD(Entity-Relationship Diagram)만 보고 구조를 이해하면 됩니다.

ERD는 데이터베이스 설계의 기본 도구입니다. 개념적 , 논리적 및 물리적 세 가지 디자인 수준에서 만들고 시각화할 수 있습니다.

개념 설계는 데이터베이스의 기술적 세부 사항을 이해할 필요가 없는 프로젝트 이해 관계자와 기준에 동의하는 데 필요한 요소만 포함된 매우 요약된 다이어그램을 보여줍니다. 논리적 디자인은 엔터티와 엔터티의 관계를 자세히 보여주지만 데이터베이스에 구애받지 않는 방식으로 보여줍니다.

ERD에서 데이터베이스 설계를 용이하게 하는 데 사용할 수 있는 많은 도구가 있습니다. 가장 좋은 것은 DbSchema , SqlDBM 및 Vertabelo 입니다.

DB스키마

DbSchema를 사용하면 SQL, NoSQL 또는 Cloud 데이터베이스를 시각적으로 디자인하고 관리할 수 있습니다. 이 도구를 사용하면 컴퓨터에서 스키마를 설계하고 여러 데이터베이스에 배포하고 HTML5 다이어그램으로 문서를 생성하고 쿼리를 작성하고 데이터를 시각적으로 탐색하는 등의 작업을 수행할 수 있습니다. 또한 스키마 동기화, 임의 데이터 생성 및 자동 완성 기능을 통한 SQL 코드 편집 기능을 제공합니다.

SQLDBM

SqlDBM은 모든 브라우저에서 데이터베이스를 쉽게 디자인할 수 있는 방법을 제공하기 때문에 최고의 데이터베이스 다이어그램 디자인 도구 중 하나입니다. SqlDBM을 사용하면 기존 데이터베이스에서 스키마를 가져올 수 있지만 이를 사용하는 데 다른 데이터베이스 엔진이나 모델링 도구가 필요하지 않습니다. 동료와 디자인 프로젝트를 공유할 수 있으므로 팀워크에 이상적입니다.

베르타벨로

Vertabelo는 데이터베이스를 논리적으로 설계하고 물리적 스키마를 자동으로 파생할 수 있는 온라인 시각적 데이터베이스 설계 도구입니다. 소유자, 편집자 및 뷰어에 대한 액세스 권한을 구분하여 리버스 엔지니어링하고 기존 데이터베이스에서 다이어그램을 생성하고 다이어그램에 대한 액세스를 제어할 수 있습니다.

마지막으로 물리적 설계는 ERD에 MySQL, MariaDB, MS SQL Server 등과 같은 특정 DBMS에서 사용 가능한 데이터베이스로 전환하는 데 필요한 모든 세부 정보를 추가하는 것입니다. 결과 데이터베이스가 최상의 상태로 작동하도록 ERD를 설계할 때 염두에 두어야 할 모범 사례를 살펴보겠습니다.

설계할 데이터베이스 유형 정의

데이터베이스의 두 가지 기본 유형은 일반적으로 관계형 및 차원 으로 구분됩니다.

관계형 데이터베이스는 데이터에 대한 트랜잭션을 실행하는 기존 애플리케이션에 사용됩니다. 즉, 데이터베이스에서 정보를 가져와 처리하고 결과를 저장합니다.

반면에 차원 데이터베이스는 통찰력을 얻기 위한 데이터 분석 및 데이터 마이닝을 위한 정보의 대규모 저장소인 데이터 웨어하우스 생성에 사용됩니다.

모든 데이터베이스 디자인 작업의 첫 번째 단계는 작업할 두 가지 주요 데이터베이스 유형인 관계형 또는 차원 중 하나를 선택하는 것입니다. 디자인을 시작하기 전에 이것을 명확히 하는 것이 중요합니다. 그렇지 않으면 결국 많은 문제를 일으키고 수정하기 어려운(또는 불가능한) 설계 실수에 쉽게 빠질 수 있습니다.

명명 규칙 채택

데이터베이스 디자인에 사용된 이름은 데이터베이스에 생성된 개체의 이름을 변경하면 치명적일 수 있기 때문에 필수적입니다. 이름의 한 글자만 변경하면 종속성, 관계 및 전체 시스템이 손상될 수 있습니다.

이것이 바로 건전한 명명 규칙으로 작업하는 것이 중요한 이유입니다. 기억할 수 없는 개체의 이름을 찾기 위해 50가지 다른 가능성을 시도하는 수고를 덜어주는 일련의 규칙입니다.

작업을 수행하기 위해 명명 규칙이 무엇인지에 대한 보편적인 지침은 없습니다. 그러나 중요한 것은 데이터베이스에 있는 객체의 이름을 지정하고 그 규칙을 영원히 유지하기 전에 명명 규칙을 설정하는 것입니다. 명명 규칙은 밑줄을 사용하여 단어를 구분할지 또는 직접 결합할지, 모두 대문자를 사용할지 또는 단어를 대문자로 할지(Camel Case 스타일), 객체 이름에 복수 단어 또는 단수 단어를 사용할지 여부 등과 같은 지침을 설정합니다.

개념 설계부터 시작하여 논리적 설계, 마지막으로 물리적 설계를 수행합니다.

그것이 자연스러운 일의 순서입니다. 디자이너는 단계를 건너뛰기 위해 DBMS에서 직접 개체를 생성하여 시작하고 싶을 수 있습니다. 그러나 이렇게 하면 설계가 비즈니스 요구 사항을 충족하는지 확인하기 위해 이해 관계자와 논의할 도구를 가질 수 없습니다.

개념적 설계 후에는 프로그래머가 데이터베이스 구조를 이해하는 데 도움이 되는 적절한 문서를 갖도록 논리적 설계로 이동해야 합니다. 사용할 데이터베이스 엔진과 독립적으로 논리적 디자인을 업데이트하는 것이 중요합니다. 이렇게 하면 결국 데이터베이스를 다른 엔진으로 마이그레이션하더라도 논리적 설계가 여전히 유용할 것입니다.

마지막으로, 물리적 디자인은 프로그래머 자신이나 DBA에 의해 생성될 수 있으며, 논리적 디자인을 취하고 특정 DBMS에서 구현하는 데 필요한 모든 구현 세부 사항을 추가합니다.

데이터 사전 생성 및 유지 관리

ERD가 명확하고 서술적일지라도 더 명확하게 만들기 위해 데이터 사전을 추가해야 합니다. 데이터 사전은 특히 개체 수가 크게 증가할 때 데이터베이스 디자인에서 일관성과 일관성을 유지합니다.

데이터 사전의 주요 목적은 데이터 모델의 엔터티 및 해당 속성에 대한 참조 정보의 단일 저장소를 유지 관리하는 것입니다. 데이터 사전에는 모든 엔티티의 이름, 모든 속성의 이름, 형식 및 데이터 유형, 각각에 대한 간략한 설명이 포함되어야 합니다.

데이터 사전은 데이터베이스를 구성하는 모든 요소에 대해 명확하고 간결한 가이드를 제공합니다. 이렇게 하면 동일한 것을 나타내는 여러 개체를 만드는 것을 방지할 수 있으므로 정보를 쿼리하거나 업데이트해야 할 때 어떤 개체에 의존해야 하는지 알기 어렵습니다.

기본 키에 대한 일관된 기준 유지

자연 키 또는 대리 키를 사용하기로 한 결정은 데이터 모델 내에서 일관성이 있어야 합니다. 데이터 모델의 엔터티에 해당 테이블의 기본 키로 효율적으로 관리할 수 있는 고유 식별자가 있는 경우 대리 키를 만들 필요가 없습니다.

그러나 엔터티는 날짜, 숫자 및/또는 긴 문자열과 같은 다양한 유형의 여러 속성으로 식별되는 것이 일반적이며 기본 키를 형성하는 데 비효율적일 수 있습니다. 이러한 경우 인덱스 관리에서 최대 효율성을 제공하는 정수 숫자 유형의 대리 키를 만드는 것이 좋습니다. 엔터티에 고유하게 식별하는 속성이 없는 경우 대리 키는 유일한 옵션입니다.

각 속성에 대해 올바른 데이터 유형을 사용하십시오.

특정 데이터는 데이터를 나타내는 데 사용할 데이터 유형을 선택할 수 있는 옵션을 제공합니다. 예를 들어 날짜. 날짜 유형 필드, 날짜/시간 유형 필드, varchar 유형 필드 또는 숫자 유형 필드에 저장하도록 선택할 수 있습니다. 또 다른 경우는 수학적 연산에 사용되지 않고 운전 면허증 번호 또는 우편 번호와 같은 엔티티를 식별하는 데 사용되는 숫자 데이터입니다.

날짜의 경우 엔진의 데이터 유형을 사용하는 것이 편리하므로 데이터를 조작하기가 더 쉽습니다. 시간을 지정하지 않고 이벤트 날짜만 저장해야 하는 경우 선택할 데이터 유형은 단순히 날짜입니다. 특정 이벤트가 발생한 날짜와 시간을 저장해야 하는 경우 데이터 유형은 DateTime이어야 합니다.

varchar 또는 숫자와 같은 다른 유형을 사용하여 날짜를 저장하는 것이 편리할 수 있지만 매우 특정한 경우에만 가능합니다. 예를 들어, 날짜를 어떤 형식으로 표현할지 미리 알 수 없다면 varchar로 저장하는 것이 편리합니다. 날짜 유형 필드를 처리하는 데 검색 성능, 정렬 또는 인덱싱이 중요한 경우 이전에 float로 변환하면 차이가 날 수 있습니다.

수학적 연산과 관련되지 않은 숫자 데이터는 varchar로 표시되어야 하며 불일치나 반복을 피하기 위해 기록에 형식 유효성 검사를 적용해야 합니다. 그렇지 않으면 일부 데이터가 숫자 필드의 제한을 초과할 위험에 노출되고 이미 프로덕션 단계에 있을 때 디자인을 리팩토링해야 합니다.

룩업 테이블 사용

경험이 부족한 일부 설계자는 설계를 정규화하기 위해 조회 테이블을 과도하게 사용하면 데이터베이스의 ERD가 불필요하게 복잡해질 수 있다고 생각할 수 있습니다. 이는 때때로 소수의 요소를 포함하지 않는 많은 "위성" 테이블을 추가하기 때문입니다. 이렇게 생각하는 사람들은 룩업 테이블을 사용하면 단점보다 장점이 더 많다는 것을 이해해야 합니다. ERD의 복잡성이나 크기가 문제인 경우 다이어그램의 복잡성에도 불구하고 이해할 수 있도록 다양한 방식으로 다이어그램을 시각화할 수 있는 ERD 설계 도구가 있습니다.

이 샘플 쿼리는 잘 설계된 데이터베이스에서 조회 테이블의 올바른 사용을 보여줍니다.

 SELECT StreetName, StreetNumber, Cities.Name AS City, States.Name AS State FROM Addresses INNER JOIN Cities ON Cities.CityId = Addresses.CityId INNER JOIN States ON States.StateId = Addresses.StateId

이 경우 도시 및 주에 대한 조회 테이블을 사용합니다.

조회 테이블의 이점으로는 데이터베이스 크기 감소, 검색 성능 향상, 필드에 포함될 수 있는 유효한 데이터 세트에 대한 제한 적용 등이 있습니다. 또한 모든 조회 테이블에 테이블의 레코드가 사용 중인지 또는 폐기되었는지 여부를 나타내는 비트 또는 부울 필드를 포함하는 것이 좋습니다. 이 필드는 애플리케이션 UI의 옵션으로 사용되지 않는 요소를 피하기 위한 필터로 사용할 수 있습니다.

데이터베이스 유형에 따라 정규화 또는 비정규화

기존 애플리케이션에 사용되는 관계형 데이터베이스에서 정규화는 필수입니다. 정규화는 중복을 방지하여 필요한 저장 공간을 줄이는 것으로 잘 알려져 있습니다. 정보 품질을 개선하고 복잡한 쿼리에서 성능을 최적화하기 위한 여러 도구를 제공합니다.

그러나 다른 유형의 데이터베이스에서는 비정규화라고 하는 기술이 적용됩니다. 데이터 웨어하우스로 사용되는 차원 데이터베이스에서 비정규화는 스키마 테이블에 특정 유용한 중복 정보를 추가합니다.

정반대의 개념처럼 보이지만 비정규화가 정규화를 취소하는 것은 아닙니다. 실제로 쿼리 작성 및 보고를 단순화하기 위해 데이터 모델을 정규화한 후 데이터 모델에 적용하는 최적화 기술입니다.

부품의 물리적 모델 설계

소프트웨어 개발 프로젝트에서 데이터베이스 디자이너는 이해 관계자에게 대규모 개념 모델을 제시하며 여기에는 구현 세부 정보가 표시되지 않습니다. 차례로, 개발자와 함께 작업하기 위해 디자이너는 각 엔터티 및 속성의 모든 세부 정보가 포함된 물리적 모델을 제공해야 합니다. 그러나 두 모델 모두 프로젝트 시작 시 완전히 만들 필요는 없습니다.

애자일 방법론을 적용할 때 각 개발 주기가 시작될 때 각 개발자는 해당 주기 동안 작업할 하나 이상의 사용자 스토리를 사용합니다. 데이터베이스 디자이너의 임무는 각 개발자에게 작업 단위에 필요한 개체만 포함하는 물리적 하위 모델을 제공하는 것입니다.

각 개발 주기가 끝나면 해당 주기 동안 생성된 하위 모델이 병합되어 완전한 물리적 모델이 애플리케이션 개발과 평행하게 형성됩니다.

뷰와 인덱스를 잘 활용하기

뷰와 인덱스는 애플리케이션 성능을 향상시키기 위한 데이터베이스 디자인의 두 가지 기본 도구입니다. 뷰를 사용하면 불필요한 테이블 세부 정보를 숨기고 쿼리를 단순화하는 추상화를 처리할 수 있습니다. 결과적으로 보기는 데이터베이스 엔진이 데이터를 얻는 방법을 예상하고 쿼리 결과를 더 빨리 제공하기 위한 최상의 전략을 선택할 수 있게 해주기 때문에 쿼리 최적화 작업을 더 쉽게 만듭니다.

인덱스는 데이터베이스가 프로덕션 상태에 있으면 사용자 경험을 기반으로 하는 느린 쿼리의 성능을 향상시킬 수 있습니다. 그러나 인덱스 생성은 응용 프로그램의 요구 사항을 예상하여 데이터베이스 디자인 작업의 일부로 수행할 수 있습니다.

인덱스를 생성하려면 레코드 수 측면에서 각 테이블의 크기에 대한 대략적인 아이디어가 필요하고 더 큰 테이블에 대한 인덱스를 생성해야 합니다. 인덱스에 포함할 필드를 선택하려면 주로 외래 키를 나타내는 필드와 검색에서 필터로 사용될 필드를 고려해야 합니다.

작업이 끝났다고 생각되면 리팩토링할 때입니다.

데이터베이스 디자인은 항상 개선될 수 있습니다. 새로운 요구 사항이나 새로운 비즈니스 요구로 인해 데이터베이스에 변경 사항이 없을 때 디자인을 개선하는 리팩토링 절차를 수행할 수 있는 좋은 기회입니다. 리팩토링이란 단순히 데이터베이스의 의미 체계에 영향을 주지 않고 디자인을 개선하는 변경을 도입하는 것을 의미합니다.

이 글의 범위를 벗어나는 데이터베이스 디자인을 개선하기 위한 많은 리팩토링 기술이 있지만, 필요할 때 사용할 수 있도록 그 존재를 아는 것이 좋다.

데이터베이스를 설계해야 할 때마다 이 모범 사례 목록을 준비하면 응용 프로그램이 데이터 액세스에서 항상 최적의 성능을 유지하도록 최상의 결과를 얻을 수 있습니다.