ABAP-словарь данных
Словарь данных ABAP — это центральное хранилище, используемое для создания определений данных (метаданных) и управления ими. Централизованное хранение определений данных в словаре данных ABAP помогает избежать избыточности. Кроме того, поскольку словарь данных APAP является центральным репозиторием, любые изменения, внесенные в его определения данных, будут автоматически отражены в программах. Другими словами, словарь данных ABAP обеспечивает целостность данных, согласованность данных и безопасность данных.
Таблицы базы данных
Таблицы базы данных являются одним из наиболее важных объектов в словаре данных ABAP. Как вы знаете, каждая система SAP состоит из базовой реляционной базы данных или базы данных в памяти, такой как SAP HANA. Однако мы можем определять таблицы независимо от баз данных в словаре данных ABAP. Мы не работаем на уровне базы данных, чтобы определить таблицы базы данных; мы всегда используем словарь данных ABAP для поддержки определений таблиц базы данных.
Как только соответствующий объект (таблица) определен в словаре данных ABAP и активирован, система физически создает таблицу базы данных в базовой базе данных с той же структурой, что и определение таблицы, определенное в словаре данных ABAP. Система автоматически преобразует определения таблицы в словаре данных ABAP в определения, присущие базовой базе данных. Это позволяет нам не беспокоиться о специфике базовой базы данных; Словарь данных ABAP выступает в качестве промежуточного программного обеспечения между базой данных и системой SAP.
Таблица базы данных в словаре данных ABAP состоит из следующих компонентов:
Поля таблицы
Каждая таблица базы данных состоит из полей. Поля таблицы определяют структуру таблицы базы данных. Каждое поле таблицы базы данных полностью определяется назначением типа данных. Поля представляют столбцы таблицы, а первичный ключ таблицы существует как подмножество полей таблицы.
Внешние ключи
Внешние ключи определяют связь между текущей таблицей базы данных и другими таблицами базы данных в базе данных.
Технические настройки
Технические параметры управляют созданием таблицы базы данных в базовой базе данных. Мы можем поддерживать различные настройки, такие как исходный размер таблицы базы данных, табличное пространство для создания таблицы базы данных и так далее.
Индексы
Ключевые поля таблицы базы данных образуют первичный индекс таблицы базы данных. Дополнительные вторичные индексы могут быть созданы для ускорения выбора данных.
В словаре данных ABAP можно определить следующие категории таблиц:
Прозрачная таблица: каждая прозрачная таблица, определенная в словаре данных ABAP, создает ровно одну таблицу базы данных в базовой базе данных с идентичными именами и полями. Все таблицы клиентов, включая таблицы, в которых хранятся бизнес-данные, должны быть определены как прозрачные таблицы.
Таблицы пула и таблицы кластера. Таблицы пула и таблицы кластера — это специфичная для SAP категория таблиц базы данных, которая имеет отношения «один ко многим» с базовыми таблицами базы данных. Другими словами, когда вы определяете таблицу пула или таблицу кластера в словаре данных ABAP, она может создать несколько таблиц базы данных в базовой базе данных. Эти таблицы обычно используются SAP для хранения информации внутреннего контроля, документации и т. д.
Эти таблицы не следует использовать для хранения бизнес-данных. SAP рекомендует преобразовать все существующие объединенные таблицы и кластерные таблицы в прозрачные таблицы. Как и в случае с прозрачными таблицами, вы можете использовать операторы Open SQL для доступа к таблицам пула и кластера; однако вы не можете использовать инструкции Native SQL для таблиц пула и кластера.
Глобальные временные таблицы (GTT): с выпуском SAP NetWeaver 7.5 стала доступна новая категория таблиц — глобальные временные таблицы. GTT — это специальные прозрачные таблицы, используемые для хранения временных данных в логической единице работы базы данных (LUW). База данных LUW существует между каждым шагом диалога. Каждый шаг диалога включает логику программирования между двумя последовательными экранами. Отдельные диалоговые шаги программы могут выполняться различными рабочими процессами на сервере приложений, а программа состоит из нескольких диалоговых шагов. GTT позволяют разбивать сложные процессы базы данных на несколько этапов, например, сохранять временные промежуточные итоги.
Таблицы GTT разработаны специально для хранения временных данных в базе данных LUW и, таким образом, требуют гораздо меньших затрат на администрирование, чем обычные прозрачные таблицы. GTT всегда пуст в начале LUW базы данных, что означает, что он должен очищаться в конце каждой LUW базы данных. Системы баз данных обычно обеспечивают встроенную поддержку GTT, неявно определяя данные в таблице базы данных GTT как данные, специфичные для транзакции. Это гарантирует, что данные в GTT неявно удаляются в конце LUW базы данных (когда выполняется фиксация или откат базы данных).
Если GTT, определенный в словаре данных ABAP, заполняется явно с помощью операторов Open SQL, то его следует явно очищать в конце LUW базы данных с помощью оператора DELETE FROM dbtab. GTT также следует явно очищать, если используются операторы ABAP, такие как COMMIT WORK, COMMIT CONNECTION, ROLLBACK WORK, ROLLBACK CONNECTION, или связанные операторы Native SQL. Операторы COMMIT WORK и ROLLBACK WORK очищают GTT всех открытых в данный момент подключений к базе данных, но вы можете удалить GTT указанного соединения с помощью операторов COMMIT CONNECTION и ROLLBACK CONNECTION.
Если GTT словаря данных ABAP не очищается явно с помощью инструкции DELETE FROM dbtab до выполнения неявной фиксации базы данных, это приведет к ошибке COMMIT_GTT_ERROR во время выполнения. Эта ошибка времени выполнения возникает, даже если таблица пуста, если инструкция DELETE FROM dbtab снабжена предложением WHERE. SAP принудительно очищает GTT словаря данных ABAP, чтобы гарантировать, что код будет прозрачным и простым для понимания. Например, разработчик может быть удивлен, обнаружив пустую таблицу между модулями программирования, если таблица была неявно очищена системой базы данных из-за LUW базы данных, выполненного RFC. Явная очистка GTT также помогает избежать зависимостей от платформы, поскольку не все системы баз данных неявно очищают GTT. Доступ к GTT можно получить так же, как и к обычным прозрачным таблицам, с помощью операторов Open SQL и Native SQL. Однако SAP рекомендует использовать только операторы Open SQL при работе с GTT.
Структура. Когда вы выбираете Структура, таблица базы данных преобразуется в структурированный тип данных.
Настройки для класса поставки и ведение брауз. дан./ракурса табл.
Класс поставки: это поле позволяет вам выбрать тип данных, которые будут содержаться в таблице базы данных. Параметр, выбранный для класса поставки, будет управлять переносом данных таблицы во время установки, обновлений и клиентских копий. Этот параметр также влияет на транспортировку между клиентскими системами.
Ведение брауз. дан./ракурса табл это поле позволяет ограничить возможность ввода данных пользователем вручную или возможность обновления таблицы только с помощью программ (например, транзакция SE16).
Используйте справку (F1) в обоих полях, чтобы узнать больше об этих настройках.
На вкладке «Поля» находится таблица, содержащая несколько столбцов:
Ключ: установите этот флажок, если поле является частью ключа таблицы. Все ключевые поля должны располагаться в верхней части таблицы непрерывно.
Начальное значения: Установите этот флажок, чтобы установить флаг NOT NULL в базе данных. Этот параметр полезен при добавлении новых полей в существующую таблицу базы данных, поскольку система автоматически заполнит поле начальными значениями, совместимыми по типу, для всех строк поля. Если этот флаг не установлен для новых полей в существующей таблице, система присвоит значение NULL для всех строк поля. Поскольку в ABAP нет аналога для NULL, это поле можно затем запросить, только используя специальное условие WHERE IS NULL или IS NOT NULL с Open SQL.
При использовании этой настройки помните о следующих моментах:
Этот параметр не действует для новых таблиц, поскольку для новых таблиц по умолчанию установлен флаг NOT NULL. Этот флаг всегда установлен для ключевых полей.
Компоненты таблицы можно определить, включив компоненты других плоских структур в словарь данных ABAP. Эти структуры известны как включающие структуры. Если этот флаг установлен для включаемой структуры, то он применяется только к компонентам структуры, для которых установлен этот флаг. Если компонент структуры не установлен с этим флагом, он будет проигнорирован.
Рекомендуется использовать этот флаг только в случае необходимости или если в таблице мало записей. В таблицах с большим количеством записей установка начальных значений, совместимых по типу, может занять много времени.
Элемент данных: элемент данных, от которого поле должно наследовать семантические и технические свойства. Если вы хотите создать новый элемент данных, вы можете ввести имя элемента данных и дважды щелкнуть его, чтобы создать новый элемент данных.
Тип данных/длина/десятичные разряды/краткое описание: эти поля отключены по умолчанию и заполняются автоматически на основе элемента данных, предоставленного в предыдущем поле. Если вы хотите сохранить тип данных, длину, десятичные разряды и краткое описание вручную, нажмите кнопку «Встроенный тип» и введите данные вручную. Обратите внимание, что для полей без элементов данных предоставляется только ограниченная функциональность. В этих полях не могут быть определены внешние ключи или фиксированные значения. Для этих полей нет справки (F1).
Группа: при включении структуры в таблицу, структуре можно присвоить имя группы. Программы ABAP могут получать доступ к полям этой структуры вместе или по отдельности, используя имя группы. Обратите внимание, что компоненты структуры являются частью таблицы, поэтому доступ к ним можно получить напрямую, используя ссылку на имя таблицы. Предоставление имени группы является необязательным.
Категория расширения структуры.
Структуры словаря ABAP и таблицы базы данных, поставляемые SAP, могут быть расширены с помощью настройки структур включения или добавления . Эти типы изменений вызывают проблемы, если улучшения изменяют представление фрагмента структуры .
По этой причине структуры и таблицы базы данных классифицируются, что позволяет распознавать и решать проблемы, связанные с усовершенствованием структуры. Эта классификация используется во время проверки программы для создания предупреждений во всех точках, где программа работает со структурами, и где более поздние усовершенствования структуры могут вызвать синтаксические ошибки или изменения в поведении программы. Когда структура или таблица базы данных определены в ABAP-словаре, в качестве классификации можно использовать категории расширения.
Не классифицировано. Эту категорию можно выбрать, например, для статуса перехода; однако его нельзя выбирать для создания структур.
Правила определения категории расширения неявным образом вытекают из настройки структуры и классификации используемых типов.
Без возможности расширения. Структура не должна расширяться.
Возможно буквенное расширение. Все компоненты структуры и их улучшения должны быть символьного типа (C, N, D или T). Это ограничение распространяется на исходную структуру и все усовершенствования посредством пользовательской настройки, включающей или добавляющей структуры.
Возможно буквенное или цифровое расширение. Структура и ее расширение не должны содержать глубоких типов данных (таблиц, ссылок, строк).
Любое расширение возможно. Структура и ее расширение могут содержать компоненты, тип данных которых может относиться к любой категории.
Технические параметры таблицы
Технические параметры определяют способ создания таблицы в базе данных( SE13 ).
Технические параметры таблицы базы данных:
Вид данных: этот параметр важен только для платформ баз данных Oracle и Informix. Для всех других платформ баз данных этот параметр следует игнорировать. Этот параметр определяет физическую область базы данных (известную как табличное пространство), в которой должна быть создана таблица. Используйте справку, чтобы выбрать тип данных, которые вы планируете хранить в таблице. На основе значения система автоматически определит местонахождение таблицы в базе данных.
Категория размера. Категория размера определяет начальный объем памяти, выделяемый для таблицы базы данных. Если начальное пространство памяти израсходовано, размер таблицы будет увеличен на то же значение, известное как расширение. Обеспечьте хорошую оценку, чтобы избежать слишком большого количества маленьких областей памяти или слишком больших областей памяти. Используйте справку (F4), чтобы выбрать подходящее значение. Вы можете попросить своего функционального консультанта предоставить вам оценку ожидаемых записей.
Буферизация: эти настройки определяют, следует ли буферизовать данные в таблице базы данных. Если буферизация включена, система будет хранить копию содержимого базы данных на сервере приложений, чтобы ускорить отбор данных и повысить производительность. Поскольку данные для буферизованных таблиц могут быть доступны непосредственно из буфера сервера приложений, буферизация помогает избежать трудоемкого процесса доступа к базе данных, а также снижает нагрузку на сеть.
Буферизация рекомендуется для данных, которые редко изменяются. Когда приложение изменяет данные буферизованной таблицы на сервере приложений, интерфейс базы данных отмечает это изменение в журнале. Программа синхронизации проверяет этот журнал и обновляет его на основе изменений через регулярные промежутки времени (скажем, каждые одну-две минуты), чтобы синхронизировать буфер сервера приложений с данными в соответствующей таблице базы данных. Если данные в таблице базы данных часто изменяются, программа синхронизации постоянно обновляет данные в буфере, что может повлиять на производительность системы. По этой причине мы не рекомендуем буферизировать таблицы, для которых часто меняются данные, или использовать буферизацию, когда требуется доступ к данным в реальном времени.
Для установки разрешений на буферизацию доступны следующие параметры:
Буферизация запрещена: этот параметр отключает буферизацию для таблицы базы данных и указывает, что эта таблица не должна буферизоваться ни в одной системе.
Буферизация разрешена, но выключена: этот параметр указывает, что буферизация для таблицы базы данных отключена при доставке, но может быть активирована позже в других системах, в зависимости от того, как используется таблица.
Буферизация включена: этот параметр активирует буферизацию, и содержимое таблицы базы данных буферизуется на сервере приложений.
Тип буферизации: если буфер таблицы активирован, необходимо определить тип буферизации. Тип буферизации определяет, сколько записей таблицы базы данных буферизуется при чтении записи из таблицы базы данных. Доступны следующие типы буферизации: Буферизация отдельных записей, Буферизация общей области, Полная буферизация. Если выбран параметр «Буферизация отдельных записей», буферизуются только те строки, к которым обращается программа. Если выбрана общая буферизованная область, количество ключевых полей должно быть введено в поле ввода. Когда строка считывается из таблицы базы данных, система буферизует все совпадающие строки полей первичного ключа до числа ключевых полей, поддерживаемых для этого параметра. Кроме того, если выбран параметр «Полная буферизация», все строки таблицы буферизируются при чтении строки таблицы. С этой опцией либо все данные в таблице базы данных существуют в буфере, либо нет никаких данных.
Регистрировать изменения данных: этот параметр определяет, должны ли данные в таблице регистрироваться для любых изменений. Если выбран этот параметр, все изменения данных в таблице базы данных будут регистрироваться.
Доступ для записи только с помощью Java: если выбран этот параметр, данные в таблице могут быть обновлены или изменены только из приложений Java.
Обратите внимание, что для GTT технические параметры предопределены и не могут быть изменены. Тип данных и категория размера игнорируются и не определяются. Буферизация SAP не разрешена, ведение журналов отключено.
Индексы
Первичный индекс
Ключевые поля таблицы базы данных образуют первичный индекс таблицы. При создании таблицы базы данных система автоматически создает первичный индекс для ключевых полей. Вы можете думать об индексе как о копии фактической таблицы, но с уменьшенным количеством полей (состоящим только из полей индекса) и с указателями на другие поля таблицы. Записи в указателе всегда сортируются, чтобы обеспечить более быстрый доступ к записям таблицы. Когда выполняется поиск записи таблицы с использованием полей индекса, система проверяет индекс вместо того, чтобы вручную сканировать таблицу базы данных, чтобы быстрее получить данные.
Например, скажем, таблица XYZ имеет четыре поля — A, B, C и D — с A в качестве ключевого поля. Если мы напишем запрос выбора как SELECT * FROM TABLE xyz WHERE A = '10', система проверит индекс, чтобы найти запись, где A = 10, и использует указатель для извлечения оставшихся полей строки из таблицы.
Помимо первичного индекса, созданного по умолчанию, мы можем создавать другие индексы, называемые вторичными индексами. Это необходимо, если мы выполняем поиск в таблице, в которой полный первичный ключ не используется в предложении WHERE. Например, если мы ищем таблицу XYZ, где D=41, то система не может использовать первичный индекс, потому что первичный индекс хранит только ключевые поля.
В таких ситуациях, когда подходящий индекс недоступен, система выполняет полное сканирование таблицы, что влияет на производительность. Чтобы избежать полного сканирования таблицы, если полный первичный ключ не может быть указан в предложении WHERE, мы можем создать вторичные индексы.
Ядро базы данных состоит из оптимизатора SQL, который анализирует SQL-запрос и оптимизирует доступ к данным, выполняя определение стоимости и анализируя табличную статистику. Оптимизатор SQL выбирает наилучшую стратегию поиска для доступа к данным. Например, если таблица содержит несколько индексов, оптимизатор SQL автоматически выбирает наиболее подходящий индекс для чтения данных.
Оптимизатор SQL также может определить, приводит ли полное сканирование таблицы к более эффективному доступу, чем выбор любого из доступных индексов. Иногда оптимизатор SQL может игнорировать индекс и выполнять полное сканирование таблицы, даже если подходящий индекс доступен. Это может произойти, если оптимизатор SQL обнаружит, что стоимость полного сканирования таблицы ниже, чем стоимость использования вторичного индекса из-за настроек профиля, которые более благоприятны для полного сканирования таблицы. Некоторые базы данных, такие как Oracle, поддерживают подсказки, что позволяет вам как разработчику приложений принимать решения, которые обычно принимает оптимизатор SQL.
Иногда вам может быть известна информация о ваших данных, которую оптимизатор SQL может не знать; например, вы можете знать, что определенный индекс более селективен для определенных запросов, но оптимизатор SQL может его игнорировать. В таких случаях вы можете использовать подсказки, чтобы заставить оптимизатор SQL использовать определенный индекс. Вы можете снабдить свой запрос подсказками, используя параметр %_HINTS.
SELECT <fields> INTO TABLE <itab> FROM <database table>
WHERE <logical expression>
AND <logical expression>
%_HINTS <database name> 'INDEX("<database table>" "Index name")'.
За параметром %_HINTS следует имя базы данных и индекс используемой таблицы. Если база данных Oracle и мы хотим, чтобы оптимизатор SQL использовал вторичный индекс SPFLI~001 таблицы SPFLI, мы можем написать запрос, как показано ниже.
SELECT * FROM spfli
INTO TABLE it_spfli
WHERE cityfrom EQ 'NEW YORK'
AND cityto EQ 'SAN FRANCISCO'
%_HINTS ORACLE 'INDEX("SPFLI" "SPFLI~001")'.
Несколько вторичных индексов в одной и той же таблице идентифицируются с помощью трехсимвольного идентификатора индекса.
Уникального индекса или неуникального индекса. Если значения в полях индекса однозначно идентифицируют строку (т. е. комбинация значений в ключевых полях не должна встречаться в таблице более одного раза), выберите Уникальный индекс. В противном случае выберите Неуникальный индекс. Когда вы выбираете Неуникальный индекс, вы также можете выбрать, должен ли индекс создаваться во всех системах баз данных (Индекс для всех систем баз данных), Для выбранных систем баз данных или вообще не создаваться в базе данных (Без индекса базы данных).
Порядок выбранных полей очень важен. При запросе к таблице индекс используется только в том случае, если порядок полей указан в том же порядке, что и в предложении WHERE оператора SELECT, или если указана подсказка оптимизатора SQL (для некоторых систем баз данных, таких как Oracle).
Создание дополнительных вторичных индексов может иметь побочные эффекты для производительности системы. Не рекомендуется создавать слишком много индексов или индексов со слишком большим количеством общих полей, потому что это может затруднить для оптимизатора выбор наиболее селективного индекса.
Генератор введения таблиц
Чтобы упростить пользователям ввод данных в таблицу базы данных, мы можем создать представление введения для таблицы базы данных.
На этом экране у вас есть следующие опции:
Группа полномочий: Укажите группу авторизации, чтобы ограничить разрешение обслуживания для избранных пользователей. Введите «&NC&» в это поле, если вы не хотите устанавливать какие-либо ограничения.
Группа функций: введите имя группы функций, в которой будет создан весь необходимый код.
Пакет: Отображает пакет, которому назначен объект.
Тип обслуживания: для этого поля есть два переключателя:
– одноуровневый: это создаст единый экран для отображения и обслуживания.
– двухуровневый: будут созданы два экрана, один для отображения и один для обслуживания.
Номер экрана введения: Вы можете ввести номера экранов, которые должны быть созданы, или использовать кнопку «Найти номера экранов» на панели инструментов приложения, чтобы система предложила доступные номера экранов для выбранной функциональной группы.
Подпрограмма записи: позволяет записывать изменения в записи таблицы, которые затем можно перенести. Выберите стандартную процедуру записи или нет или пользовательскую процедуру записи. Если вы выберете стандартную процедуру записи, система будет использовать стандартную процедуру для записи изменений, и данные могут быть перенесены на основе настроек клиента. Отключение этой опции приведет к тому, что изменения не будут записаны и данные не будут переданы.
Внешние ключи
Внешние ключи определяют отношения между таблицами. Если поле одной таблицы существует как ключевое поле в другой таблице, то говорят, что таблицы находятся во взаимосвязи внешнего ключа. Таблица, в которой поля существуют как ключи, называется проверочной таблицей, а другая таблица называется таблицей внешнего ключа.
Используя проверочную таблицу, можно выполнять автоматическую проверку ввода для поля в таблице внешнего ключа. Это обеспечивает целостность данных, и в систему не попадают недействительные данные. Например, если у вас есть пользовательская таблица с полем MATNR, и вы хотите, чтобы пользователь ввел только действительные номера материалов, хранящиеся в основной таблице материалов MARA, вы можете создать отношение внешнего ключа с MARA в качестве проверочной таблицы.
Когда пользователь вводит номер материала в вашу пользовательскую таблицу, система автоматически проверяет, существует ли запись в таблице MARA. Обратите внимание, что отношение внешнего ключа создается только в словаре данных ABAP, а не в базе данных. Проверка выполняется по контрольной таблице только тогда, когда пользователь вводит запись через экран. Проверка не выполняется, когда записи обновляются с помощью операторов Open SQL. При программировании оператора Open SQL проверочная таблица должна учитываться вручную и проверяться в программе.
Если в домене поля ведется таблица значений, система отобразит запрос на создание предложения на основе таблицы значений. Таблица значений поддерживается в домене, прикрепленном к элементу данных; он указывает возможные записи для поля, но не выполняет никаких проверок.
Таблицы проверки выполняют проверки ввода в поле. В большинстве случаев таблица значений и таблица проверки будут одинаковыми; в противном случае таблица значений может предложить значение в качестве возможной записи, а проверочная таблица может отклонить эту запись. Вы можете принять предложение системы или использовать любую другую таблицу в качестве проверочной.
На экране «Изменить внешний ключ…» у вас есть следующие опции:
Проверочная таблица: введите имя проверочной таблицы и нажмите «Создать ЗначПоУмолчанию», чтобы вывести список полей проверочной таблицы, которые можно сопоставить с таблицей внешнего ключа.
Родовой: если у вас есть несколько полей в таблице внешнего ключа, которые соответствуют ключевым полям в проверочной таблице, вы можете установить этот флажок, чтобы игнорировать проверку ввода для поля.
Константа: вы можете назначить постоянное значение для других полей, чтобы система проверяла, имеет ли поле в проверочной таблице назначенное постоянное значение для проверки ввода.
Проверка экрана: установите этот флажок, если вы хотите, чтобы система выполняла проверку ввода для поля внешнего ключа по проверочной таблице. При желании вы также можете назначить собственное сообщение об ошибке.
Семантические свойства: При желании вы можете поддерживать семантические атрибуты при создании отношения внешнего ключа. Они предназначены в первую очередь для документации.
Тип поля внешнего ключа: Дополнительно можно определить тип полей внешнего ключа, чтобы описать значение полей внешнего ключа в таблице внешнего ключа. Есть несколько вариантов:
Без ключевых полей/ -кандидатов: указывает, являются ли поля таблицы внешнего ключа неключевыми полями, которые не однозначно идентифицируют строку.
Ключевые поля/ -кандидаты: указывает, являются ли поля таблицы внешнего ключа ключевыми полями, которые однозначно идентифицируют строку.
Ключевые поля текстовой таблицы: если выбран этот параметр, таблица внешнего ключа обрабатывается как текстовая таблица проверочной таблицы. Первичный ключ таблицы внешнего ключа должен совпадать с проверочной таблицей, а также должно существовать поле ключа языка с типом LANG. Одна проверочная таблица может иметь только одну текстовую таблицу. Записи в текстовой таблице используются для помощи при вводе для полей экрана и других подобных целей.
Кардинальность: количество элементов n:m может быть определено для таблицы внешнего ключа. Кардинальность указывает, например, для каждой записи в контрольной таблице, сколько записей может существовать в таблице внешнего ключа. Используйте справку (F4) для выбора возможных вариантов. Краткий текст для каждой опции достаточно объясняет кардинальность.
Include Structure
Если вы хотите использовать поля из существующей структуры или создаете несколько таблиц с общими полями, которые должны поддерживаться централизованно, вы можете добавить поля структуры в таблицу, включив структуру.
Для включения структуры должны быть выполнены следующие требования:
-Структура, которая должна быть включена в таблицу, должна быть плоской структурой.
-Имена полей в структуре не должны быть длиннее шестнадцати символов.
-Структура не может иметь полей, которые уже существуют в таблице, потому что после включения структуры в таблицу поля структуры считаются частью таблицы.
При желании вы можете ввести имя группы и суффикс имени. Если указано имя группы, к компонентам структуры можно обращаться из программ один раз или по отдельности, используя это имя группы. Если указан суффикс имени, к полям структуры будет добавлен суффикс с введенным значением, чтобы избежать конфликтов имен с существующими полями таблицы.
Append Structure
Структуры добавления используются для расширения стандартных таблиц SAP путем добавления собственных полей. Структуры добавления специфичны для таблицы и добавляются внизу таблицы. Вы можете иметь более одной структуры добавления для таблицы, но структуру добавления одной таблицы нельзя использовать в другой таблице.
Структура добавления создается в пространстве имен клиента, чтобы ее нельзя было перезаписать при обновлении. Поля в структуре добавления также должны находиться в пространстве имен клиента и начинаться с YY или ZZ. Если новая версия стандартной таблицы импортируется после обновления, поля структуры добавления добавляются в стандартную таблицу.
Как уже отмечалось, структура добавления может быть назначена только одной таблице. Если вам нужны одинаковые поля в нескольких таблицах, вы можете создать структуру с полями и включить структуру в структуру добавления. Затем вы можете создать структуры добавления для каждой таблицы и включить структуру включения.
В таблице базы данных не может быть длинных полей (типы данных VARC, LCHR или LRAW), потому что эти длинные поля всегда должны быть в конце таблицы.
Комментарии
Отправить комментарий