데이터베이스 설계

Database design

데이터베이스 설계는 데이터베이스 모델에 따라 데이터를 구성하는 것입니다.설계자는 저장해야 하는 데이터와 데이터 요소의 상관 관계를 결정합니다.이 정보를 사용하여 데이터를 데이터베이스 [1]모델에 맞추기 시작할 수 있습니다.데이터베이스 관리 시스템은 이에 따라 데이터를 관리한다.

데이터베이스 설계에는 데이터를 분류하고 상호 관계를 식별하는 작업이 포함됩니다.이러한 데이터의 이론적 표현을 온톨로지라고 합니다.온톨로지는 데이터베이스 설계의 이면에 있는 이론입니다.

저장할 데이터 결정

대부분의 경우 데이터베이스 설계를 하고 있는 사람은 재무정보, 생체정보 등 저장해야 할 데이터가 도출되는 영역의 전문지식이 아니라 데이터베이스 설계 분야의 전문지식을 가진 사람이다.따라서 데이터베이스에 저장되는 데이터는 해당 도메인에 대한 전문지식을 가지고 시스템 내에 저장해야 하는 데이터를 알고 있는 사람과 협력하여 결정해야 합니다.

이 프로세스는 일반적으로 요구사항 분석의 일부로 간주되며 도메인 지식을 가진 사용자로부터 필요한 정보를 이끌어내기 위해 데이터베이스 설계자의 기술이 필요합니다.이는 저장해야 하는 개별 데이터 요소에 대한 생각에 익숙하지 않기 때문에 필요한 도메인 지식을 가진 사람들은 데이터베이스에 대한 시스템 요구 사항이 무엇인지 명확하게 표현하지 못하는 경우가 많기 때문입니다.저장할 데이터는 요건 [2]사양에 따라 결정할 수 있습니다.

데이터 관계 결정

데이터베이스 설계자는 데이터베이스에 저장해야 하는 데이터를 인식한 후 데이터 내의 종속성이 어디에 있는지 확인해야 합니다.데이터가 변경될 때 보이지 않는 다른 데이터가 변경될 수 있습니다.예를 들어, 이름 및 주소 목록에서 여러 사람이 동일한 주소를 가질 수 있지만 한 사람이 여러 주소를 가질 수 없는 경우 주소는 이름에 따라 달라집니다.이름과 목록을 지정하면 주소를 고유하게 결정할 수 있지만, 주소 및 목록을 지정하면 여러 사람이 주소에 상주할 수 있기 때문에 이름을 고유하게 결정할 수 없습니다.주소는 이름에 따라 결정되므로 주소는 이름에 따라 달라지는 것으로 간주됩니다.

(주: 일반적인 오해는 데이터 요소 간의 관계를 기술하기 때문에 관계 모델을 호출하는 것입니다.그건 사실이 아니야.관계 모델은 관계라고 알려진 수학적 구조에 기초하기 때문에 그렇게 명명되었습니다.)

데이터 논리 구조화

주요 기사:논리 스키마

여러 정보 간의 관계와 의존성이 결정되면 데이터를 논리 구조로 배열하여 데이터베이스 관리 시스템에서 지원하는 스토리지 객체에 매핑할 수 있다.관계형 데이터베이스의 경우 스토리지 개체는 행과 열에 데이터를 저장하는 테이블입니다.개체 데이터베이스에서 스토리지 개체는 데이터를 관리하고 액세스할 애플리케이션을 쓰는 데 사용되는 개체 지향 프로그래밍 언어가 사용하는 개체에 직접 해당합니다.관계는 관련된 오브젝트클래스의 속성 또는 오브젝트클래스에서 동작하는 메서드로 정의할 수 있습니다.

이 매핑이 일반적으로 수행되는 방법은 실제든 추상이든 단일 개체에 의존하는 관련 데이터 세트를 테이블에 배치하는 것입니다.그런 다음 이러한 종속 개체 간의 관계가 다양한 개체 간의 링크로 저장됩니다.

각 테이블은 논리 객체의 구현 또는 하나 이상의 논리 객체의 하나 이상의 인스턴스를 결합하는 관계를 나타낼 수 있다.그런 다음 테이블 간의 관계를 하위 테이블과 부모 테이블을 연결하는 링크로 저장할 수 있습니다.복잡한 논리관계는 그 자체가 테이블이기 때문에 여러 부모에 대한 링크가 있을 수 있습니다.

