코어 데이터

website = Apple 개발자 Core Data 프로그래밍 가이드 **코어 데이터**(Core Data)는 애플이 macOS 및 iOS 운영체제에서 제공하는 객체 그래프 및 지속성 프레임워크이다. Mac OS X 10.4 타이거와 iOS에서 아이폰 SDK 3.0과 함께 도입되었다.Apple, "Core Data Tutorial for iPhone OS". 관계형 엔티티-속성 모델로 구성된 데이터를 직렬화하여 XML, 이진 파일 또는 SQLite 저장소에 저장할 수 있다. 데이터는 엔티티와 그 관계를 나타내는 상위 수준 객체를 사용하여 조작할 수 있다. 코어 데이터는 직렬화된 버전을 관리하며, 객체 수명 주기 및 객체 그래프 관리(지속성 포함)를 제공한다. 코어 데이터는 SQLite와 직접 인터페이스하며, 개발자가 기본 SQL로부터 격리될 수 있도록 한다.Apple, "Core Data Programming Guide". 코코아 바인딩이 모델-뷰-컨트롤러 설계에서 컨트롤러의 많은 역할을 처리하는 것처럼, 코어 데이터는 데이터 모델의 많은 역할을 처리한다. 다른 작업 중에서도 변경 관리, 디스크에 직렬화, 메모리 사용량 최소화 및 데이터에 대한 쿼리를 처리한다.
# 사용법
코어 데이터는 엔티티와 그 관계, 그리고 특정 기준을 충족하는 엔티티를 검색하는 가져오기 요청 측면에서 표현되는 상위 수준 데이터 모델로 데이터를 설명한다. 코드는 저장 및 검색의 세부 사항에 대해 걱정할 필요 없이 순수 객체 수준에서 이 데이터를 검색하고 조작할 수 있다. 인터페이스 빌더에서 사용할 수 있는 컨트롤러 객체는 이러한 엔티티를 직접 검색하고 조작할 수 있다. 코코아 바인딩과 결합하면 UI는 백그라운드 코드가 필요 없이 데이터 모델의 많은 구성 요소를 표시할 수 있다. 예를 들어: 개발자가 VCard를 처리하는 프로그램을 작성하고 있을 수 있다. 이를 관리하기 위해, 작성자는 VCard를 객체로 읽어 들인 다음, 더 큰 단일 XML 파일에 저장할 계획이다. 코어 데이터를 사용하면 개발자는 엑스코드의 데이터 디자이너에서 데이터베이스 스키마를 인터페이스 빌더 창으로 끌어다 놓아 스키마에 대한 GUI를 만들 수 있다. 그런 다음 표준 오브젝티브-C 또는 스위프트 코드를 작성하여 VCard 파일을 읽고 데이터를 코어 데이터 관리 엔티티에 넣을 수 있다. 그 시점부터 작성자의 코드는 기본 VCard 대신 이러한 코어 데이터 객체를 조작한다. `저장` 메뉴 항목을 컨트롤러 객체의 적절한 메서드에 연결하면 컨트롤러는 객체 스택을 검사하고, 어떤 객체가 더티한지 확인한 다음, 이러한 변경 사항을 포함하여 코어 데이터 문서 파일을 다시 작성하도록 지시한다. 코어 데이터는 거대한 클래스 계층 구조로 구성되어 있지만, 실제 상호 작용은 그 중 작은 부분과만 주로 이루어진다. {| class="wikitable" |- ! 이름 !! 용도 !! 주요 메서드 |- | NSManagedObject | * 속성 접근 * 데이터의 "행" | * -entity * -valueForKey: * -setValue:forKey: |- | NSManagedObjectContext | * 동작 * 변경 사항 | * -executeFetchRequest:error: * -save |- | NSManagedObjectModel | * 구조 * 저장소 | * -entities * -fetchRequestTemplateForName: * -setFetchRequestTemplate: : forName: |- | NSFetchRequest | * 데이터 요청 | * -setEntity: * -setPredicate: * -setFetchBatchSize: |- | NSPersistentStoreCoordinator | * 중재자 * 데이터 지속화 | * -addPersistentStoreWithType: : configuration:URL: : options:error: * -persistentStoreForURL: |- | NSPredicate | * 쿼리 지정 | * +predicateWithFormat: * -evaluateWithObject: |} 출처:Zarra, Core Data.Stevenson, "Core Data Class Overview"Jurewitz, "Working With Core Data"
# 저장 형식
코어 데이터는 객체를 XML, 이진 또는 SQLite로 직렬화하여 저장할 수 있다. Mac OS X 10.5 레퍼드 출시와 함께 개발자는 자신만의 사용자 지정 아토믹 저장소 유형을 생성할 수도 있다. 각 방법은 사람이 읽을 수 있는 형식(XML) 또는 더 메모리 효율적인 형식(SQLite)과 같은 장단점을 가지고 있다. 코어 데이터의 이 부분은 원래의 엔터프라이즈 객체 프레임워크 (EOF) 시스템과 유사하며, 상당히 정교한 쿼리를 작성할 수 있다. EOF와 달리, 기본 저장소가 SQL 기반이 아닐 수 있으므로 자체 SQL을 작성하는 것은 불가능하다. 최근에는 ODBC 프레임워크에서 ODBC용 코어 데이터 저장소를 사용할 수 있게 되었다.Github, "Odbc framework" 코어 데이터 스키마는 표준화되어 있다. Xcode 데이터 모델 파일이 있다면 해당 형식의 파일을 자유롭게 읽고 쓸 수 있다. 그러나 EOF와 달리 코어 데이터는 ODBC 프레임워크를 사용하지 않는 한 다중 사용자 또는 동시 접근을 위해 설계되지 않았다.Github, "Odbc framework" 스키마 마이그레이션 또한 간단하지 않으며, 거의 항상 코드를 필요로 한다. 다른 개발자들이 데이터 모델에 접근하고 의존하는 경우, 스키마가 변경되면 새로운 데이터 모델 외에도 버전 변환 코드를 제공해야 할 수 있다.
# 역사와 기원
코어 데이터는 초기 NeXT 제품인 엔터프라이즈 객체 프레임워크 (EOF)의 디자인에 많은 영향을 받았다.Apple, "EOModeler User Guide" EOF는 마이크로소프트 SQL 서버 및 오라클과 같은 고급 SQL 데이터베이스 엔진을 위한 객체 관계형 매핑이었다. EOF의 목적은 두 가지였다. 첫째, 데이터베이스 엔진에 연결하고 구현 세부 사항을 숨기는 것. 둘째, 관계형 형식에서 데이터를 읽어 객체 집합으로 변환하는 것. 개발자들은 일반적으로 객체와만 상호 작용했으며, 이는 복잡한 프로그램 개발을 단순화했지만, 데이터를 객체에 매핑하는 일부 설정 비용이 들었다. EOF 객체 모델은 결과 프로그램이 문서와 유사한 방식으로 작동하도록 의도적으로 설계되었다. 사용자는 메모리에서 로컬로 데이터를 편집한 다음 단일 저장 명령으로 모든 변경 사항을 저장할 수 있었다. EOF는 역사 전반에 걸쳐 NeXTSTEP/오픈스텝에서 사용할 수 없었던 유용한 코드 조각들을 많이 포함하고 있었다. 예를 들어, EOF는 어떤 객체가 더티한지 추적하는 기능이 필요했는데, 이는 나중에 시스템이 이를 저장할 수 있도록 하기 위함이었다. 이것은 개발자에게 문서와 유사한 시스템으로 제공될 뿐만 아니라, 데이터에 적용된 각 명령이 실행 취소 가능한 작업으로 표현되는 무제한 실행 취소 명령 스택 형태로도 제공되었다. 많은 개발자들은 이 상태 관리 코드가 EOF에만 격리되기에는 너무 유용하다고 불평했고, 이는 나중에 맥 OS X로 전환하는 동안 코코아 API로 옮겨졌다. 처음에 번역되지 않은 것은 EOF 자체였다. EOF는 주로 또 다른 오픈스텝 시대 제품인 웹 애플리케이션 서버로, 원래 오브젝티브-C를 기반으로 했던 웹오브젝트와 함께 사용되었다. 당시 애플은 웹오브젝트를 자바 프로그래밍 언어로 포팅하는 과정에 있었고, 이 변환의 일부로 EOF는 코코아에서 사용하기가 훨씬 더 어려워졌다. 다시 한번, 서드파티 개발자들 사이에서 상당한 불만이 있었다. 중요한 깨달음 중 하나는 EOF의 객체 상태 관리 시스템이 관계형 데이터베이스와 실제로 아무 관련이 없었다는 것이다. 동일한 코드를 개발자들이 다른 객체들의 그래프를 관리하는 데 사용될 수 있었고 실제로 사용되었다. 이 역할에서 EOF의 정말 유용한 부분은 원시 데이터로부터 객체 집합을 자동으로 구축하고 추적하는 부분이었다. 코어 데이터의 기반을 형성하는 개념이 바로 이것이다.
# 내용주
2