Шаблон бэкенда приложения регистратора музея
Контроль местоположения музейных объектов и workflow регистратора
Готовый к производству бэкенд регистратора музея на Back4app с отслеживанием музейных объектов, правом собственности на коллекцию, обновлениями местоположения, workflow соглашений о займе, историей журналов исключений и аудитом журналов активности. Включает ER-диаграмму, словарь данных, JSON-схему, API-песочницу и AI Агент для быстрой настройки.
Итоги регистратора
Этот шаблон предоставляет вам бэкенд для регистратора музея для записей MuseumObject, обновлений местоположения, рабочий процесс LoanAgreement, записи DeaccessionLog и историю ActivityLog, чтобы команды коллекций могли работать из одного общего источника правды.
- Контроль местоположения MuseumObject — Моделируйте каждый MuseumObject с currentLocation, status, collection, conditionSummary и provenanceNote, чтобы регистраторы могли отслеживать поступление от галереи до хранения.
- Рабочий процесс LoanAgreement — Отслеживайте исходящие и входящие займы с помощью статуса LoanAgreement, loanNumber, borrowingInstitution, startDate, dueDate и staff, подписавшего.
- Ответственность DeaccessionLog — Записывайте решения о деакцессии, этапы утверждения и заметки о finalDisposition в записях DeaccessionLog, связанных с каждым MuseumObject.
- Разрешения, удобные для регистратора — Используйте правила ACL и CLP, чтобы регистраторами, кураторами, менеджерами коллекций и консерваторами обрабатывались только те классы, к которым они назначены.
- Единый API для операций с коллекциями — Обслуживайте веб-, мобильные и административные инструменты через один REST и GraphQL уровень для MuseumObject, Location, Collection, LoanAgreement, DeaccessionLog и ActivityLog.
Что такое шаблон приложения регистратора музея?
Сроки в регистраторе музея редко бывают необязательными; структурированный уровень записи превращает даты в уведомления вместо сюрпризов. Динамика зависит от точного состояния. С Collection, Location, MuseumObject, LoanAgreement и DeaccessionLog на Back4app, команды регистратора музея могут обеспечить разделение обязанностей, продолжая сотрудничать над одной записью дела. Схема охватывает User (имя пользователя, email, пароль, роль, полное имя), Collection (номер поступления, название, отдел, главный куратор), Location (код, название, тип, защищенность), MuseumObject (номер поступления, название объекта, тип объекта, коллекция, текущее местоположение, статус), LoanAgreement (номер займа, музейный объект, тип займа, учреждение-заемщик, дата начала, дата возврата, подписант, статус соглашения), DeaccessionLog (номер отчуждения, музейный объект, дата решения, причина, утверждено, окончательное распределение, статус записи) и ActivityLog (актер, музейный объект, тип действия, дата действия) с встроенными потоками аутентификации и ведения учета. Подключите ваш предпочтительный фронтенд и отправляйте быстрее.
Лучше всего для:
Как организован этот бэкенд музея-регистратора
Пиковые недели выявляют задолженность музея-регистратора: обходы, которые казались нормальными в январе, становятся причиной, по которой вы пропускаете обязательства февраля.
Используйте Collection, Location и MuseumObject в качестве контрольного списка для объема MVP: если это не смоделировано, это станет обходным решением в таблицах.
Функции музея-регистратора
Каждая технологическая карточка в этом центре использует одну и ту же схемы назад музейного регистратора с Пользователем, Коллекцией, Местоположением, МузейнымОбъектом, ДоговоромЗайма, ЛогомИсключения и ЛогомДеятельности.
Управление MuseumObject
MuseumObject хранит accessionNumber, objectTitle, objectType, status, collection и currentLocation.
Отслеживание местоположений
Местоположение захватывает код, название, тип и isSecure.
Рабочий процесс Договоров займа
Договор займа связывает музейный объект, номер займа, тип займа, заимствующую организацию, срок возврата и статус соглашения.
Лог исключения отслеживает
Лог исключения фиксирует номер исключения, дату решения, причину, окончательное распределение и статус записи.
Почему стоит создавать бэкенд вашего приложения музея-регистратора с помощью Back4app?
Back4app предоставляет регистраторам, кураторам и менеджерам коллекций классы, необходимые для того, чтобы команда могла сосредоточиться на номерах поступлений, текущем местоположении и истории перемещений, а не на инфраструктуре.
- •MuseumObject и Location остаются связанными: Указатели MuseumObject и Location позволяют легко запрашивать текущее местоположение, статус и право собственности на коллекцию.
- •Записи LoanAgreement остаются под аудиторией: LoanAgreement хранит loanNumber, loanType, borrowingInstitution, startDate, dueDate, agreementStatus и signedBy для исходящих и входящих объектов.
- •Записи DeaccessionLog структурированы с первого дня: DeaccessionLog фиксирует deaccessionNumber, decisionDate, reason, approvedBy, finalDisposition и recordStatus для каждого случая удаления объекта.
Создайте бэкенд регистратора один раз, затем используйте ту же схему во всех рабочих процессах коллекции и клиентах.
Преимущества регистратора
Задний план музея, который помогает командам по коллекциям поддерживать порядок в движении, займах и исключениях.
Более быстрые поиски объектов
Начните с MuseumObject и Location вместо того, чтобы вручную создавать таблицы отслеживания поступлений и полок.
Чистое управление займами
Используйте поля LoanAgreement, такие как agreementStatus, dueDate, borrowingInstitution и signedBy, чтобы отслеживать исходящие и входящие займы.
Отслеживаемая история выбытия
Храните решения о выбытии в DeaccessionLog с decisionDate, reason, finalDisposition и approvedBy для дальнейшего просмотра.
Границы разрешений для ролей сотрудников
Применяйте правила ACL и CLP, чтобы регистраторам было разрешено редактировать записи MuseumObject, в то время как остальному персоналу разрешено только читать одобренные местоположения объектов.
Поисковые операции с коллекциями
Запрашивайте записи MuseumObject, Location, LoanAgreement, DeaccessionLog и ActivityLog, не сбрасывая схему каждый сезон.
Искусственный интеллект в поддержке создания
Сгенерируйте бэкенд регистратора музея и стартовые интеграции из одного структурированного запроса.
Готовы запустить приложение регистратора музея?
Позвольте ИИ-агенту Back4app создать ваш бэкенд регистратора и сгенерировать рабочие процессы MuseumObject, LoanAgreement, DeaccessionLog и ActivityLog из одного запроса.
Бесплатно для начала — 50 запросов ИИ-агента в месяц, без необходимости в кредитной карте
Технологический стек музея
Все включено в этот шаблон регистратора музея.
ER-диаграмма музея
Модель взаимосвязей сущностей для схемы бэкенда регистратора музея.
Схема, охватывающая пользователей, коллекции, местоположения, музейные объекты, договоры займа, журналы выбраковки и журналы активности.
Просмотреть источник диаграммы
erDiagram
User ||--o{ Collection : "primaryCurator"
User ||--o{ LoanAgreement : "signedBy"
User ||--o{ DeaccessionLog : "approvedBy"
User ||--o{ ActivityLog : "actor"
Collection ||--o{ MuseumObject : "collection"
Location ||--o{ MuseumObject : "currentLocation"
MuseumObject ||--o{ LoanAgreement : "museumObject"
MuseumObject ||--o{ DeaccessionLog : "museumObject"
MuseumObject ||--o{ ActivityLog : "museumObject"
User {
String objectId PK
String username
String email
String password
String role
String fullName
Date createdAt
Date updatedAt
}
Collection {
String objectId PK
String accessionNumber
String title
String department
String primaryCuratorId FK
Date createdAt
Date updatedAt
}
Location {
String objectId PK
String code
String name
String type
Boolean isSecure
Date createdAt
Date updatedAt
}
MuseumObject {
String objectId PK
String accessionNumber
String objectTitle
String objectType
String collectionId FK
String currentLocationId FK
String status
String conditionSummary
String provenanceNote
Date createdAt
Date updatedAt
}
LoanAgreement {
String objectId PK
String loanNumber
String museumObjectId FK
String loanType
String borrowingInstitution
Date startDate
Date dueDate
String signedById FK
String agreementStatus
Date createdAt
Date updatedAt
}
DeaccessionLog {
String objectId PK
String deaccessionNumber
String museumObjectId FK
Date decisionDate
String reason
String approvedById FK
String finalDisposition
String recordStatus
Date createdAt
Date updatedAt
}
ActivityLog {
String objectId PK
String actorId FK
String museumObjectId FK
String actionType
String notes
Date actionAt
Date createdAt
Date updatedAt
}
Поток интеграции регистратора
Типичный поток выполнения для аутентификации, поиска MuseumObject, обновлений местоположения, создания LoanAgreement, записей DeaccessionLog и обновлений ActivityLog.
Просмотреть источник диаграммы
sequenceDiagram
participant User
participant App as Museum Registrar App
participant Back4app as Back4app Cloud
User->>App: Sign in as registrar, curator, or collections manager
App->>Back4app: POST /login
Back4app-->>App: Session token
User->>App: Open object location board
App->>Back4app: GET /classes/MuseumObject?include=collection,currentLocation&order=accessionNumber
Back4app-->>App: MuseumObject list with Location and Collection pointers
User->>App: Record a transfer to storage or gallery
App->>Back4app: PUT /classes/MuseumObject/{objectId}
Back4app-->>App: Updated currentLocation and status
User->>App: Create a loan agreement or deaccession log
App->>Back4app: POST /classes/LoanAgreement or /classes/DeaccessionLog
Back4app-->>App: Agreement or log saved
App->>Back4app: Subscribe to ActivityLog updates
Back4app-->>App: Live updates for object movements and record changesПолевой справочник музея
Полное полевое руководство для каждого класса в схеме регистратора музея.
| Поле | Тип | Описание | Обязательно |
|---|---|---|---|
| objectId | String | Auto-generated unique identifier | Авто |
| username | String | User login name | |
| String | User email address | ||
| password | String | Hashed password (write-only) | |
| role | String | Role of the user (e.g., registrar, curator, collections-manager, conservator, read-only-staff) | |
| fullName | String | Display name for staff and stakeholders | |
| createdAt | Date | Auto-generated creation timestamp | Авто |
| updatedAt | Date | Auto-generated last-update timestamp | Авто |
8 поля в User
Безопасность регистратора и разрешения
Как стратегия ACL и CLP защищает записи MuseumObject, документы займа и заметки о снятии.
Доступ регистратора на основе ролей
Регистраторы могут создавать и редактировать записи MuseumObject, Location, LoanAgreement и DeaccessionLog; другим сотрудникам предоставляется доступ только для чтения, где это уместно.
Контроль займа и снятия из учета
Ограничить права на запись для LoanAgreement и DeaccessionLog, чтобы одобрения оставались у уполномоченного персонала коллекции.
Целостность истории объекта
Используйте Cloud Code для проверки обновлений currentLocation и добавления ActivityLog перед сохранением изменений перемещения.
JSON-схема
Сырая JSON-схема, готовая к копированию в Back4app или использованию в качестве справочной реализации.
{
"classes": [
{
"className": "User",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"username": {
"type": "String",
"required": true
},
"email": {
"type": "String",
"required": true
},
"password": {
"type": "String",
"required": true
},
"role": {
"type": "String",
"required": true
},
"fullName": {
"type": "String",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "Collection",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"accessionNumber": {
"type": "String",
"required": true
},
"title": {
"type": "String",
"required": true
},
"department": {
"type": "String",
"required": true
},
"primaryCurator": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "Location",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"code": {
"type": "String",
"required": true
},
"name": {
"type": "String",
"required": true
},
"type": {
"type": "String",
"required": true
},
"isSecure": {
"type": "Boolean",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "MuseumObject",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"accessionNumber": {
"type": "String",
"required": true
},
"objectTitle": {
"type": "String",
"required": true
},
"objectType": {
"type": "String",
"required": true
},
"collection": {
"type": "Pointer",
"required": true,
"targetClass": "Collection"
},
"currentLocation": {
"type": "Pointer",
"required": true,
"targetClass": "Location"
},
"status": {
"type": "String",
"required": true
},
"conditionSummary": {
"type": "String",
"required": false
},
"provenanceNote": {
"type": "String",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "LoanAgreement",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"loanNumber": {
"type": "String",
"required": true
},
"museumObject": {
"type": "Pointer",
"required": true,
"targetClass": "MuseumObject"
},
"loanType": {
"type": "String",
"required": true
},
"borrowingInstitution": {
"type": "String",
"required": true
},
"startDate": {
"type": "Date",
"required": true
},
"dueDate": {
"type": "Date",
"required": true
},
"signedBy": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"agreementStatus": {
"type": "String",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "DeaccessionLog",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"deaccessionNumber": {
"type": "String",
"required": true
},
"museumObject": {
"type": "Pointer",
"required": true,
"targetClass": "MuseumObject"
},
"decisionDate": {
"type": "Date",
"required": true
},
"reason": {
"type": "String",
"required": true
},
"approvedBy": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"finalDisposition": {
"type": "String",
"required": true
},
"recordStatus": {
"type": "String",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "ActivityLog",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"actor": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"museumObject": {
"type": "Pointer",
"required": true,
"targetClass": "MuseumObject"
},
"actionType": {
"type": "String",
"required": true
},
"notes": {
"type": "String",
"required": false
},
"actionAt": {
"type": "Date",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
}
]
}Создавайте с помощью AI Agent
Используйте AI Agent Back4app для генерации реального приложения регистратуры музея из этого шаблона, включая фронтенд, бэкенд, аутентификацию, а также потоки объектов, займов и вывода из фондов.
Создайте бэкэнд приложения Регистраторов музеев на Back4app с этой точной схемой и поведением. Схема: 1. Пользователь (используйте встроенное решение Back4app): имя пользователя, электронная почта, пароль, роль, полное имя; objectId, createdAt, updatedAt (система). 2. Коллекция: номер поступления (строка, обязательный), название (строка, обязательный), отдел (строка, обязательный), главный куратор (указатель на пользователя, обязательный); objectId, createdAt, updatedAt (система). 3. Локация: код (строка, обязательный), имя (строка, обязательный), тип (строка, обязательный), защищенно ли (булевый, обязательный); objectId, createdAt, updatedAt (система). 4. Экспонат музея: номер поступления (строка, обязательный), название объекта (строка, обязательный), тип объекта (строка, обязательный), коллекция (указатель на коллекцию, обязательный), текущее местоположение (указатель на локацию, обязательный), статус (строка, обязательный), сводка состояния (строка, необязательный), заметка о происхождении (строка, необязательный); objectId, createdAt, updatedAt (система). 5. Договор займа: номер займа (строка, обязательный), музейный объект (указатель на музейный объект, обязательный), тип займа (строка, обязательный), заимствующая организация (строка, обязательный), дата начала (дата, обязательный), дата истечения (дата, обязательный), подписанный (указатель на пользователя, обязательный), статус соглашения (строка, обязательный); objectId, createdAt, updatedAt (система). 6. Журнал деакцессии: номер деакцессии (строка, обязательный), музейный объект (указатель на музейный объект, обязательный), дата решения (дата, обязательный), причина (строка, обязательный), одобрено (указатель на пользователя, обязательный), окончательное распределение (строка, обязательный), статус записи (строка, обязательный); objectId, createdAt, updatedAt (система). 7. Журнал активности: актёр (указатель на пользователя, обязательный), музейный объект (указатель на музейный объект, обязательный), тип действия (строка, обязательный), заметки (строка, необязательный), действие по (дата, обязательный); objectId, createdAt, updatedAt (система). Безопасность: - Роли регистратора, куратора и менеджера коллекций могут создавать и редактировать записи Музейного объекта, Локации, Договора займа и Журнала деакцессии в соответствии со своей ответственностью. - Ограничить доступ к записям коллекции и объекта только для авторизованного персонала. - Сохранять записи о займе и деакцессии подлежащими аудиту; сохранить историю Журнала активности. Аутентификация: - Регистрация, вход, выход. Поведение: - Отслеживание местоположений объектов, управление договорами займа и запись журналов деакцессии. - Показать коллекции по отделам и объекты по текущему местоположению и статусу. - Сохранять заметки активности, когда Музейный объект перемещается, договор займа подписывается или деакцессия одобряется. Доставка: - Приложение Back4app с схемой, CLP, ACL и интерфейсом для регистраторов, кураторов, менеджеров коллекций и специалистов по охране для управления перемещением объектов, документацией по займам и рабочими процессами деакцессии.
Нажмите кнопку ниже, чтобы открыть Агент с заранее заполненным запросом этого шаблона.
Это базовый запрос без суффикса технологии. Вы можете адаптировать сгенерированную фронтенд-стек позже.
API Sandbox
Попробуйте REST и GraphQL конечные точки с учетом схемы регистратора музея. Ответы используют макетные данные и не требуют учетной записи Back4app.
Использует ту же схему, что и этот шаблон.
Выберите вашу технологию
Разверните каждую карточку, чтобы увидеть, как интегрировать Collection, Location и MuseumObject с вашим выбранным стеком.
Flutter Регистратор музея Бэкенд
React Регистратор музея Бэкенд
React Native Регистратор музея Бэкенд
Next.js Регистратор музея Бэкенд
JavaScript Регистратор музея Бэкенд
Android Регистратор музея Бэкенд
iOS Регистратор музея Бэкенд
Vue Регистратор музея Бэкенд
Angular Регистратор музея Бэкенд
GraphQL Регистратор музея Бэкенд
REST API Регистратор музея Бэкенд
PHP Регистратор музея Бэкенд
.NET Регистратор музея Бэкенд
Что вы получаете с каждой технологией
Каждый стек использует одну и ту же схему бэкенда музея и API-контракты.
Унифицированная структура музейных данных
Управляйте записями MuseumObject, статьями Location, файлами LoanAgreement и нотами DeaccessionLog с помощью одной схемы.
Отслеживание местоположения объектов для команд коллекций
Сохраняйте информацию о текущем местоположении и истории активности, читабельной для регистраторов и кураторов.
Процессы соглашений о займах для музеев
Храните borrowingInstitution, dueDate, agreementStatus и signedBy в одном структурированном потоке.
Документация по деактивации для музеев
Запишите recordStatus, decisionDate и причину для проверки и аудита.
REST/GraphQL API для музейных приложений
Подключите веб, мобильные и внутренние инструменты, используя гибкие API.
Расширяемая архитектура для операций с коллекциями
Добавляйте поля или классы по мере эволюции поступлений и выставок.
Сравнение стеки музея-регистратора
Сравните скорость настройки, стиль SDK и поддержку ИИ для всех поддерживаемых технологий.
| Фреймворк | Время настройки | Преимущество для регистратора музея | Тип SDK | Поддержка ИИ |
|---|---|---|---|---|
| Около 5 минут | Единая кодовая база для мобильных и веб-инструментов регистратора. | Типизированный SDK | Полный | |
| Менее 5 минут | Быстрая веб-панель для отслеживания объектов. | Типизированный SDK | Полный | |
| ~3–7 мин | Кроссплатформенное мобильное приложение для сотрудников по сбору. | Типизированный SDK | Полный | |
| Быстрая настройка (5 мин) | Серверный портал регистратора для сотрудников. | Типизированный SDK | Полный | |
| ~3–5 мин | Легкая веб-интеграция для инструментов регистратора. | Типизированный SDK | Полный | |
| Около 5 мин | Родное приложение Android для отслеживания галереи и хранения. | Типизированный SDK | Полный | |
| Менее 5 минут | Родное приложение iOS для сотрудников музея. | Типизированный SDK | Полный | |
| ~3–7 мин | React веб-интерфейс для операций с коллекциями. | Типизированный SDK | Полный | |
| Быстрая настройка (5 мин) | Корпоративное веб-приложение для рабочих процессов регистратора. | Типизированный SDK | Полный | |
| Менее 2 минут | Гибкий GraphQL API для представлений объектов и займов. | GraphQL API | Полный | |
| Быстрая настройка (2 мин) | REST API интеграция для систем регистраторов. | REST API | Полный | |
| ~3 мин | Серверная часть PHP для инструментов музеев. | REST API | Полный | |
| ~3–7 мин | .NET бэкенд для управления коллекциями. | Типизированный SDK | Полный |
Время настройки отражает ожидаемую продолжительность от начальной загрузки проекта до первого запроса MuseumObject или LoanAgreement с использованием этой схемы шаблона.
Вопросы регистраторов музеев
Распространенные вопросы о создании бэкенда регистратора музея с помощью этого шаблона.
Готовы создать приложение для регистратора вашего музея?
Начните свой проект регистратора музея за считанные минуты. Кредитная карта не требуется.