ER 다이어그램(항체-관계 모형)

샘플 엔티티-관계도

데이터베이스 설계에는 ER(Entity-Relationship Model) 다이어그램도 포함됩니다.ER 다이어그램은 데이터베이스를 효율적으로 설계하는 데 도움이 되는 다이어그램입니다.

ER 다이어그램의 속성은 일반적으로 속성을 포함하는 엔티티 또는 관계에 링크된 속성의 이름을 가진 타원형으로 모델링됩니다.

ER 모델은 정보 시스템 설계에서 일반적으로 사용됩니다. 예를 들어 개념 구조 설계 [3]단계에서 데이터베이스에 저장되는 정보 요건 및/또는 정보의 유형을 설명하는 데 사용됩니다.

Microsoft Access 설계 프로세스 제안

  1. 데이터베이스의 용도 결정 - 나머지 단계를 준비하는 데 도움이 됩니다.
  2. 필요한 정보 찾기 및 구성 - 제품 이름 및 주문 번호 등 데이터베이스에 기록할 모든 유형의 정보를 수집합니다.
  3. 정보를 표로 나누기 - 정보 항목을 제품이나 주문과 같은 주요 엔티티 또는 주제로 나눕니다.각 피사체가 표가 됩니다.
  4. 정보 항목을 열로 변환 - 각 테이블에 저장해야 하는 정보를 결정합니다.각 항목은 필드가 되고 테이블에 열로 표시됩니다.예를 들어 직원 테이블에는 성 및 고용 날짜와 같은 필드가 포함될 수 있습니다.
  5. 기본 키 지정 - 각 테이블의 기본 키를 선택합니다.기본 키는 각 행을 고유하게 식별하는 데 사용되는 열 또는 열 세트입니다.예를 들어 제품 ID 또는 주문 ID가 있습니다.
  6. 테이블 관계 설정 - 각 테이블을 보고 한 테이블의 데이터와 다른 테이블의 데이터가 어떻게 관련되어 있는지 결정합니다.필요에 따라 테이블에 필드를 추가하거나 새 테이블을 생성하여 관계를 명확히 합니다.
  7. 설계 세분화 - 설계에서 오류를 분석합니다.테이블을 만들고 샘플 데이터의 레코드를 추가합니다.표에서 결과가 예상대로 나오는지 확인합니다.필요에 따라 설계를 조정합니다.
  8. 정규화 규칙 적용 - 데이터 정규화 규칙을 적용하여 테이블이 올바르게 구성되었는지 확인합니다.필요에 따라 테이블을 조정합니다.

[4]

정규화

주요 기사: 데이터베이스 정규화

관계형 데이터베이스 설계 분야에서 정규화는 데이터베이스 구조가 범용 쿼리에 적합하고 데이터 무결성을 잃을 수 있는 특정 바람직하지 않은 특성(삽입, 업데이트 및 삭제)이 없음을 보증하는 체계적인 방법입니다.

데이터베이스 설계 지침의 표준 부분은 설계자가 완전히 정규화된 설계를 작성해야 한다는 것입니다. 이후 선택적 정규화를 수행할 수 있는 것은 성능상의 이유뿐입니다.단점은 스토리지 공간과 성능입니다.설계가 정규화될수록 데이터의 용장성이 적어집니다(따라서 저장 공간이 적어집니다). 그러나 일반적인 데이터 검색 패턴에서는 복잡한 결합, 병합 및 정렬이 필요하게 되어 데이터 읽기 및 계산 사이클이 증가합니다.데이터 웨어하우스 설계에 대한 치수 모델링 접근법과 같은 일부 모델링 분야에서는 비정규화된 설계, 즉 대부분 3NF를 준수하지 않는 설계를 명시적으로 권장하고 있습니다.정규화는 1NF, 2NF, 3NF, BOYCE-CODD NF(3.5)의 정규 형태로 구성됩니다.NF), 4NF 및 5NF

