데이터 모델링: 데이터 구조 설계

앱으로 데이터를 저장하거나 볼 때 디자인의 중요한 부분은 데이터 구조입니다. 하나의 특정 앱이나 화면에서 데이터가 사용되는 방법뿐만 아니라 다른 사람이 데이터를 사용하는 방법을 고려하십시오. 개인 정보, 작업, 비즈니스 프로세스 및 목표를 다시 참조하면 저장할 데이터 및 구조를 정의하는 데 도움이 됩니다.

팁

Access 데이터베이스용으로 작성되었지만 데이터 디자인 기본 사항에 대한 이 기사는 데이터 모델링 원칙: 데이터베이스 디자인 기본 사항에 대한 일반적인 설명을 제공합니다.

다음 경비 보고서를 예로 들어 보겠습니다.

직원 이름 및 부서 세부 사항이 있는 경비 보고서의 주요 부분이 표시됩니다. 주요 부분 아래에 구매한 각 항목에 대한 여러 행의 설명이 표시됩니다. 이를 품목이라고 합시다. 품목은 경비 보고서의 주요 부분과 구조가 다릅니다. 따라서 모든 경비 보고서에 대해 여러 개의 품목이 있다고 말할 수 있습니다.

이러한 종류의 데이터를 데이터베이스에 저장하려면 데이터베이스 디자인에서 데이터 구조를 모델링해야 합니다.

일대다(1:N) 데이터 구조

이것은 이전 예에서 설명한 데이터 구조 유형입니다. 경비 보고서의 주요 부분은 여러 품목에 연결되어 있습니다. (품목의 관점에서 많은 품목과 하나의 경비 보고서(N:1)의 관계를 확인할 수도 있습니다.)

다대다(N:N) 데이터 구조

다대다 데이터 구조는 특별한 유형입니다. 여러 레코드가 다른 여러 레코드 집합과 연결될 수 있는 경우에 해당됩니다. 좋은 예는 비즈니스 파트너 네트워크입니다. 함께 일하는 여러 비즈니스 파트너(고객 및 공급업체)가 있으며 해당 비즈니스 파트너도 여러 동료와 협력합니다.

데이터 모델링 예

시스템에서 발생할 수 있는 여러 유형의 모델링이 있습니다. 몇 가지 예제를 생각해 봅시다.

예 1: 휴가 승인 요청

이 간단한 예는 두 데이터 집합을 보여줍니다. 하나는 직원이고 다른 하나는 휴가 요청입니다. 각 직원이 여러 요청을 제출하므로 여기서의 관계는 일대다입니다. 여기서 "일"은 직원이고 "다"는 요청입니다. 직원 데이터와 휴가 요청 데이터는 직원 번호를 공통 필드(키라고도 함)로 지정하여 서로 관련이 있습니다.

예 2: 구매 승인

여기서 데이터 구조는 매우 정교해 보이지만 이 문서의 시작 부분에서 설명한 경비 보고서 예제와 매우 유사합니다. 각 벤더 또는 공급업체는 여러 구매 주문과 연관되어 있습니다. 각 직원은 여러 구매 주문을 담당합니다. 따라서 이 두 데이터 집합은 일대다 데이터 구조를 갖습니다.

직원이 항상 같은 벤더 또는 공급업체를 사용하는 것은 아니므로 여러 직원이 벤더를 이용하고 각 직원은 여러 공급업체와 협력합니다. 따라서 직원과 벤더 간의 관계는 다대다입니다.

예 3: 경비 보고

다음 단계: 어떤 유형의 앱을 만들지 결정

참고

귀사의 설명서 언어 기본 설정에 대해 말씀해 주시겠습니까? 간단한 설문 조사에 응해주세요. (이 설문 조사는 영어로 되어 있습니다.)

이 설문 조사는 약 7분 정도 걸립니다. 개인 데이터는 수집되지 않습니다(개인정보처리방침).