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