문서 데이터베이스는 다른 접근 방식을 취합니다.이러한 데이터베이스에 저장된 문서에는 일반적으로 둘 이상의 정규화된 데이터 단위와 장치 간의 관계도 포함됩니다.모든 데이터 단위와 문제의 관계가 함께 검색되는 경우가 많은 경우, 이 방법은 검색 수를 최적화합니다.또한 데이터 복제 방법을 단순화합니다. 이제 일관성 있는 데이터를 명확하게 식별할 수 있는 단위가 자체적으로 존재하기 때문입니다.또 다른 고려사항은 이러한 데이터베이스에서 단일 문서를 읽고 쓰는 것은 단일 트랜잭션을 필요로 한다는 것입니다. 이는 마이크로 서비스 아키텍처에서 중요한 고려사항이 될 수 있습니다.이러한 상황에서는 대부분의 경우 문서의 일부가 API를 통해 다른 서비스에서 검색되고 효율성을 위해 로컬로 저장됩니다.데이터 유닛이 서비스 전체에 분산되어 있는 경우, 서비스 소비자를 지원하기 위한 읽기(또는 쓰기)에 여러 서비스 콜이 필요할 수 있으며, 이로 인해 여러 트랜잭션이 관리될 수 있으며, 이는 바람직하지 않을 수 있습니다.

개념 스키마

주요 기사:개념 스키마

물리 설계

주요 기사:물리 스키마

데이터베이스의 실제 설계는 저장 미디어에 있는 데이터베이스의 실제 구성을 지정합니다.여기에는 DBMS 데이터 사전에 있는 데이터 요소, 데이터 유형, 인덱싱 옵션 및 기타 매개 변수의 자세한 사양이 포함됩니다.모듈 및 데이터베이스의 하드웨어 및 시스템 소프트웨어 사양을 포함하는 시스템의 상세 설계입니다.물리 계층에서 해결되는 몇 가지 측면:

  • 보안 - 최종 사용자 및 관리 보안.
  • 복제 - 다른 데이터베이스로 복사되는 데이터 조각과 빈도를 지정합니다.마스터는 여러 개입니까, 아니면 한 개입니까?
  • 하이 어베이러빌리티 - 구성이 액티브-패시브인지 액티브-액티브인지에 관계없이 토폴로지, 조정 방식, 신뢰성 목표 등을 모두 정의해야 합니다.
  • 파티션 분할 - 데이터베이스가 분산되어 있는 경우 단일 엔티티에 대해 데이터베이스의 모든 파티션 간에 데이터가 어떻게 분산되며 파티션 장애가 어떻게 고려됩니까?
  • 백업 및 복원 구성표.

응용 프로그램 수준에서 물리적 설계의 다른 측면에는 저장 프로시저, 구체화된 쿼리 뷰, OLAP 큐브 등을 정의할 필요성이 포함될 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Teorey, T.J., Lightstone, S.S., et al., (2009)데이터베이스 설계: 모든 것을 알고 있습니다.1차판벌링턴, 매사추세츠주: 모건 카우프만 출판사
  2. ^ Teorey, T.; Lightstone, S. 및 Nadeau, T. (2005) 데이터베이스 모델링 및 설계: 논리설계, 제4판, 모건 카우프만 프레스 ISBN0-12-685352-5
  3. ^ Javed, Muhammad; Lin, Yuqing (2018). "Iterative Process for Generating ER Diagram from Unrestricted Requirements". Proceedings of the 13th International Conference on Evaluation of Novel Approaches to Software Engineering. SCITEPRESS - Science and Technology Publications: 192–204. doi:10.5220/0006778701920204. ISBN 978-989-758-300-1.
  4. ^ 데이터베이스 설계의 기본 (n.d.)데이터베이스 설계의 기본.2010년 5월 1일 https://support.office.com/en-US/article/Database-design-basics-EB2159CF-1E30-401A-8084-BD4F9C9CA1F5에서 취득

추가 정보

  • S. 라이트스톤, TTeorey, T. Nadeau, "물리 데이터베이스 설계: 데이터베이스 전문가의 인덱스, 뷰, 스토리지 등 활용 가이드", Morgan Kaufmann Press, 2007.ISBN 0-12-369389-6
  • M. Hernandez, "Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design", 제3판, Adison-Wesley Professional, 2013.ISBN 0-321-88449-3

외부 링크