Вступление
В первой статье этой серии мы узнали о стеке Core Data, сердце приложения Core Data. Мы изучили контекст управляемого объекта, координатора постоянного хранилища и модель управляемого объекта.
Эта статья посвящена модели данных приложения Core Data. Мы приближаемся к редактору моделей данных XCode и рассматриваем сущности, атрибуты и отношения.
Предпосылки
То, что я освещаю в этой серии о Core Data, применимо к iOS 7+ и OS X 10.10+, но основное внимание будет уделено iOS. В этой серии я буду работать с Xcode 7.1 и Swift 2.1. Если вы предпочитаете Objective-C, то я рекомендую прочитать мои предыдущие серии по платформе Core Data .
1. Редактор модели данных
Начните с загрузки проекта из предыдущего урока или клонируйте репозиторий из GitHub . Откройте проект в Xcode и в Project Navigator найдите Core_Data.xcdatamodeld . XCode автоматически показывает редактор модели данных, когда модель данных проекта выбрана.
2. Сущности
Прежде чем мы исследуем пользовательский интерфейс редактора, нам нужно создать объект для работы. В нижней части редактора модели данных нажмите кнопку Добавить объект . Это добавит объект с именем Entity . Он отобразится в разделе « Объекты » слева от редактора модели данных. Измените имя объекта на Человек , дважды щелкнув его в разделе сущностей .
«Что такое сущность?» Вы можете быть удивлены. Чтобы восстановить аналогию с базой данных, сущность сопоставима с таблицей в базе данных. Когда вы выбираете сущность Person , вы видите, что сущность может иметь атрибуты, отношения и извлеченные свойства. Пока не беспокойтесь о извлеченных свойствах, они — более продвинутая функция фреймворка.
3. Атрибуты
Присвойте сущности Person атрибут, нажав кнопку «плюс» в нижней части таблицы « Атрибуты» . Дважды щелкните имя атрибута и установите его первый В раскрывающемся меню « Тип» выберите « Строка» . Если мы сравним это с таблицей в базе данных, то Таблица Person теперь имеет первый столбец типа String .
Несмотря на то, что я не хочу вводить вас в заблуждение, сравнивая сущности с таблицами базы данных, это упрощает понимание сущностей и атрибутов. Фактически, если вы используете базу данных SQLite в качестве резервного хранилища вашего приложения, Core Data создаст таблицу для хранения данных сущности Person . Однако это то, о чем нам не нужно и не нужно беспокоиться. Помните, что Core Data не является базой данных.
То же самое касается отношений. Как базовые данные отслеживают отношения, нам не о чем беспокоиться. Фактически, Core Data гарантирует, что отношения загружаются только тогда, когда они нужны приложению. Это то, что мы вернемся позже в этой серии.
Добавьте еще два атрибута к сущности Person , последний тип String и возраст типа Integer 16 . Тип, который вы выбираете для чисел, на данном этапе не важен. Он сообщает Core Data, как он должен структурировать постоянное хранилище и оптимизировать его для производительности.
Параметры атрибута
Атрибут объекта можно настроить с помощью инспектора модели данных . Выберите первый атрибут объекта Person и откройте инспектор справа. Инспектор моделей данных позволяет настроить выбранный атрибут. На данный момент нас интересуют только несколько настроек: Необязательный , Тип атрибута и Значение по умолчанию .
Необязательный
Отметка атрибута как необязательного означает, что атрибут может быть пустым или оставить пустым для записи. Однако в нашем примере мы хотим убедиться, что каждая запись Person имеет имя. С первым выбранным атрибутом снимите флажок Необязательно, чтобы пометить его как необходимый. Новые атрибуты являются необязательными по умолчанию.
Маркировка атрибута как обязательного имеет последствия. Если мы сохраним запись Person без действительного имени, Core Data выдаст ошибку. Это означает, что мы должны убедиться, что первый атрибут записи установлен, прежде чем сохранить его.
Тип атрибута
Тип атрибута важен по нескольким причинам. Он сообщает Core Data в каком формате сохранить атрибут, а также возвращает нам данные атрибута в указанном формате. Каждый тип атрибута имеет свой набор параметров конфигурации. Измените тип атрибута первого атрибута на Date, чтобы увидеть параметры конфигурации для атрибута типа Date .
Значение по умолчанию
Несколько типов атрибутов, таких как String и Date , имеют поле Значение по умолчанию, которое вы можете установить. Это удобно, например, если требуется атрибут, и вы хотите убедиться, что атрибут для записи имеет действительное значение, когда он вставлен в базу данных.
Обратите внимание, что значение по умолчанию используется только при создании новой записи. Если существующая запись Person , например, обновлена, для первого атрибута установлено значение nil , то в Core Data первый атрибут не будет заполнен значением по умолчанию. Вместо этого Core data выдаст ошибку, потому что мы пометили первый атрибут как необходимый.
4. Отношения
Основные данные действительно сияют, когда вы начинаете работать с отношениями между сущностями. Давайте посмотрим, как это работает, добавив вторую сущность с именем Address . Сущность Address имеет четыре атрибута типа String , улица , номер , город и страна .
Отношения между сущностями имеют ряд определяющих характеристик, имя, место назначения, мощность отношения, обратное отношение и правило удаления отношения.
Давайте рассмотрим взаимосвязи более подробно, создав отношения между сущностями Person и Address .
Имя, место назначения и дополнительные возможности
Создайте отношение, выбрав сущность Person и нажав кнопку «плюс» в нижней части таблицы « Отношения» . Назовите отношения адрес и установите адресата к объекту адреса . Это указывает на то, что каждая запись о человеке может быть связана с записью адреса.
Как и с атрибутами, отношения по умолчанию являются необязательными. Это означает, что ошибка проверки не будет выдана, если запись о человеке не связана с записью адреса. Давайте изменим это, сняв флажок Optional в Инспекторе моделей данных справа.
Обратная зависимость
На данный момент человек может иметь отношения с адресной записью. Однако, если у человека есть адресная запись, связанная с ним, адресная запись не знает о записи о человеке, потому что в данный момент связь является односторонней — от человека к адресу . Однако большинство отношений в Базовых данных являются двусторонними, обе сущности знают об этих отношениях.
Давайте создадим обратную связь от объекта « Адрес» к объекту « Человек », выбрав объект « Адрес» и создав отношение с именем « персона» с объектом « Человек» в качестве пункта назначения.
Несмотря на то, что мы создали обратную связь между Address и Person , Xcode дает нам несколько предупреждений о том, что Person.address должен иметь обратное значение, а Address.person должно иметь обратное . Мы что-то сделали не так?
Базовые данные не достаточно умны, чтобы знать, какое отношение является обратным отношением к какому. Это легко исправить, хотя. Выберите объект « Персона» и установите значение « Обратное отношение адреса к человеку» . Если вы сейчас выберете объект « Адрес» , то увидите, что обратное отношение адреса уже установлено для отношения « человек» .
График модели данных
Когда модель данных приобретает все большую сложность, отношения могут стать запутанными и неясными. Xcode прикрыл твою спину. Редактор модели данных имеет два стиля, таблицу и график . В правом нижнем углу редактора вы увидите переключатель « Стиль редактора» , который позволяет переключаться между двумя стилями. Нажмите кнопку справа, чтобы переключиться на стиль графика.
Стиль графика показывает вам объектный граф, который мы создали до сих пор. Он показывает нам сущности, которые мы создали, их атрибуты и их отношения. Однако одной из наиболее полезных функций является визуальное представление отношений между объектами модели данных. Линия со стрелкой на каждом конце соединяет Персона и Адрес , символизируя их двусторонние отношения.
Отношения ко-многим
Отношения, которые мы создали до сих пор, относятся к одному , у человека может быть один адрес, и наоборот. Однако возможно, что несколько человек живут по одному адресу. Как бы мы включили эту дополнительную информацию в модель данных?
Кардинальность отношения определяет, является ли это отношением «один к многим». Давайте изменим отношение человека к объекту Address, чтобы сделать его отношением ко многим. Выберите отношение « персона» объекта « Адрес» , измените его имя на « лица», чтобы отразить отношение «ко-многим», и установите для типа отношения значение « Многие» в инспекторе справа.
Название отношений не важно, но оно показывает, что это отношения со многими. Обратите внимание, что график модели данных обновляется автоматически. Конечная точка отношения с сущностью Person имеет две стрелки, которые символизируют природу отношения «многие».
Отношения многие ко многим
Подожди минуту. Возможно ли, что человек связан с более чем одним адресом? Человек может иметь рабочий адрес и домашний адрес. Правильно? Core Data решает эту проблему, создавая взаимосвязь « многие ко многим» . Выберите адресное отношение объекта Person , измените его имя на адреса и установите для типа отношения значение « Многие» . График модели данных показывает обновленное отношение в виде линии с двумя стрелками на обоих концах.
Рефлексивные отношения
Базовые данные реализуют отношения очень гибко. Целевой объект отношения может даже совпадать с исходным объектом. Это известно как рефлексивные отношения. Также возможно иметь несколько связей одного типа с разными именами. Человек, например, может иметь мать и отца. Оба отношения рефлексивны, с единственным отличием — это название отношений.
Удалить правила
Что происходит, когда запись на одном конце отношения удаляется? Если бы вы думали о Core Data как о базе данных, то ответ был бы очевиден. Базовые данные, однако, не являются базой данных.
Предположим, у вас есть сущность Account с отношением «ко-многим» к сущности User . Другими словами, учетная запись может иметь много пользователей, и каждый пользователь принадлежит одной учетной записи. Что происходит, когда вы удаляете пользователя? Что происходит при удалении учетной записи? В Core Data каждое отношение имеет правило удаления, которое проясняет, что происходит в этих ситуациях.
Правила удаления позволяют вам не беспокоиться об явном обновлении постоянного хранилища при удалении записи. Core Data заботится об этом, чтобы гарантировать, что граф объектов остается в согласованном состоянии.
Выберите отношение адресов сущности Person и откройте инспектор справа. Меню « Удалить правило» имеет четыре параметра: « Без действия» , « Обнулить» , « Каскадировать» и « Запретить» .
Бездействие
Если вы выберете No Action , Core Data не будет обновлять или уведомлять исходную запись о взаимосвязи. Это означает, что исходная запись отношения по-прежнему считает, что она связана с удаленной записью. Это редко то, что вы хотите.
сводить на нет
Этот параметр устанавливает целевое значение отношения при удалении целевой записи. Это правило удаления отношений по умолчанию. Вы можете применить это правило удаления, если, например, связь является необязательной.
каскадный
Если отношение « Человек- адрес» установлено в « Каскад» , при удалении записи о человеке также будут удалены все записи адресов, связанные с этой записью о человеке. Это полезно, например, если требуется отношение, и запись не может или не должна существовать без отношения. Например, пользователь не должен существовать, если он не связан с учетной записью.
отказываться от
В каком-то смысле Дени — это инверсия каскада . Например, если у нас есть объект Account , имеющий отношение «многие» к объекту User с правилом удаления, установленным на « Запретить» , запись учетной записи может быть удалена только в том случае, если с ней не связано никаких записей пользователя. Это гарантирует, что никакие пользовательские записи не существуют без учетной записи.
Вывод
В этом руководстве мы более подробно рассмотрели модель данных, используемую приложением Core Data. Теперь вы должны быть знакомы с сущностями, атрибутами и связями, и вы сможете создавать их с помощью редактора модели данных Xcode.
Core Data очень хорошо управляет отношениями, а редактор модели данных Xcode позволяет легко создавать и управлять отношениями между объектами. Отношения между сущностями мощны и просты в настройке. Правила удаления гарантируют, что управляемый Core Data граф объектов остается исправным и в согласованном состоянии.
В следующей статье мы запачкаем руки и начнем работать с Core Data. Вы узнаете, как создавать, читать, обновлять и удалять записи, а также знакомиться с NSManagedObject и NSFetchRequest .