

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 개체 및 데이터 작업: 앱의 데이터 모델 구성
<a name="data"></a>

**개체**는 App Studio의 데이터 테이블입니다. 개체는 데이터 소스의 테이블과 직접 상호 작용합니다. 개체에는 데이터를 설명하는 필드, 데이터를 찾아 반환하는 쿼리, 개체의 필드를 데이터 소스의 열에 연결하는 매핑이 포함됩니다.

**Topics**
+ [데이터 모델 설계 모범 사례](data-model-best-practices.md)
+ [App Studio 앱에서 개체 생성](data-entities-create.md)
+ [App Studio 앱에서 개체 구성 또는 편집](data-entities-edit.md)
+ [개체 삭제](data-entities-delete.md)
+ [AWS App Studio의 관리형 데이터 엔터티](managed-data-entities.md)

# 데이터 모델 설계 모범 사례
<a name="data-model-best-practices"></a>

다음 모범 사례를 사용하여 애플리케이션의 요구 사항을 충족하고 데이터 인프라의 장기 안정성과 성능을 보장하는 App Studio 애플리케이션에서 AWS 사용할 수 있도록에서 강력하고 확장 가능하며 안전한 관계형 데이터 모델을 생성합니다.
+ **올바른 AWS 데이터 서비스 선택: ** 요구 사항에 따라 적절한 AWS 데이터 서비스를 선택합니다. 예를 들어 온라인 트랜잭션 처리(OLTP) 애플리케이션의 경우 MySQL 및 PostgreSQL과 같은 다양한 데이터베이스 엔진을 지원하는 클라우드 네이티브, 관계형 및 완전 관리형 데이터베이스 서비스인 Amazon Aurora와 같은 데이터베이스(DB)를 고려할 수 있습니다. App Studio에서 지원하는 Aurora 버전의 전체 목록은 섹션을 참조하세요[Amazon Aurora에 연결](connectors-aurora.md). 반면 온라인 분석 처리(OLAP) 사용 사례의 경우 매우 큰 데이터 세트에 대해 복잡한 쿼리를 실행할 수 있는 클라우드 데이터 웨어하우스인 Amazon Redshift를 사용하는 것이 좋습니다. 이러한 쿼리는 완료하는 데 종종 시간(몇 초)이 걸릴 수 있으므로 지연 시간이 짧은 데이터 액세스가 필요한 OLTP 애플리케이션에는 Amazon Redshift가 적합하지 않습니다.
+ **확장성을 위한 설계: **향후 성장과 확장성을 염두에 두고 데이터 모델을 계획합니다. 적절한 데이터 서비스, 데이터베이스 인스턴스 유형 및 구성(예: 프로비저닝된 용량)을 선택할 때 예상 데이터 볼륨, 액세스 패턴 및 성능 요구 사항과 같은 요소를 고려합니다.
  + Aurora 서버리스를 사용한 크기 조정에 대한 자세한 내용은 [Aurora 서버리스 V2의 성능 및 크기 조정](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html)을 참조하세요.
+ **데이터 정규화: 데이터베이스 정규화 원칙에 따라 데이터 중복을 최소화하고 데이터 무결성을 개선합니다**. 여기에는 적절한 테이블 생성, 기본 및 외래 키 정의, 엔터티 간 관계 설정이 포함됩니다. App Studio에서 한 엔터티의 데이터를 쿼리할 때 쿼리에 `join` 절을 지정하여 다른 엔터티에서 관련 데이터를 검색할 수 있습니다.
+ **적절한 인덱싱 구현: **가장 중요한 쿼리 및 액세스 패턴을 식별하고 성능을 최적화하기 위한 적절한 인덱스를 생성합니다.
+ ** AWS 데이터 서비스 기능 활용: **자동 백업, 다중 AZ 배포, 자동 소프트웨어 업데이트 등 선택한 AWS 데이터 서비스에서 제공하는 기능을 활용합니다.
+ **데이터 보안: **IAM(AWS Identity and Access Management) 정책과 같은 강력한 보안 조치를 구현하고, 테이블 및 스키마에 대한 권한이 제한된 데이터베이스 사용자를 생성하고, 저장 및 전송 중 암호화를 적용합니다.
+ **성능 모니터링 및 최적화: **데이터베이스의 성능을 지속적으로 모니터링하고 필요에 따라 리소스 조정, 쿼리 최적화 또는 데이터베이스 구성 조정과 같은 조정을 수행합니다.
+ **데이터베이스 관리 자동화: **Aurora Autoscaling, Aurora용 성능 개선 도우미 및 AWS Database Migration Service와 같은 AWS 서비스를 활용하여 데이터베이스 관리 작업을 자동화하고 운영 오버헤드를 줄입니다.
+ **재해 복구 및 백업 전략 구현: **Aurora 자동 백업, point-in-time 복구, 교차 리전 복제본 구성과 같은 기능을 활용하여 잘 정의된 백업 및 복구 계획이 있는지 확인합니다.
+ ** AWS 모범 사례 및 설명서 준수: **선택한 데이터 서비스에 대한 최신 AWS 모범 사례, 지침 및 설명서를 up-to-date 데이터 모델 및 구현이 AWS 권장 사항에 부합하는지 확인합니다.

