Как соотносятся домен, элемент данных, структура, тип таблицы и таблица базы данных, где проходят границы семантики и что проверять при изменениях.
3 мин чтения·База знаний
Ревизия 1Применимость к указанным контекстамЧастичное покрытиеКонтекст: CTX-GENERALдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
ABAP Dictionary задаёт глобальные типы и описывает объекты данных, доступные другим объектам ABAP в системе. При чтении модели важно не смешивать назначение домена, элемента данных, структуры и физической таблицы. Изменение одного объекта может требовать активации зависимых объектов и повлиять на несколько потребителей.
Домен задаёт технические свойства вроде базового типа, длины, десятичных разрядов и допустимых фиксированных значений. Один домен может использоваться несколькими элементами данных. Сам домен не объясняет бизнес-смысл конкретного поля.
Элемент данных описывает смысл поля и связывает его с техническим типом. На нём размещают подписи и документацию; к нему можно присоединить search help, чтобы одинаковый по смыслу ввод имел согласованную подсказку. Одинаковая техническая длина не делает два поля одним бизнес-понятием, а одинаковый элемент данных сам по себе не гарантирует одинаковых правил обработки во всех приложениях.
В сумме, количестве и дате важен не только тип. Сохраняйте ссылку на валюту или единицу измерения и проверяйте, что вычисления и интерфейс используют согласованные значения и точность. Для ключей отдельно различайте техническую идентичность записи и бизнес-ключ, по которому связываются процессы.
Структура задаёт состав полей, но сама по себе не является сохранённой строкой базы данных. Тип таблицы задаёт тип строк и способ представления внутренней таблицы ABAP, включая вид и ключи, применимые к внутренним таблицам. Таблица Dictionary определяет поля и настройки объекта хранения; при активации Dictionary формирует соответствующее описание для базы данных целевой платформы.
Не делайте вывод о физической схеме или нагрузке только по объявлению ABAP-типа. Для таблицы проверьте ключи, технические настройки и индексы в целевой системе. Вторичный индекс имеет стоимость изменений и хранения, поэтому добавляйте его под проверяемый профиль запросов. CDS-объекты и современные модели доступа описываются в соответствующих редакторах ADT; это отдельные сущности, хотя они могут взаимодействовать с Dictionary-типами.
Связь foreign key в Dictionary описывает отношение полей и может поддерживать проверки и помощь при вводе в соответствующем контексте. Она не должна автоматически трактоваться как универсальное ограничение целостности для любого способа записи: отдельно проверьте фактическую проверку приложения, интерфейса, базы данных и сценария массовой загрузки.
Search help отвечает за поиск и передачу выбранного значения в поле. Если он назначен элементу данных, этот ввод может использоваться всеми подходящими экранными полями, ссылающимися на элемент. Это не заменяет проверку полномочий и актуальности значения на серверной стороне.
Активация Dictionary-типа создаёт runtime-объект. Зависимые Dictionary-объекты должны быть активируемы; программы и экраны могут обновлять зависимое представление при последующем использовании. Поэтому после изменения проверяйте цепочку потребителей: домен, элемент данных, структуру или таблицу, views/CDS, программы, экраны и интеграционные контракты.
Append structures применяйте только в предусмотренном расширяемом контексте и с учётом enhancement category, namespace и правил целевой платформы. Это не общее разрешение модифицировать стандартную схему. В S/4HANA и ABAP Cloud дополнительно проверяйте released API и clean-core ограничения; допустимость классического расширения зависит от продукта, редакции и релиза.
Для изменений финансовых объектов сравните до и после: тип и точность суммы, ссылку на валюту, единицу измерения, ключ и его бизнес-смысл, настройки хранения, потребителей и результат активации. Проверьте перенос между системами и чтение старых данных, а не только успешную активацию объекта-разработки.
Ссылки описывают ABAP Platform 2025. Доступность редакторов и допустимых расширений зависит от установленного стека и редакции. В этом проекте нет ABAP-системы; активация объектов, поведение базы и перенос не запускались.
ABAP Dictionary: Types, Tables, and Relationships#
The ABAP Dictionary defines global types and data objects that other ABAP objects in the system can use. When reading a model, do not mix the roles of a domain, data element, structure, and physical table. Changing one object may require dependent objects to be activated and can affect several consumers.
A domain defines technical properties such as the base type, length, decimal places, and permitted fixed values. One domain can be used by multiple data elements. A domain by itself does not explain the business meaning of a particular field.
A data element describes the meaning of a field and connects it to a technical type. It carries labels and documentation; a search help can be assigned to it so suitable input fields with the same meaning can use consistent help. Having the same technical length does not make two fields one business concept, and sharing a data element does not guarantee identical processing rules in every application.
For amounts, quantities, and dates, the type alone is not enough. Preserve the reference to currency or unit of measure and verify that calculations and interfaces use consistent values and precision. Distinguish a record's technical identity from the business key used to connect processes.
A structure defines a set of fields but is not itself a persisted database row. A table type defines the row type and representation of an ABAP internal table, including its applicable table kind and keys. A Dictionary table defines fields and storage-object settings; on activation, the Dictionary produces the corresponding database definition for the target platform.
Do not infer physical schema or workload from an ABAP type declaration alone. For a table, check keys, technical settings, and indexes in the target system. A secondary index has a maintenance and storage cost, so add one for a verifiable query profile. CDS objects and modern access models are described in the relevant ADT editors; they are separate objects even though they can interact with Dictionary types.
A Dictionary foreign-key relationship describes a field relationship and can support checks and input help in the relevant context. Do not automatically treat it as a universal integrity constraint for every write method: separately verify application, interface, database, and bulk-load behavior.
A search help provides a way to search for and return a selected value to a field. When assigned to a data element, it can be used by suitable screen fields that refer to the element. This does not replace authorization and current-value checks on the server side.
Activating a Dictionary type generates a runtime object. Dependent Dictionary objects must be activatable; programs and screens may update their dependent representation on later use. After a change, check the consumer chain: domain, data element, structure or table, views/CDS, programs, screens, and integration contracts.
Use append structures only in a supported extension context and with the enhancement category, namespace, and target-platform rules in mind. This is not general permission to modify the standard schema. In S/4HANA and ABAP Cloud, also check released APIs and clean-core restrictions; whether a classic extension is allowed depends on product, edition, and release.
For changes to financial objects, compare before and after: amount type and precision, currency reference, unit of measure, key and its business meaning, storage settings, consumers, and activation result. Check transport between systems and the reading of existing data, not just successful activation in the development system.
The cited links describe ABAP Platform 2025. Available editors and permitted extensions depend on the installed stack and edition. This project has no ABAP system; object activation, database behavior, and transport were not run.