история появления, эволюция и перспективы / Хабр
Привет, Хабр! Меня зовут Азат Якупов, я работаю Data Architect в компании Quadcode. Сегодня хочу поговорить о реляционных СУБД, которые играют важную роль в современном IT-мире. О том, что они собой представляют и для чего нужны, понимают, вероятно, большинство читателей.
Но вот как и почему появились реляционные СУБД? Об этом многие из нас знают лишь приблизительно. А ведь история создания технологии весьма интересна, она позволяет лучше понять основу цифрового мира. Если вам интересна эта тема — прошу под кат.
Как всё начиналось
В 60-х годах прошлого столетия появилась необходимость в надежной модели хранения и обработки данных. В первую очередь эти данные генерировались банками и финансовыми организациями. В то время не существовало единых стандартов работы с данными и моделями, да и работа как таковая заключалась в ручном упорядочении и организации хранящейся информации.
У банков худо-бедно получалось записывать информацию о транзакциях в виде файлов в заранее подготовленную структуру.
У каждой организации было собственное понимание того, как все это должно выглядеть и работать. Не было таких понятий, как консистентность (англ. data consistency), целостности данных (англ. data integrity). В файлах часто встречались дубликаты данных клиентов и их транзакций, которые необходимо было каким-то образом уточнять и приводить в порядок, делалось это в основном вручную. В целом все проблемы того времени в отношении работы с данными можно разделить на несколько основных видов:
Представление структуры в каждом файле было различным.
Необходимо было согласовывать данные в разных файлах, чтобы обеспечить непротиворечивость информации.
Сложность разработки и поддержки приложений, работающих с конкретными данными, и их обновления при изменении структуры файла.
По сути, здесь мы видим антипаттерн «чистой архитектуры», который был описан Робертом Мартином (Robert C. Martin).
Следует отметить, что были попытки создания моделей, позволяющих навести порядок в данных и их обработке.
Одна из таких попыток — иерархическая модель, в которой данные были организованы в виде древовидной структуры. Иерархическая модель была востребованной, но не гибкой. В ней каждая запись могла иметь только одного «предка», даже если отдельные записи могли иметь несколько «потомков». Из-за этого базы данных представляли только отношения «один к одному» или «один ко многим». Невозможность реализации отношения «многие ко многим» могла привести к проблемам при работе с данными и усложняла модель. Более того, вопросы консистентности данных и отсутствия дублирования информации здесь вообще не стояли. Первая иерархическая СУБД называлась IMS от IBM.
На помощь иерархической пришла сетевая модель данных, и уже новая концепция реализовала отношение «многие ко многим». Данный подход был предложен как спецификация модели CODASYL в рамках рабочей группы DBTG (Data Base Task Group).
Но всё это модели, которые сложно было поддерживать. Упростить задачу сбора и обработки данных смог Франк Кодд (Edgar F.
Codd). Его фундаментальная работа привела к появлению реляционных баз данных, которые нужны практически всем отраслям. Кодд предложил язык Alpha для управления реляционными данными. Коллеги Кодда из IBM — Дональд Чемберлен (Donald Chamberlin) и Рэймонд Бойс (Raymond Boyce) — создали один из языков под влиянием работы Кодда. Они назвали свой язык SEQUEL (Structured English Query Language), но изменили название на SQL из-за существующего товарного знака.
Появление реляционных БД и их эволюция
Активное развитие технологий БД началось примерно в 1970 году, когда Кодд опубликовал свою работу, послужившую основой для создания реляционной модели данных. Среди достоинств этой модели стоит выделить:
Отсутствие дублирования данных.
Исключение ряда ошибок и аномалий данных, которые есть в других моделях.
Все данные представлены как факты, хранящиеся в виде отношений (relations) со столбцами (attributes) и строками (tuples).
Одной из первых РСУБД можно назвать dBase-II от компании Ashton-Tate, которая выпустила свой продукт в 1979 году.
Она смогла поставить на рынок около 100 000 копий своего продукта. В итоге эта база данных стала самой популярной среди всех существовавших в то время продуктов. К слову, компанию Ashton-Tate позже приобрела фирма Borland. В целом реляционной СУБД этот продукт можно было назвать лишь с очень большой натяжкой.
Но начало было положено — и другие компании стали представлять свои продукты. Так, например, появились Oracle, Ingress и Focus.
К 1980 году сформировалось архитектурное (высокоуровневое) и инженерное (низкоуровневое) понимание того, как должна функционировать РСУБД. И пришло решение о введении стандарта (SQL Standard ISO and ANSI).
Развитие баз данных усилилось после распространения локальных сетей, а затем и сети глобальной. Сеть позволяла совместно использовать оборудование. Также пользователи хотели совместно (параллельно) работать с РСУБД, что ускорило развитие многопользовательских приложений для локальных сетей. Была создана клиент-серверная архитектура обработки данных.
С 90-х годов технология стала более дружелюбной к пользователю. По словам маркетологов, в СУБД теперь мог разобраться любой человек. Конечно, это преувеличение, но в целом направление эволюции понятно.
В это же время стали появляться первые онлайн-сервисы (например, отправка цветов, подарков, открыток, ведение блогов и т. п.). Большинство этих сервисов стали (и продолжают) работать в связке PHP + MySQL.
Распространение сотовой связи и сотовых телефонов с 1996 года привело к созданию специализированных баз данных для обработки информации в мобильном устройстве. Сейчас они эволюционировали в отдельный стек баз данных (In-Memory) и применяются либо в качестве кэша данных, находясь перед основной базой данных, либо в качестве Warm / Hot логического слоя, используясь в Lambda / Kappa архитектуре.
По моему мнению, в 2000-х произошла своеобразная эволюция, когда нереляционная модель была интегрирована в реляционную базу данных (я говорю про интеграцию XML-формата). Можно было определять модель в модели (по сути, описать любую модель можно в одном столбце таблицы).
Примерами технической реализации такого «фрактального моделирования» были Oracle Nested Tables, а также тип XML, а в последствии JSON. Такие модели назвали Post-Relational Models, и можно сказать, что начали появляться зачатки работы с noSQL-моделями формата «ключ-значение / ключ-документ».
Значение и ценность данных стал постепенно осознавать бизнес, в результате чего возросла необходимость в соответствующих специалистах. Технологии БД стали использовать далеко не только для OLTP и OLAP-трафиков, но и для глубоких исследований в данных (поиск аномалий, корреляций, использование статистического аппарата и т. д.).
С 2006 года начал работать облачный сервис Amazon AWS, по словам его представителей, сейчас он насчитывает уже свыше 20 000 частных Data Lakes, построенных внутри облака.
Ну а сейчас роль баз данных возросла еще больше. Ведь данные генерирует любое умное устройство, а их становится всё больше. Это уже не только телевизоры или смартфоны, но и зубные щетки и даже чайники (IOT-трафик, не путать с Index-Organized Tables! 😉
Правда, с увеличением объема данных стало больше и узконаправленных баз данных, которые специализируются на работе с разными типами информации и моделями.
Реляционных СУБД не так много (по сравнению с нереляционными базами данных), но архитектура каждой из них уникальна. У каждой есть свои плюсы и минусы. Также можно отметить, что в мире не существует РСУБД, которая полностью бы описывала математическую реляционную модель Франка Кодда, кроме одной с именем Rel и языком Tutorial-D. Почему это так? Неужели сложность в технической реализации реляционной теории? Нет, конечно. По моему мнению, на самом деле все проще: бизнес неявно диктует свои условия реализации хранения и обработки данных. Давайте вспомним некоторые основные свойства отношений (relations) в рамках реляционной теории и сравним их с реальной жизнью.
“All tuples are unique“. Это значит, что необходимо хранить один факт о свершившимся событии из реального мира. Данное утверждение также поддерживает определение простейшего уникального ключа для отношения, который должен включать весь набор атрибутов отношения.
2. “The order of the lines is irrelevant”.
Зачем нам вообще вводить такое понятие, как сортировка строк, а тем более по конкретным атрибутам, да еще в возрастании / убывании или на основании формулы? Хм, вообще, это требование недопустимо!
3.“The order of the columns is irrelevant”. Столбцы (attributes) мы можем переставлять как угодно, так как R(A,B,C) = R(B,C,A).
4.“Each attribute has a unique name within a table”. Каждый атрибут отношения должен иметь уникальное имя.
5.“Each column represents a single data element”. С одной стороны — вопрос нормализации. С другой — вопрос денормализации и ускорения работы модели.
6.“NULL value support”. NULL (𝒘) означает информацию, непригодную для употребления, а в действительности мы можем использовать значение NULL как статус значения в нашей модели.
Более того, каждая РСУБД по-своему интерпретирует NULL значения. Попробуйте выполнить команду ниже для PostgreSQL / MySQL:
SELECT 'Hello' || NULL || ' world!';
и команду для Oracle:
SELECT 'Hello' || NULL || ' world!' FROM dual;
Просто Oracle использует тождество NULL ~ » (пустая строка), и именно эта фича принесла немало боли во время миграций кодовой базы из Oracle в PostgreSQL (особенно если у вас на проекте витрины данных с материализациями на основании сортировок в оконных функциях и сами оконные функции, основанные на конкатенациях атрибутов).
Что дальше
Каждый виток спирали в IT-индустрии знаменуется очередным открытием модели или подходом в реализации. Так было с реляционными базами данных, затем на сцене появились объектно-ориентированные базы данных, после ворвались noSQL с лозунгом «Долой жесткие структуры отношений!». Я уверен, что эта история будет повторяться снова и снова в зависимости от вызовов, которые стоят уже сейчас и будут появляться перед IT-сообществом.
Но тем не менее сейчас следует обратить внимание на то, что в топ-5 баз данных 4 первых места занимают реляционные базы данных (по данным исследования Solid IT).
Почему это так? Как, учитывая полувековую историю, РСУБД может претендовать на такое высокое место в современном мире? Может быть, причина в legacy кода и созданных структурах моделей, которые нужно поддерживать в рамках реляционных баз данных? Или же причина в том, что переходить на более современные движки слишком дорого?
Можно вспомнить, что у реляционных баз данных есть принцип ACID и фундаментальный математический аппарат.
А у нереляционных баз данных есть BASE-семантика с более «мягкими» условиями функционирования и моделирования, а также набор алгоритмов, поддерживающих работу с данными. Семантика против Принципа, иногда хочется жить по Принципам без аномалий в данных и в режиме SERIALIZABLE.
Но все-таки истина лежит где-то посередине, и это видно в разных архитектурах проектов, когда используется «зоопарк» (в хорошем смысле слова) гетерогенных баз данных и их интеграция между собой. А особенно это прослеживается при создании общих хранилищ данных (DWH + Data Lake) в корпорациях.
Как совместить OLAP и OLTP и получить полноценные «диагональные» базы данных? Почему бы не посмотреть в сторону дедуктивных баз данных? Наконец, почему бы полноценно не привлечь весь аппарат Data Science в движки оптимизаторов и обработки информации?
Новое отдельное направление — Data Engineering дает сильный толчок в исследованиях не только данных, но и в поиске архитектуры / интеграции / валидации данных для конкретного бизнес-домена.
Появляются стандарты определения данных / информации / знаний / мудрости, что перерастает в обобщенное логическое восприятие информации через разные логические слои данных (тут я могу сослаться на книгу DAMA-DMBOK) при помощи новых инженерных ролей и разграничения ответственности в направлении Data Engineering:
Если у вас есть интересные идеи по поводу перспектив развития баз данных, моделей, стандартов и Data Engineering в целом — давайте обсудим в комментариях.
Что такое реляционная база данных
Реляционные базы данных представляют собой базы данных, которые используются для хранения и предоставления доступа к взаимосвязанным элементам информации. Реляционные базы данных основаны на реляционной модели — интуитивно понятном, наглядном табличном способе представления данных. Каждая строка, содержащая в таблице такой базы данных, представляет собой запись с уникальным идентификатором, который называют ключом. Столбцы таблицы имеют атрибуты данных, а каждая запись обычно содержит значение для каждого атрибута, что дает возможность легко устанавливать взаимосвязь между элементами данных.
Подробнее о СУБД Oracle Database
Пример реляционной базы данных
В качестве примера рассмотрим две таблицы, которые небольшое предприятие использует для обработки заказов продукции. Первая таблица содержит информацию о заказчиках: каждая запись в ней включает в себя имя и адрес заказчика, платежные данные и информацию о доставке, номер телефона и т. д. Каждый элемент информации (атрибут) помещен в отдельный столбец базы данных, которому назначен уникальный идентификатор (ключ) для каждой строки. Во второй таблице (с информацией о заказе) каждая запись содержит идентификатор заказчика, совершившего заказ, название заказанного продукта, его количество, размер или цвет и т. д. Записи в этой таблице не содержат таких данных, как имя заказчика или его контактные данные.
У обеих таблиц есть только один общий элемент — идентификатор столбца (ключ). Благодаря наличию этого общего столбца реляционные базы данных могут устанавливать взаимосвязи между двумя таблицами. Когда приложение для обработки заказов передает заказ в базу данных, база данных обращается к таблице со сведениями о заказах, извлекает сведения о продукции и использует идентификатор заказчика из этой таблицы, чтобы найти сведения об оплате и доставке в таблице с информацией о нем.
Структура реляционных баз данных
Реляционная модель подразумевает логическую структуру данных: таблицы, представления и индексы. Логическая структура отличается от физической структуры хранения. Такое разделение дает возможность администраторам управлять физической системой хранения, не меняя данных, содержащихся в логической структуре. Например, изменение имени файла базы данных не повлияет на хранящиеся в нем таблицы.
Разделение между физическим и логическим уровнем распространяется в том числе на операции, которые представляют собой четко определенные действия с данными и структурами базы данных. Логические операции дают возможность приложениям определять требования к необходимому содержанию, в то время как физические операции определяют способ доступа к данным и выполнения задачи.
Чтобы обеспечить точность и доступность данных, в реляционных базах должны соблюдаться определенные правила целостности.
Например, в правилах целостности можно запретить использование дубликатов строк в таблицах, чтобы устранить вероятность попадания неправильной информации в базу данных.
Реляционная модель
В первых базах данных данные каждого приложения хранились в отдельной уникальной структуре. Если разработчик хотел создать приложение для использования таких данных, он должен был хорошо знать конкретную структуру, чтобы найти необходимые данные. Такой метод организации был неэффективен, сложен в обслуживании и затруднял оптимизацию эффективности приложений. Реляционная модель была разработана, чтобы устранить потребность в использовании разнообразных структур данных.
Она обеспечила стандартный способ представления данных и отправки запросов, которые могли быть использованы в любых приложениях. Разработчики уяснили, что таблицы являются ключевым преимуществом реляционных баз данных, так как обеспечивают интуитивно понятный, эффективный и гибкий способ хранения структурированной информации и получения к ней доступа.
Со временем, когда разработчики стали использовать язык структурированных запросов (SQL) для записи данных в базу и отправки запросов, стало очевидным и другое преимущество реляционной модели. Вот уже на протяжении многих лет SQL широко используется в качестве языка запросов в базах данных. Он основан на алгоритмах реляционной алгебры и четкой математической структуре, что обеспечивает простоту и эффективность при оптимизации любых запросов к базе данных. Для сравнения: при использовании других подходов приходится создавать отдельные, уникальные запросы.
Преимущества системы управления реляционными базами данных
Компании всех типов и размеров используют простую, но функциональную реляционную модель для обслуживания разнообразных информационных потребностей. Реляционные базы данных применяются для отслеживания товарных запасов, обработки торговых транзакций через Интернет, управления большими объемами критически важных данных заказчиков и т. д. Реляционные базы данных можно рекомендовать для обслуживания любых информационных потребностей, где элементы данных связаны между собой и необходимо обеспечивать безопасное и надежное управление ими на основе правил целостности.
Реляционные базы данных появились в 1970-х годах. На сегодняшний день преимущества реляционного подхода сделали его самой распространенной моделью для баз данных в мире.
Реляционная модель и согласованность данных
Реляционная модель наиболее эффективно поддерживает целостность данных во всех приложениях и копиях (экземплярах) базы данных. Например, когда заказчик кладет деньги на счет с помощью банкомата, а затем проверяет баланс на мобильном телефоне, он ожидает, что поступившие средства сразу же отобразятся на счете. Реляционные базы данных отлично подходят для обеспечения целостности данных в различных экземплярах базы в одно и то же время.
Другие типы баз данных не могут одновременно поддерживать целостность больших объемов данных. Некоторые современные типы баз данных, такие как NoSQL, обеспечивают только так называемую окончательную целостность. Это значит, что, когда выполняется масштабирование данных или несколько пользователей одновременно используют одни и те же данные, необходимо некоторое время на внесение изменений.
В некоторых случаях окончательная целостность вполне приемлема (например, для обновления позиций в товарном каталоге), однако для критически важной операционной деятельности бизнеса (например, транзакций с использованием корзины) реляционные базы представляют собой фундаментальный стандарт.
Фиксация изменений и атомарность
В реляционных базах данных используются очень детальные и строгие бизнес-правила и политики в отношении фиксации изменений в базе данных (то есть сохранения изменений в данных на постоянной основе). Рассмотрим для примера складскую базу данных, в которой отслеживаются три запчасти, всегда использующиеся в комплекте. Когда одну из них извлекают из товарных запасов, две другие также должны извлекаться. Если одна из трех запчастей недоступна, две другие также не могут быть проданы отдельно, то есть, чтобы в базу данных можно было внести изменения, должны быть доступны все три запчасти. Реляционная база данных не разрешит сохранять изменения, если они не касаются всех трех запчастей.
Эту особенность реляционных баз данных называют атомарностью или неразрывностью. Неразрывность необходима для сохранения точности данных в базе и обеспечения соответствия с правилами, нормативными положениями и бизнес-политиками.
Свойства ACID и РСУБД
Транзакции реляционных баз данных определяются четырьмя основными свойствами: : атомарность, согласованность, изоляция и долговечность, которые обычно обозначаются аббревиатурой ACID.
- Неразрывность определяет все элементы, которые необходимы для совершения транзакции в базе данных.
- Согласованность или целостность определяет правила сохранения состояния данных после выполнения транзакции.
- Изолированность гарантирует, что во избежание путаницы транзакция не повлияет на другие элементы до окончательного сохранения изменений.
- Неизменность обеспечивает неизменность данных после сохранения изменений в результате транзакции.
Хранимые процедуры и реляционные базы данных
Доступ к данным включает в себя множество повторяющихся действий.
Блокировки базы данных и параллельный доступ
Когда несколько пользователей или приложений пытаются одновременно изменить одни и те же данные, это может вести к возникновению конфликта в базе.
Блокировка не разрешает другим пользователям и приложениям получать доступ к данным во время их обновления. В некоторых базах данных блокировка может применяться к целой таблице, что негативно отражается на эффективности приложения. В других типах баз данных, например реляционных базах Oracle, блокировка выполняется на уровне одной записи, оставляя другие записи в таблице доступными. Такой подход помогает сохранить эффективность приложения.
Инструмент параллельного доступа используется, когда несколько пользователей или приложений пытаются одновременно выполнить запросы к одной базе данных. Он обеспечивает доступ пользователей и приложений к базе данных в соответствии с политиками контроля.
Характеристики, на которые следует обратить внимание при выборе реляционной базы данных
Программное обеспечение, которое используется для сохранения, контроля и извлечения данных в базе, а также выполнения к ней запросов, называют системой управления реляционной базой данных (РСУБД).
При выборе типа базы данных и продуктов на основе реляционных баз данных необходимо учитывать несколько факторов. Выбор РСУБД зависит от потребностей Вашей компании. Задайте себе следующие вопросы.
- Каковы наши требования к точности данных? Будем ли мы использовать бизнес-логику для хранения и обеспечения точности данных? Предъявляются ли к нашим данным более строгие требования в отношении точности (например, если Вы работаете с финансовыми данными и отчетностью)?
- Нужна ли нам масштабируемость? Какими объемами данных требуется управлять и каков прогнозируемый рост этих объемов? Должна ли модель базы данных поддерживать зеркальные копии (как отдельные экземпляры) в целях масштабирования? Если да, сможем ли мы обеспечивать целостность данных в этих экземплярах?
- Насколько важно наличие параллельного доступа? Потребуется ли пользователям и приложениям одновременный доступ к данным? Поддерживает ли ПО базы данных параллельный доступ без ущерба для безопасности?
- Каковы наши потребности в эффективности и надежности баз данных? Требуется ли нам высокоэффективная и надежная система? Каковы требования к скорости выполнения запросов? Какие гарантии дает поставщик услуг в соответствии с соглашением об уровне обслуживания (SLA) или на случай незапланированного простоя?
Реляционная база данных будущего: автономная база данных
На протяжении лет реляционные базы данных улучшали производительность, надежность и безопасность и становились проще в обслуживании.
Однако их структура становилась все более сложной, и, как следствие, администрирование такой базы данных начало требовать немалых усилий. Вместо того чтобы использовать свои навыки для разработки инновационных приложений, которые будут приносить прибыль организации, разработчики вынуждены посвящать львиную долю времени на управление базой данных для оптимизации ее эффективности.
Сегодня автономные технологии используются, чтобы расширить возможности реляционной модели, технологии облачных баз данных и машинного обучения и создать реляционную базу данных нового типа. Самоуправляемая база данных (которую также называют автономной) сохраняет все преимущества и возможности реляционной модели и добавляет к ним средства на основе искусственного интеллекта, машинного обучения и автоматизации для мониторинга и оптимизации скорости выполнения запросов и управления. Например, чтобы улучшить скорость выполнения запросов, самоуправляемая база данных строит прогнозы и проверяет индексы, а затем применяет лучшие результаты на практике — и все это без участия администратора.
Самоуправляемые базы данных постоянно вносят такие улучшения в собственную работу без человеческого вмешательства.
Автономные технологии дают возможность разработчикам больше не тратить время на рутинные задачи обслуживания. Например, больше не нужно заблаговременно определять требования к инфраструктуре. При использовании самоуправляемой базы данных можно расширять системы хранения и добавлять вычислительные ресурсы по мере возникновения необходимости в них. Разработчики могут создавать автономные реляционные базы данных всего за несколько шагов, ускоряя процесс разработки приложений.
Подробнее о СУБД Oracle Database
Т852У — Субгруппа компаний | LeanX
- Главная
- Ресурсы
- Таблицы SAP
- T852U — Субгруппа компаний
T852U (Подгруппа компаний) — стандартная таблица в системах SAP R\3 ERP. Ниже вы можете найти технические детали полей, которые составляют эту таблицу. Ключевые поля отмечены синим цветом.
Кроме того, мы предоставляем обзор отношений внешнего ключа, если таковые имеются, которые связывают T852U с другими таблицами SAP.
Поля таблицы T852U
| Поле | Элемент данных | Контрольная таблица | Тип данных | Длина | Десятичные числа | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| МАНДТ | Клиент | МАНДТ | Т000 | CLNT | 3 | 0 | ||||||||||
| РВЕРС | Версия для изменений вложений | RVERS_I | СИМВОЛ | 3 | 0 | |||||||||||
| ГОЛУБОЙ | финансовый год | РЖИ | НУМК | 4 | 0 | |||||||||||
| РСУБД | Подгруппа | руб. | Т852 | СИМВОЛ | 3 | 0 | ||||||||||
| РКОМП | Компания, входящая в подгруппу | RCOMP_SUBD | Т880 | СИМВОЛ | 6 | 0 | ||||||||||
| ПЕРИД | Период | ПЕРИОД | НУМК | 3 | 0 | |||||||||||
| ПРОЦЕНТ | Доля группы | КОНЗПРЗ | ДЕКАБРЬ | 7 | 4 | |||||||||||
| ПКНТ1 | Доля группы | GRP_PCNT1 | ДЕКАБРЬ | 11 | 8 | |||||||||||
| ПКНТ2 | Доля группы с правом голоса | GRP_PCNT2 | ДЕКАБРЬ | 11 | 8 | |||||||||||
| ПКНТ3 | Акция группы без права голоса | GRP_PCNT3 | ДЕКАБРЬ | 11 | 8 | |||||||||||
| ПКНТ4 | Доля Группы сохранена | GRP_PCNT4 | ДЕКАБРЬ | 11 | 8 | |||||||||||
| ПКНТД | Прямые акции других компаний | ПКНТД | ДЕКАБРЬ | 11 | 8 | |||||||||||
| КЗНЭ | Индикатор: Исключить компанию | ФК_НЕ | СИМВОЛ | 1 | 0 | Возможные значения
| ||||||||||
| РЭАСН | Причина включения/исключения из консолидации | REASN_EXP | Т855 | СИМВОЛ | 1 | 0 | ||||||||||
| ТИППП | Тип компании: Посмотреть материнскую компанию. | ТИПП | СИМВОЛ | 1 | 0 | Возможные значения
| ||||||||||
| ТИПГ | Тип компании: Просмотр подгруппы | ТИПГ | СИМВОЛ | 1 | 0 | Возможные значения
| ||||||||||
Отношения внешнего ключа T852U
| Таблица | Поле | Таблица внешних ключей | Поле внешнего ключа | Контрольный стол | Проверить поле | |
|---|---|---|---|---|---|---|
| Т852У | МАНДТ | Т852У | МАНДТ | Т000 | клиентов | МАНДТ |
| Т852У | РКОМП | Т852У | МАНДТ | Т880 | Глобальные данные компании (для KONS Ledger) | МАНДТ |
| Т852У | РКОМП | Т852У | РКОМП | Т880 | Глобальные данные компании (для KONS Ledger) | РКОМП |
| Т852У | РЕАСН | Т852У | МАНДТ | Т855 | Основания для включения в консолидацию | МАНДТ |
| Т852У | РЕАСН | Т852У | РЕАСН | Т855 | Основания для включения в консолидацию | РЕАСН |
| Т852У | руб. | Т852У | МАНДТ | Т852 | Подгруппы | МАНДТ |
| Т852У | руб. | Т852У | руб. | Т852 | Подгруппы | руб. |
RF10S — Поля справки для экранов SAPMF10S
- Главная
- Ресурсы
- Таблицы SAP
- RF10S — Поля справки для экранов SAPMF10S
RF10S (Поля справки для экранов SAPMF10S) — это стандартная таблица в системах SAP R\3 ERP. Ниже вы можете найти технические детали полей, которые составляют эту таблицу. Ключевые поля отмечены синим цветом.
Кроме того, мы предоставляем обзор отношений внешнего ключа, если таковые имеются, которые связывают RF10S с другими таблицами SAP.
Поля таблицы RF10S
| Поле | Элемент данных | Контрольная таблица | Тип данных | Длина | Десятичные числа | |||
|---|---|---|---|---|---|---|---|---|
| ГОЛУБОЙ | финансовый год | РЖИ | НУМК | 4 | 0 | |||
| РСУБД | Подгруппа | руб. | Т852 | СИМВОЛ | 3 | 0 | ||
| ПЕРИД | Период | ПЕРИОД | НУМК | 3 | 0 | |||
| РВЕРС | Версия консолидации | RVERS_GC | Т858 | СИМВОЛ | 3 | 0 | ||
| НОМЕР | Ссылка на подгруппу | RSUBD_REF | Т852 | СИМВОЛ | 3 | 0 | ||
| ВОНГ | «От» компания | RCOMP_FROM | Т880 | СИМВОЛ | 6 | 0 | ||
| БИСГС | Компания «К» | RCOMP_TO | Т880 | СИМВОЛ | 6 | 0 | ||
| CNTRY | Ключ страны | ЦЕНТРАЛЬНЫЙ | Т005 | СИМВОЛ | 3 | 0 | ||
| РЕФВЕРСЫ | Ссылка на версию | RVERS_REF | СИМВОЛ | 3 | 0 | |||
| WK_REF | Справочное поле для шаблонов | WF_REF | СИМВОЛ | 79 | 0 | |||
| CTYPPTXT | Пояснительный краткий текст | ДДТЕКСТ | СИМВОЛ | 60 | 0 | |||
| CTYPGTXT | Пояснительный краткий текст | ДДТЕКСТ | СИМВОЛ | 60 | 0 | |||
| ТХТ001 | Пояснительный краткий текст | ДДТЕКСТ | СИМВОЛ | 60 | 0 | |||
| ТХТ002 | Пояснительный краткий текст | ДДТЕКСТ | СИМВОЛ | 60 | 0 | |||
| ТХТ003 | Пояснительный краткий текст | ДДТЕКСТ | СИМВОЛ | 60 | 0 | |||
| ТХТ004 | Пояснительный краткий текст | ДДТЕКСТ | СИМВОЛ | 60 | 0 | |||
Отношения внешнего ключа RF10S
| Таблица | Поле | Таблица внешних ключей | Поле внешнего ключа | Контрольный стол | Проверить поле | |
|---|---|---|---|---|---|---|
| РФ10С | БИСГС | СИСТЕМА | МАНДТ | Т880 | Глобальные данные компании (для KONS Ledger) | МАНДТ |
| РФ10С | БИСГС | РФ10С | БИСГС | Т880 | Глобальные данные компании (для KONS Ledger) | РКОМП |
| РФ10С | ЦЕНТРАЛЬНЫЙ | СИСТЕМА | МАНДТ | Т005 | стран | МАНДТ |
| РФ10С | ЦЕНТРАЛЬНЫЙ | РФ10С | ЦЕНТРАЛЬНЫЙ | Т005 | стран | ЗЕМЛЯ1 |
| РФ10С | ССЫЛКИ | СИСТЕМА | МАНДТ | Т852 | Подгруппы | МАНДТ |
| РФ10С | ССЫЛКИ | РФ10С | ССЫЛКИ | Т852 | Подгруппы | руб. |
