Core Data Developer(s) Apple Inc. Stable release 3.2.0 Operating system Mac OS X Type System Utility License Proprietary Website Apple Developer Data ManagementIn simplest terms, Core Data is an object graph that can be persisted to Disk. [...] Core Data can do a lot more for us. It serves as the entire model layer for us. It is not just the persistence on disk, but it is also all the objects in memory that we normally consider to be data objects.—Marcus Zarra, Core Data
Core Data is part of the Cocoa API in Mac OS X first introduced with Mac OS X 10.4 Tiger and for iOS with iPhone SDK 3.0. It allows data organised by the relational entity-attribute model to be serialised into XML, binary, or SQLite stores. The data can be manipulated using higher level objects representing entities and their relationships. Core Data manages the serialised version, providing object lifecycle and object graph management, including persistence. Core Data interfaces directly with SQLite, insulating the developer from the underlying SQL.
Just as Cocoa Bindings handles many of the duties of the Controller in a Model-View-Controller design, Core Data handles many of the duties of the data Model. Among other tasks, it handles change management, serializing to disk, memory footprint minimization, and queries against the data.
Core Data describes data with a high level data model expressed in terms of entities and their relationships plus fetch requests that retrieve entities meeting specific criteria. Code can retrieve and manipulate this data on a purely object level without having to worry about the details of storage and retrieval. The controller objects available in Interface Builder can retrieve and manipulate these entities directly. When combined with Cocoa bindings the UI can display many components of the data model without needing background code.
For example: a developer might be writing a program to handle vCards. In order to manage these, the author intends to read the vCards into objects, and then store them in a single larger XML file. Using Core Data the developer would drag their schema from the data designer in Xcode into an interface builder window to create a GUI for their schema. They could then write standard Objective-C code to read vCard files and put the data into Core Data managed entities. From that point on the author's code manipulates these Core Data objects, rather than the underlying vCards. Connecting the
Savemenu item to the appropriate method in the controller object will direct the controller to examine the object stack, determine which objects are dirty, and then re-write a Core Data document file with these changes.
Core Data is organized into a large hierarchy of classes, though interaction is only prevalent with a small set of them.
Name Use Key Methods NSManagedObject
- Access attributes
- A "row" of data
- -setValue: forKey:
- -executeFetchRequest: error:
- -setFetchRequestTemplate: forName:
- Request data
- Persisting the data
- -addPersistentStoreWithType: configuration: URL: options: error:
- Specify query
Core Data can serialize objects into XML, Binary, or SQLite for storage. With the release of Mac OS X 10.5 Leopard, developers can also create their own custom atomic store types. Each method carries advantages and disadvantages, such as being human readable (XML) or more memory efficient (SQLite). This portion of Core Data is similar to the original Enterprise Objects Framework (EOF) system, in that one can write fairly sophisticated queries. Unlike EOF, it is not possible to write your own SQL.
Core Data schemas are standarized. If you have the Xcode Data Model file, you can read and write files in that format freely. Unlike EOF, though, Core Data is not currently designed for multiuser or simultaneous access. Schema migration is also non-trivial, virtually always requiring code. If other developers have access to and depend upon your data model, you may need to provide version translation code in addition to a new data model if your schema changes.
History and genesis
EOF was specifically aimed at object-relational mapping for high-end SQL database engines such as Microsoft SQL Server and Oracle. EOF's purpose was twofold, one to connect to the database engine and hide the implementation details, and two to read the data out of the simple relational format and translate that into a set of objects. Developers typically interacted with the objects only, dramatically simplifying development of complex programs for the cost of some "setup". The EOF object model was deliberately set up to make the resulting programs "document like", in that the user could edit the data locally in memory, and then write out all changes with a single Save command.
Throughout its history EOF "contained" a number of bits of extremely useful code that were not otherwise available under NeXTSTEP/OpenStep. For instance, EOF required the ability to track which objects were "dirty" so the system could later write them out, and this was presented to the developer not only as a document-like system, but also in the form of an unlimited Undo command stack. Many developers complained that this state management code was far too useful to be isolated in EOF, and it was moved into the Cocoa API during the transition to Mac OS X.
Oddly what was not translated was EOF itself. EOF was used primarily along with another OpenStep-era product, WebObjects, an application server originally based on Objective-C that was in the process of being ported to the Java programming language. As part of this conversion EOF was also converted to Java, and thus became much more difficult to use from Cocoa. Enough developers complained about this that Apple apparently decided to do something about it.
One critical realization is that the object state management system in EOF did not really have anything to do with relational databases. The same code could be, and was, used by developers to manage graphs of other objects as well. In this role the really useful parts of EOF were those that automatically built the object sets from the raw data, and then tracked them. It is this concept, and perhaps code, that forms the basis of Core Data.
- Apple Inc. (2009, 17 September). "Core Data Programming Guide". Retrieved from http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/CoreData/cdProgrammingGuide.html
- Apple Inc. (2009, 09 September). "Core Data Tutorial for iPhone OS". Retrieved from http://developer.apple.com/iphone/library/documentation/DataManagement/Conceptual/iPhoneCoreData01/Introduction/Introduction.html
- Apple Inc. (2006). "EOModeler User Guide". Retrieved from http://developer.apple.com/legacy/mac/library/documentation/WebObjects/UsingEOModeler/Introduction/Introduction.html#//apple_ref/doc/uid/TP30001018-CH201-TP1
- Jurewitz, M. & Apple Inc. (2010). "iPhone Development Videos: Working With Core Data". Retrieved from http://developer.apple.com/videos/iphone/#video-advanced-coredata
- Stevenson, S. (2005). "Core Data Class Overview". Retrieved from http://cocoadevcentral.com/articles/000086.php
- Zarra, M. S. (2009). Core Data Apple's API for Persisting Data on Mac OS X. The Pragmatic Programmers.
- LaMarche, J., & Mark, D. (2009). More iPhone 3 Development: Tackling iPhone SDK 3. Apress.
- Apple Inc. (2006). "Developing With Core Data". Retrieved from http://developer.apple.com/macosx/coredata.html
- Apple Inc. (2009). "Web Objects Tutorial". Retrieved from http://developer.apple.com/legacy/mac/library/documentation/DeveloperTools/Conceptual/WOTutorial/Introduction/Introduction.html
- CocoaDev. (n.d.). Retrieved from http://www.cocoadev.com/
- Stevenson, S. (2005). "Build A Core Data Application". Retrieved from http://cocoadevcentral.com/articles/000085.php
Mac OS X Core Foundation
Wikimedia Foundation. 2010.
Look at other dictionaries:
Core data — Information held in the system data base which controls how the automated system works. This is a term used by technical systems staff to describe the table information of an automated system. Basically these tables allow you to enter standard… … International financial encyclopaedia
Core data integration — is the use of data integration technology for a significant, centrally planned and managed IT initiative within a company. Examples of core data integration initiatives could include: ETL (Extract, transform, load) implementations EAI (Enterprise … Wikipedia
Core Foundation — (also called CF) is a C application programming interface (API) in Mac OS X iOS, and is a mix of low level routines and wrapper functions. Apple releases most of it as an open source project called CFLite that can be used to write cross platform… … Wikipedia
Core Animation — (Графическая модель Mac OS X) Тип System Utility Разработчик Apple Inc. Операционная система Mac OS X Лицензия Проприетарн … Википедия
Core Audio — Developer(s) Apple Inc. Stable release 3.2.6 Operating system Mac OS X, iOS … Wikipedia
Core Text — is a Core Foundation style API in Mac OS X, first introduced in Mac OS X 10.4 Tiger, made public in Mac OS X 10.5 Leopard, and introduced for the iPad with iPhone SDK 3.2. Exposing a C API, it replaces the text rendering abilities of the now… … Wikipedia
Core Services — are a set of Mac OS X and iOS application programming interfaces that architecturally are underneath Carbon, Cocoa and Cocoa Touch. In addition to Core Foundation, it also encompasses other APIs including Grand Central Dispatch, Blocks,… … Wikipedia
Data integration — involves combining data residing in different sources and providing users with a unified view of these data. This process becomes significant in a variety of situations, which include both commercial (when two similar companies need to merge… … Wikipedia
Core Image — Mac OS X graphics model Rendering QuickDraw • Core OpenGL Quartz 2D • Core Image Core Animation • … Wikipedia
Core Video — Mac OS X graphics model Rendering QuickDraw • Core OpenGL Quartz 2D • Core Image Core Animation • Core Video ColorSync … Wikipedia