각 AWS 데이터 서비스의 자세한 지침은 다음 주제를 참조하세요.
+ [Amazon Aurora의 모범 사례](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.BestPractices.html)
+ [Amazon Aurora MySQL의 모범 사례](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.BestPractices.html)
+ [Amazon Redshift 쿼리 성능 튜닝](https://docs.aws.amazon.com/redshift/latest/dg/c-optimizing-query-performance.html)
+ [Amazon DynamoDB에서 데이터 쿼리 및 스캔 모범 사례](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-query-scan.html)

# App Studio 앱에서 개체 생성
<a name="data-entities-create"></a>

App Studio 앱에서 개체를 생성하는 방법에는 네 가지가 있습니다. 다음 목록에는 각 메서드, 그 이점, 해당 메서드를 사용하여 개체를 생성 및 구성하기 위한 지침 링크가 포함되어 있습니다.
+ [기존 데이터 소스에서 개체 생성](#data-entities-create-existing-data-source): 기존 데이터 소스 테이블에서 개체와 해당 필드를 자동으로 생성하고 필드를 데이터 소스 테이블 열에 매핑합니다. App Studio 앱에서 사용하려는 기존 데이터 소스가 있는 경우이 옵션을 사용하는 것이 좋습니다.
+ [App Studio 관리형 데이터 소스를 사용하여 엔터티 생성](#data-entities-create-managed-data-source): App Studio가 관리하는 엔터티와 DynamoDB 테이블을 생성합니다. 개체를 업데이트하면 DynamoDB 테이블이 자동으로 업데이트됩니다. 이 옵션을 사용하면 타사 데이터 소스를 수동으로 생성, 관리 또는 연결하거나 엔터티 필드에서 테이블 열로의 매핑을 지정할 필요가 없습니다. 앱의 모든 데이터 모델링 및 구성은 App Studio에서 수행됩니다. 이 옵션은 자체 데이터 소스와 DynamoDB 테이블을 관리하지 않으려는 경우에 선호되며, 해당 기능으로 앱에 충분합니다.
+ [빈 개체 생성](#data-entities-create-empty): 완전히 처음부터 빈 개체를 생성합니다. 관리자가 생성한 기존 데이터 소스 또는 커넥터가 없고 외부 데이터 소스의 제약 없이 앱의 데이터 모델을 유연하게 설계하려는 경우이 옵션을 사용하는 것이 좋습니다. 생성 후 개체를 데이터 소스에 연결할 수 있습니다.
+ [AI를 사용하여 개체 생성](#data-entities-create-with-ai): 지정된 개체 이름을 기반으로 개체, 필드, 데이터 작업 및 샘플 데이터를 생성합니다. 앱의 데이터 모델을 알고 있지만 엔터티로 변환하는 데 도움이 필요한 경우이 옵션을 사용하는 것이 좋습니다.

## 기존 데이터 소스에서 개체 생성
<a name="data-entities-create-existing-data-source"></a>

데이터 소스의 테이블을 사용하여 엔터티와 해당 필드를 자동으로 생성하고 엔터티 필드를 테이블의 열에 매핑합니다. App Studio 앱에서 사용하려는 기존 데이터 소스가 있는 경우이 옵션을 사용하는 것이 좋습니다.

1. 필요한 경우 애플리케이션으로 이동합니다.

1. 캔버스 상단의 **데이터** 탭을 선택합니다.

1. 앱에 개체가 없는 경우 **\$1 개체 생성을** 선택합니다. 그렇지 않으면 왼쪽 **엔터티** 메뉴에서 **\$1 추가**를 선택합니다.

1. **기존 데이터 소스에서 테이블 사용을** 선택합니다.

1. **커넥터**에서 개체를 생성하는 데 사용할 테이블이 포함된 커넥터를 선택합니다.

1. **테이블**에서 개체를 생성하는 데 사용할 테이블을 선택합니다.

1. **데이터 작업 생성** 확인란을 선택하여 데이터 작업을 생성합니다.

1. **개체 생성을** 선택합니다. 이제 개체가 생성되고 왼쪽 개체 패널에서 해당 **개체를** 볼 수 있습니다.

1. 의 절차에 따라 새 개체를 구성합니다[App Studio 앱에서 개체 구성 또는 편집](data-entities-edit.md). 개체가 기존 데이터 소스로 생성되었으므로 필드, 연결된 데이터 소스 및 필드 매핑과 같은 일부 속성 또는 리소스가 이미 생성되었습니다. 또한 생성 중에 데이터 작업 **생성 확인란을 선택한 경우 엔터티에 데이터 작업이** 포함됩니다.

## App Studio 관리형 데이터 소스를 사용하여 엔터티 생성
<a name="data-entities-create-managed-data-source"></a>

App Studio에서 관리하는 관리형 엔터티와 해당 DynamoDB 테이블을 생성합니다. 연결된 AWS 계정에 DynamoDB 테이블이 있는 동안 App Studio 앱의 개체가 변경되면 DynamoDB 테이블이 자동으로 업데이트됩니다. 이 옵션을 사용하면 타사 데이터 소스를 수동으로 생성, 관리 또는 연결하거나 엔터티 필드에서 테이블 열로의 매핑을 지정할 필요가 없습니다. 이 옵션은 자체 데이터 소스와 DynamoDB 테이블을 관리하지 않으려는 경우에 선호되며, 해당 기능으로 앱에 충분합니다. 관리형 엔터티에 대한 자세한 내용은 섹션을 참조하세요[AWS App Studio의 관리형 데이터 엔터티](managed-data-entities.md).

여러 애플리케이션에서 동일한 관리형 엔터티를 사용할 수 있습니다. 지침은 [기존 데이터 소스에서 개체 생성](#data-entities-create-existing-data-source) 섹션을 참조하세요.

1. 필요한 경우 애플리케이션으로 이동합니다.

1. 캔버스 상단에서 **데이터** 탭을 선택합니다.

1. 앱에 개체가 없는 경우 **\$1 개체 생성을** 선택합니다. 그렇지 않으면 왼쪽 **엔터티** 메뉴에서 **\$1 추가**를 선택합니다.

1. **App Studio 관리형 엔터티 생성을** 선택합니다.

1. **엔터티 이름**에 엔터티의 이름을 입력합니다.

1. **프라이머리 키**에서 엔터티의 프라이머리 키 이름을 입력합니다. 기본 키는 엔터티의 고유 식별자이며 엔터티가 생성된 후에는 변경할 수 없습니다.

1. **프라이머리 키 데이터 유형**에서 개체의 프라이머리 키 데이터 유형을 선택합니다. 개체가 생성된 후에는 데이터 유형을 변경할 수 없습니다.

1. **개체 생성을** 선택합니다. 이제 개체가 생성되고 왼쪽 개체 패널에서 해당 **개체를** 볼 수 있습니다.

1. 의 절차에 따라 새 개체를 구성합니다[App Studio 앱에서 개체 구성 또는 편집](data-entities-edit.md). 개체가 관리형 데이터로 생성되었으므로 기본 키 필드 및 연결된 데이터 소스와 같은 일부 속성 또는 리소스가 이미 생성되었습니다.

## 빈 개체 생성
<a name="data-entities-create-empty"></a>

완전히 처음부터 빈 개체를 생성합니다. 관리자가 생성한 기존 데이터 소스 또는 커넥터가 없는 경우이 옵션을 사용하는 것이 좋습니다. 외부 데이터 소스의 제약 없이 App Studio 앱 내에서 개체를 설계할 수 있으므로 빈 개체를 생성하면 유연성이 제공됩니다. 앱의 데이터 모델을 설계하고 그에 따라 개체를 구성한 후에도 나중에 외부 데이터 소스에 연결할 수 있습니다.

1. 필요한 경우 애플리케이션으로 이동합니다.

1. 캔버스 상단에서 **데이터** 탭을 선택합니다.

1. 앱에 개체가 없는 경우 **\$1 개체 생성을** 선택합니다. 그렇지 않으면 왼쪽 **엔터티** 메뉴에서 **\$1 추가**를 선택합니다.

1. **개체 생성을** 선택합니다.

1. **개체 생성을** 선택합니다. 이제 개체가 생성되고 왼쪽 개체 패널에서 해당 **개체를** 볼 수 있습니다.

1. 의 절차에 따라 새 개체를 구성합니다[App Studio 앱에서 개체 구성 또는 편집](data-entities-edit.md).

## AI를 사용하여 개체 생성
<a name="data-entities-create-with-ai"></a>

지정된 개체 이름을 기반으로 개체, 필드, 데이터 작업 및 샘플 데이터를 생성합니다. 앱의 데이터 모델을 알고 있지만 엔터티로 변환하는 데 도움이 필요한 경우이 옵션을 사용하는 것이 좋습니다.

1. 필요한 경우 애플리케이션으로 이동합니다.

1. 캔버스 상단에서 **데이터** 탭을 선택합니다.

1. 앱에 개체가 없는 경우 **\$1 개체 생성을** 선택합니다. 그렇지 않으면 왼쪽 **엔터티** 메뉴에서 **\$1 추가**를 선택합니다.

1. **AI를 사용하여 개체 생성을** 선택합니다.

1. **엔터티 이름**에 엔터티의 이름을 입력합니다. 이 이름은 개체의 필드, 데이터 작업 및 샘플 데이터를 생성하는 데 사용됩니다.

1. **데이터 작업 생성** 확인란을 선택하여 데이터 작업을 생성합니다.

1. **개체 생성을** 선택합니다. 이제 개체가 생성되고 왼쪽 개체 패널에서 해당 **개체를** 볼 수 있습니다.

1. 의 절차에 따라 새 개체를 구성합니다[App Studio 앱에서 개체 구성 또는 편집](data-entities-edit.md). 개체가 AI로 생성되었으므로 개체에 이미 생성된 필드가 포함됩니다. 또한 생성 중에 데이터 작업 **생성 확인란을 선택한 경우 엔터티에 데이터 작업이** 포함됩니다.

# App Studio 앱에서 개체 구성 또는 편집
<a name="data-entities-edit"></a>

다음 주제를 사용하여 App Studio 애플리케이션에서 개체를 구성합니다.

**Topics**
+ [개체 이름 편집](data-entities-edit-name.md)
+ [개체 필드 추가, 편집 또는 삭제](data-entities-edit-fields.md)
+ [데이터 작업 생성, 편집 또는 삭제](data-entities-edit-data-actions.md)
+ [샘플 데이터 추가 또는 삭제](data-entities-edit-sample-data.md)
+ [연결된 데이터 소스 및 맵 필드 추가 또는 편집](data-entities-edit-connection.md)

# 개체 이름 편집
<a name="data-entities-edit-name"></a>

1. 필요한 경우 편집하려는 엔터티로 이동합니다.

1. **구성** 탭의 **엔터티 이름**에서 엔터티 이름을 업데이트하고 텍스트 상자 외부를 선택하여 변경 사항을 저장합니다.

# 개체 필드 추가, 편집 또는 삭제
<a name="data-entities-edit-fields"></a>

**작은 정보**  
CTRL\$1Z를 눌러 개체에 대한 최신 변경 사항을 실행 취소할 수 있습니다.

1. 필요한 경우 편집하려는 엔터티로 이동합니다.

1. **구성** 탭의 **필드에서** 개체 필드 테이블을 볼 수 있습니다. 개체 필드에는 다음 열이 있습니다.
   + **표시 이름:** 표시 이름은 테이블 헤더 또는 양식 필드와 유사하며 애플리케이션 사용자가 볼 수 있습니다. 공백과 특수 문자를 포함할 수 있지만 개체 내에서 고유해야 합니다.
   + **시스템 이름:** 시스템 이름은 코드에서 필드를 참조하는 데 사용되는 고유 식별자입니다. Amazon Redshift 테이블의 열에 매핑할 때는 Amazon Redshift 테이블 열 이름과 일치해야 합니다.
   + **데이터 유형:** , `Integer` `Boolean`또는와 같이이 필드 내에 저장될 데이터의 유형입니다`String`.

1. 필드를 추가하려면:

   1. AI를 사용하여 엔터티 이름 및 연결된 데이터 소스를 기반으로 필드를 생성하려면 **추가 필드 생성을** 선택합니다.

   1. 단일 필드를 추가하려면 **\$1 필드 추가**를 선택합니다.

1. 필드를 편집하려면:

   1. 표시 이름을 편집하려면 **표시 이름** 텍스트 상자에 원하는 값을 입력합니다. 필드의 시스템 이름이 편집되지 않은 경우 표시 이름의 새 값으로 업데이트됩니다.

   1. 시스템 이름을 편집하려면 **시스템 이름** 텍스트 상자에 원하는 값을 입력합니다.

   1. 데이터 유형을 편집하려면 **데이터 유형** 드롭다운 메뉴를 선택하고 목록에서 원하는 유형을 선택합니다.

   1. 필드의 속성을 편집하려면 필드의 기어 아이콘을 선택합니다. 다음 목록은 필드 속성을 자세히 설명합니다.
      + **필수**: 데이터 소스에 필드가 필요한 경우이 옵션을 활성화합니다.
      + **프라이머리 키**: 필드가 데이터 소스의 프라이머리 키에 매핑된 경우이 옵션을 활성화합니다.
      + **고유**:이 필드의 값이 고유해야 하는 경우이 옵션을 활성화합니다.
      + **데이터 소스 기본값 사용**: 자동 증가 또는 이벤트 타임스탬프 사용과 같이 데이터 소스에서 필드 값을 제공하는 경우이 옵션을 활성화합니다.
      + **데이터 형식 옵션**: 특정 데이터 형식의 필드는 최소값 또는 최대값과 같은 데이터 형식 옵션으로 구성할 수 있습니다.

1. 필드를 삭제하려면 삭제하려는 필드의 휴지통 아이콘을 선택합니다.

# 데이터 작업 생성, 편집 또는 삭제
<a name="data-entities-edit-data-actions"></a>

데이터 작업은 애플리케이션에서 모든 레코드 가져오기 또는 ID로 레코드 가져오기와 같은 개체의 데이터에 대한 작업을 실행하는 데 사용됩니다. 데이터 작업은 테이블 또는 세부 정보 보기와 같은 구성 요소에서 볼 수 있도록 지정된 조건과 일치하는 데이터를 찾고 반환하는 데 사용할 수 있습니다.

**Contents**
+ [데이터 작업 생성](#data-entities-data-action-add)
+ [데이터 작업 편집 또는 구성](#data-entities-data-action-edit)
+ [데이터 작업 조건 연산자 및 예제](#data-entities-data-action-operators)
  + [데이터베이스의 조건 연산자 지원](#data-entities-data-action-operators-support)
  + [데이터 작업 조건 예제](#data-entities-data-action-operators-examples)
+ [데이터 작업 삭제](#data-entities-data-action-delete)

## 데이터 작업 생성
<a name="data-entities-data-action-add"></a>

**작은 정보**  
CTRL\$1Z를 눌러 엔터티에 대한 최신 변경 사항을 실행 취소할 수 있습니다.

1. 필요한 경우 데이터 작업을 생성하려는 엔터티로 이동합니다.

1. **데이터 작업** 탭을 선택합니다.

1. 데이터 작업을 생성하는 방법에는 두 가지가 있습니다.
   + (권장) AI를 사용하여 엔터티 이름, 필드 및 연결된 데이터 소스에 따라 데이터 작업을 생성하려면 **데이터 작업 생성을** 선택합니다. 다음 작업이 생성됩니다.

     1. `getAll`: 개체에서 모든 레코드를 검색합니다. 이 작업은 레코드 목록을 표시하거나 한 번에 여러 레코드에 대해 작업을 수행해야 하는 경우에 유용합니다.

     1. `getByID`: 고유 식별자(ID 또는 기본 키)를 기반으로 개체에서 단일 레코드를 검색합니다. 이 작업은 특정 레코드에 대한 작업을 표시하거나 수행해야 하는 경우에 유용합니다.
   + 단일 데이터 작업을 추가하려면 **\$1 데이터 작업 추가**를 선택합니다.

1. 새 데이터 작업을 보거나 구성하려면 단원을 참조하십시오[데이터 작업 편집 또는 구성](#data-entities-data-action-edit).

## 데이터 작업 편집 또는 구성
<a name="data-entities-data-action-edit"></a>

1. 필요한 경우 데이터 작업을 생성하려는 엔터티로 이동합니다.

1. **데이터 작업** 탭을 선택합니다.

1. **필드에서** 쿼리에서 반환할 필드를 구성합니다. 기본적으로 개체에 구성된 모든 필드가 선택됩니다.

   다음 단계를 수행하여 데이터 작업에 **조인**을 추가할 수도 있습니다.

   1. ** \$1 조인 추가**를 선택하여 대화 상자를 엽니다.

   1. **관련 엔**터티에서 현재 엔터티와 조인할 엔터티를 선택합니다.

   1. **별칭**에 선택적으로 관련 엔터티의 임시 별칭 이름을 입력합니다.

   1. **조인 유형**에서 원하는 조인 유형을 선택합니다.

   1. 각 개체의 필드를 선택하여 조인 절을 정의합니다.

   1. **추가**를 선택하여 조인을 생성합니다.

   일단 생성되면 조인이 **조인** 섹션에 표시되므로 **반환할 필드** 드롭다운에서 추가 필드를 사용할 수 있습니다. 엔터티 간에 연결된 조인을 포함하여 여러 조인을 추가할 수 있습니다. 조인된 엔터티의 필드를 기준으로 필터링하고 정렬할 수도 있습니다.

   조인을 삭제하려면 조인 옆에 있는 휴지통 아이콘을 선택합니다. 그러면 해당 필드를 사용하여 해당 조인에서 모든 필드가 제거되고 종속 조인 또는 제약 조건이 해제됩니다.

1. **조건에서** 쿼리의 출력을 필터링하는 규칙을 추가, 편집 또는 제거합니다. 규칙을 그룹으로 구성하고 여러 규칙을 `AND` 또는 `OR` 문과 함께 연결할 수 있습니다. 사용할 수 있는 연산자에 대한 자세한 내용은 섹션을 참조하세요[데이터 작업 조건 연산자 및 예제](#data-entities-data-action-operators).

1. **정렬**에서 속성을 선택하고 오름차순 또는 내림차순을 선택하여 쿼리 결과를 정렬하는 방법을 구성합니다. 정렬 규칙 옆에 있는 휴지통 아이콘을 선택하여 정렬 구성을 제거할 수 있습니다.

1. **결과 변환**에서 사용자 지정 JavaScript를 입력하여 결과를 표시하거나 자동화로 전송하기 전에 수정하거나 형식을 지정할 수 있습니다.

1. **출력 미리** 보기에서 구성된 필드, 필터, 정렬 및 JavaScript를 기반으로 쿼리 출력의 미리 보기 테이블을 봅니다.

## 데이터 작업 조건 연산자 및 예제
<a name="data-entities-data-action-operators"></a>

조건 연산자를 사용하여 구성된 표현식 값을 개체 열과 비교하여 데이터베이스 객체의 하위 집합을 반환할 수 있습니다. 사용할 수 있는 연산자는 열의 데이터 유형과 Amazon Redshift, Amazon Aurora 또는 Amazon DynamoDB와 같이 개체가 연결된 데이터베이스 유형에 따라 달라집니다.

모든 데이터베이스 서비스에서 다음 조건 연산자를 사용할 수 있습니다.
+ `=` 및 `!=`: 모든 데이터 유형에 사용할 수 있습니다(기본 키 열 제외).
+ `<=`, `>=``<`, 및 `>=`: 숫자 열에만 사용할 수 있습니다.
+ `IS NULL` 및 `IS NOT NULL`: null이거나 빈 값이 있는 열을 일치시키는 데 사용됩니다. Null 값은 종종 각 데이터베이스에서 다르게 해석되지만 App Studio에서는 `NULL` 연산자가 연결된 데이터베이스 테이블에 null 값이 있는 레코드를 일치시키고 반환합니다.

다음 조건 연산자는 이를 지원하는 데이터베이스 서비스에 연결된 엔터티에서만 사용할 수 있습니다.
+ `LIKE` 및 `NOT LIKE`(Redshift, Aurora): 연결된 데이터베이스에서 패턴 기반 쿼리를 수행하는 데 사용됩니다. 연`LIKE`산자는 지정된 패턴에 맞는 레코드를 찾아 반환하므로 검색 기능에 유연성을 제공합니다. 패턴 내의 문자 또는 문자 시퀀스와 일치하는 와일드카드 문자를 사용하여 패턴을 정의합니다. 각 데이터베이스 관리 시스템에는 고유한 와일드카드 문자 집합이 있지만 가장 많이 사용되는 두 가지는 원하는 수의 문자(0 포함)`_`를 `%` 나타내고 단일 문자를 나타내는 것입니다.
+ `Contains` 및 `Not Contains` (DynamoDB): 대/소문자를 구분하는 검색을 수행하여 열 값 내에서 지정된 텍스트를 찾을 수 있는지 확인하는 데 사용됩니다.
+ `Starts With` 및 `Not Starts With` (DynamoDB): 대/소문자를 구분하여 검색을 수행하여 지정된 텍스트가 열 값의 시작 부분에 있는지 확인하는 데 사용됩니다.

### 데이터베이스의 조건 연산자 지원
<a name="data-entities-data-action-operators-support"></a>

다음 표에는 App Studio에 연결할 수 있는 각 데이터베이스에서 지원되는 데이터 작업 조건 연산자가 나와 있습니다.


|  | =, \$1=, <, >, <=, >= | LIKE, NOT LIKE | 포함, 포함되지 않음 | 로 시작하고 로 시작하지 않음 | IS NULL, IS NOT NULL | 
| --- | --- | --- | --- | --- | --- | 
|  **DynamoDB**  |  예  |  아니요  |  예  |  예  |  예  | 
|  **Aurora**  |  예  |  예  |  아니요  |  아니요  |  예  | 
|  **Redshift**  |  예  |  예  |  아니요  |  아니요  |  예  | 

### 데이터 작업 조건 예제
<a name="data-entities-data-action-operators-examples"></a>

, `name` `city`및 `hireDate` 필드가 있는 여러 항목이 포함된 다음 데이터베이스 테이블을 고려하세요.


| 이름 | city | hireDate | 
| --- | --- | --- | 
|  Adam  |  시애틀  |  2025-03-01  | 
|  아드리엔  |  보스턴  |  2025-03-05  | 
|  Bob  |  앨버커키  |  2025-03-06  | 
|  Carlos  |  시카고  |  2025-03-10  | 
|  캐롤라인  |  NULL  |  2025-03-12  | 
|  리타  |  Miami  |  2025-03-15  | 

이제 App Studio에서 지정된 조건과 일치하는 항목의 `name` 필드를 반환하는 데이터 작업을 생성하는 것이 좋습니다. 다음 목록에는 조건 예제와 테이블이 각각에 대해 반환하는 값이 포함되어 있습니다.

**참고**  
예제는 SQL 예제로 형식이 지정됩니다. App Studio에서처럼 표시되지 않을 수 있지만 연산자의 동작을 설명하는 데 사용됩니다.
+ `WHERE name LIKE 'Adam'`:를 반환합니다`Adam`.
+ `WHERE name LIKE 'A%'`: `Adam` 및를 반환합니다`Adrienne`.
+ `WHERE name NOT LIKE 'B_B'`: `Adam`, `Adrienne`, `Carlos`, 및 `Caroline`를 반환합니다`Rita`.
+ `WHERE contains(name, 'ita')`:를 반환합니다`Rita`.
+ `WHERE begins_with(name, 'Car')`: `Carlos` 및를 반환합니다`Caroline`.
+ `WHERE city IS NULL`:를 반환합니다`Caroline`.
+ `WHERE hireDate < "2025-03-06"`: `Adam` 및를 반환합니다`Adrienne`.
+ `WHERE hireDate >= DateTime.now().toISODate()`:는 현재 날짜를 `DateTime.now().toISODate()` 반환합니다. 현재 날짜가 2025-03-10인 시나리오에서 표현식은 , `Caroline`및 `Carlos`를 반환합니다`Rita`.

**작은 정보**  
표현식의 날짜 및 시간 비교에 대한 자세한 내용은 섹션을 참조하세요[날짜 및 시간](expressions.md#expressions-date-time).

## 데이터 작업 삭제
<a name="data-entities-data-action-delete"></a>

다음 절차에 따라 App Studio 엔터티에서 데이터 작업을 삭제합니다.

1. 필요한 경우 데이터 작업을 삭제할 엔터티로 이동합니다.

1. **데이터 작업** 탭을 선택합니다.

1. 삭제하려는 각 데이터 작업에 대해 **편집** 옆의 드롭다운 메뉴를 선택하고 **삭제**를 선택합니다.

1. 대화 상자에서 **확인을** 선택합니다.

# 샘플 데이터 추가 또는 삭제
<a name="data-entities-edit-sample-data"></a>

App Studio 애플리케이션의 개체에 샘플 데이터를 추가할 수 있습니다. 애플리케이션은 게시될 때까지 외부 서비스와 통신하지 않으므로 샘플 데이터를 사용하여 미리 보기 환경에서 애플리케이션 및 엔터티를 테스트할 수 있습니다.

1. 필요한 경우 편집하려는 엔터티로 이동합니다.

1. **샘플 데이터** 탭을 선택합니다.

1. 샘플 데이터를 생성하려면 더 **많은 샘플 데이터 생성을** 선택합니다.

1. 샘플 데이터를 삭제하려면 삭제하려는 데이터의 확인란을 선택하고 삭제 또는 백스페이스 키를 누릅니다. **저장**을 선택하여 변경 사항을 저장합니다.

# 연결된 데이터 소스 및 맵 필드 추가 또는 편집
<a name="data-entities-edit-connection"></a>

**작은 정보**  
CTRL\$1Z를 눌러 개체에 대한 최신 변경 사항을 실행 취소할 수 있습니다.

1. 필요한 경우 편집하려는 엔터티로 이동합니다.

1. **연결** 탭을 선택하여 애플리케이션이 게시될 때 데이터가 저장되는 데이터 소스 테이블과 개체 간의 연결을 보거나 관리합니다. 데이터 소스 테이블이 연결되면 개체 필드를 테이블의 열에 매핑할 수 있습니다.

1. **커넥터**에서 원하는 데이터 소스 테이블에 대한 연결이 포함된 커넥터를 선택합니다. 커넥터에 대한 자세한 내용은 단원을 참조하십시오[커넥터를 사용하여 App Studio를 다른 서비스에 연결](connectors.md).

1. **테이블**에서 개체의 데이터 소스로 사용할 테이블을 선택합니다.

1. 이 표에는 개체의 필드와 개체가 매핑된 데이터 소스 열이 나와 있습니다. **자동 매핑**을 선택하여 엔터티 필드를 데이터 소스 열에 자동으로 매핑합니다. 각 개체 필드의 드롭다운에서 데이터 소스 열을 선택하여 테이블의 필드를 수동으로 매핑할 수도 있습니다.

# 개체 삭제
<a name="data-entities-delete"></a>

다음 절차에 따라 App Studio 애플리케이션에서 개체를 삭제합니다.

**참고**  
App Studio 앱에서 엔터티를 삭제해도 관리형 엔터티의 해당 DynamoDB 테이블을 포함하여 연결된 데이터 소스 테이블은 삭제되지 않습니다. 데이터 소스 테이블은 연결된 AWS 계정에 남아 있으며 원하는 경우 해당 서비스에서 삭제해야 합니다.

**개체를 삭제하려면**

1. 필요한 경우 애플리케이션으로 이동합니다.

1. **데이터** 탭을 선택합니다.

1. 왼쪽 **엔터티** 메뉴에서 삭제하려는 엔터티 옆에 있는 줄임표 메뉴를 선택하고 **삭제**를 선택합니다.

1. 대화 상자의 정보를 검토하고를 **confirm** 입력한 다음 **삭제**를 선택하여 개체를 삭제합니다.

# AWS App Studio의 관리형 데이터 엔터티
<a name="managed-data-entities"></a>

일반적으로 외부 데이터베이스 테이블에 연결하여 App Studio에서 엔터티를 구성하며, 연결된 데이터베이스 테이블의 열을 사용하여 각 엔터티 필드를 생성하고 매핑해야 합니다. 데이터 모델을 변경할 때 외부 데이터베이스 테이블과 개체를 모두 업데이트하고 변경된 필드를 다시 매핑해야 합니다. 이 방법은 유연하고 다양한 유형의 데이터 소스를 사용할 수 있지만 더 많은 사전 계획과 지속적인 유지 관리가 필요합니다.

*관리형 엔터*티는 App Studio가 전체 데이터 스토리지 및 구성 프로세스를 관리하는 엔터티 유형입니다. 관리형 엔터티를 생성하면 연결된 AWS 계정에 해당 DynamoDB 테이블이 생성됩니다. 이를 통해 내에서 안전하고 투명한 데이터 관리를 보장할 수 있습니다 AWS. 관리형 엔터티를 사용하면 App Studio에서 엔터티의 스키마를 구성하고 해당 DynamoDB 테이블도 자동으로 업데이트됩니다.

## 여러 애플리케이션에서 관리형 엔터티 사용
<a name="managed-data-entities-other-applications"></a>

App Studio 앱에서 관리형 엔터티를 생성하면 해당 엔터티를 다른 App Studio 앱에서 사용할 수 있습니다. 이는 유지할 단일 기본 리소스를 제공하여 동일한 데이터 모델 및 스키마가 있는 앱에 대한 데이터 스토리지를 구성하는 데 유용합니다.

여러 애플리케이션에서 관리형 엔터티를 사용하는 경우 해당 DynamoDB 테이블에 대한 모든 스키마 업데이트는 관리형 엔터티가 생성된 원래 애플리케이션을 사용하여 이루어져야 합니다. 다른 애플리케이션의 엔터티에 대한 스키마 변경 사항은 해당 DynamoDB 테이블을 업데이트하지 않습니다.

## 관리형 엔터티 제한 사항
<a name="managed-data-entities-limitations"></a>

**기본 키 업데이트 제한**: 엔터티가 생성된 후에는 엔터티의 기본 키 이름 또는 유형을 변경할 수 없습니다. 이는 DynamoDB의 파괴적인 변경이며 기존 데이터가 손실될 수 있기 때문입니다.

**열 이름 바꾸기**: DynamoDB에서 열 이름을 바꾸면 원래 열이 원래 데이터와 함께 유지되는 동안 실제로 새 열을 생성합니다. 원본 데이터는 새 열에 자동으로 복사되거나 원본 열에서 삭제되지 않습니다. *시스템* 이름이라고 하는 관리형 엔터티 필드의 이름을 바꿀 수 있지만 원래 열과 해당 데이터에 대한 액세스 권한은 상실됩니다. 표시 이름 변경에는 제한이 없습니다.

**데이터 유형 변경**: DynamoDB는 테이블 생성 후 열 데이터 유형을 유연하게 수정할 수 있지만 이러한 변경은 쿼리 로직 및 정확도뿐만 아니라 기존 데이터에 심각한 영향을 미칠 수 있습니다. 데이터 형식을 변경하려면 모든 기존 데이터를 새 형식에 맞게 변환해야 합니다.이 형식은 대규모 활성 테이블에서 복잡합니다. 또한 데이터 마이그레이션이 완료될 때까지 데이터 작업은 예상치 못한 결과를 반환할 수 있습니다. 필드의 데이터 유형을 전환할 수 있지만 기존 데이터는 새 데이터 유형으로 마이그레이션되지 않습니다.

**정렬 열**: DynamoDB는 정렬 키를 통해 정렬된 데이터 검색을 활성화합니다. 정렬 키는 파티션 키와 함께 복합 기본 키의 일부로 정의되어야 합니다. 제한 사항에는 필수 정렬 키, 한 파티션 내에서 제한된 정렬, 파티션 간 전역 정렬이 포함되지 않습니다. 핫 파티션을 방지하려면 정렬 키의 신중한 데이터 모델링이 필요합니다. 미리 보기 마일스톤에 대한 정렬은 지원되지 않습니다.

**조인**: DynamoDB에서는 조인이 지원되지 않습니다. 테이블은 비용이 많이 드는 조인 작업을 방지하기 위해 설계에 따라 비정규화됩니다. one-to-many 관계를 모델링하기 위해 하위 테이블에는 상위 테이블의 기본 키를 참조하는 속성이 포함되어 있습니다. 다중 테이블 데이터 쿼리에는 세부 정보를 검색하기 위해 상위 테이블에서 항목을 검색하는 작업이 포함됩니다. 미리 보기 마일스톤의 일부로 관리형 엔터티에 대한 기본 조인을 지원하지 않습니다. 해결 방법으로 두 개체의 데이터 병합을 수행할 수 있는 자동화 단계를 소개합니다. 이는 한 수준 조회와 매우 유사합니다. 미리 보기 마일스톤에 대한 정렬은 지원되지 않습니다.

**Env 단계**: 게시가 테스트하도록 허용하지만 두 환경 모두에서 동일한 관리형 스토어를 사용합니다.