Этим система «1С:Предприятие 8» выгодно отличается от универсальных инструментальных средств. Обычно, при создании бизнес-приложений с использованием универсальных сред разработки, используются отдельно поставляемые системы управления базами данных. А это значит, что разработчику приходится постоянно заботиться о преобразованиях между типами данных, поддерживаемыми той или иной системы управления базами данных, и типами, поддерживаемыми языком программирования.

Хранение ссылок на объекты

При манипулировании данными, хранящимися в базе данных «1С:Предприятия 8», зачастую используется объектный подход. Это значит, что обращение (чтение и запись) к некоторой совокупности данных, хранящихся в базе, происходит как к единому целому. Например, используя объектную технику, можно манипулировать данными справочников, документов, планов видов характеристик, планов счетов и т.д.

Характерной особенностью объектного манипулирования данными является то, что на каждый объект, как совокупность данных, существует уникальная ссылка, позволяющая однозначно идентифицировать этот объект в базе данных.

Эта ссылка также хранится в поле базы данных, вместе с остальными данными объекта. Кроме того, ссылка может быть использована как значение какого-либо поля другого объекта. Например, ссылка на объект справочника Контрагенты может быть использована как значение соответствующего реквизита документа Приходная накладная.

Составные типы

Существенной возможностью модели данных, которая поддерживается «1С:Предприятием 8», является то, что для поля базы данных можно определить сразу несколько типов данных, значения которых могут храниться в этом поле. При этом значение в каждый момент времени будет храниться одно, но оно может быть разных типов — как ссылочных, так и примитивных — число, строка, дата и т.п.:

Такая возможность очень важна для экономических задач — например, в расходной накладной в качестве покупателя может быть указано либо юридическое лицо из справочника организаций, либо физическое лицо из справочника частных лиц. Соответственно, при проектировании базы данных разработчик может определить поле, которое будет хранить значение любого из этих типов.

Хранение любых данных как Хранилище значения

Идеология создания прикладных решений в «1С:Предприятии 8» предполагает, что все файлы, имеющие отношение к данному прикладному решению, нужно хранить в самой базе данных.

Для этого введен специальный тип данных — ХранилищеЗначения. Поля базы данных могут хранить значения такого типа, а встроенный язык содержит специальный одноименный объект, позволяющий преобразовывать значения других типов к специальному формату Хранилища значений.

Благодаря этому разработчик имеет возможность сохранять в базе данных значения, тип которых не может быть выбран в качестве типа поля базы данных, например, графические изображения.

Создание и обновление структур данных на основе метаданных

В процессе создания или модификации прикладного решения разработчик избавлен от необходимости каких-либо действий по непосредственному изменению структуры полей базы данных прикладного решения.

Разработчику достаточно путем визуального конструирования описать структуру используемых объектов прикладного решения, состав их реквизитов, табличных частей, форм и пр.

Все действия по созданию или изменению структуры таблиц базы данных платформа выполнит самостоятельно, на основании состава объектов прикладного решения и их характеристик.

Например, для того, чтобы в справочнике сотрудников появилась возможность хранить сведения о составе семьи сотрудника, разработчику «1С:Предприятия 8» не нужно создавать в базе данных специальную новую таблицу, задавать правила, по которым данные, хранящиеся в этой таблице, будут связаны с данными из основной таблицы, программировать алгоритмы совместного доступа к данным этих таблиц, создавать алгоритмы проверки прав доступа к данным, находящимся в подчиненной таблице и пр.

Все, что требуется сделать разработчику — щелчком мыши добавить к справочнику табличную часть и задать два ее строковых реквизита: Имя и Родство. При сохранении или обновлении конфигурации платформа самостоятельно выполнит реорганизацию структуры базы данных, создаст необходимые таблицы и т.д.

Объектный / табличный доступ к данным

Штатной возможностью «1С:Предприятия 8» является поддержка двух способов доступа к данным — объектного (для чтения и записи) и табличного (для чтения).

В объектной модели разработчик оперирует объектами встроенного языка. В этой модели обращения к объекту, например документу, происходят как к единому целому — он полностью загружается в память, вместе с вложенными таблицами, к которым можно обращаться средствами встроенного языка как к коллекциям записей и т.д.

При манипулировании данными в объектной модели обеспечивается сохранение целостности объектов, кэширование объектов, вызов соответствующих обработчиков событий и т.д.

В табличной модели все множество объектов того или иного класса представляется как совокупность связанных между собой таблиц, к которым можно обращаться при помощи запросов — как к отдельной таблице, так и к нескольким таблицам во взаимосвязи:

В этом случае разработчик получает доступ к данным сразу нескольких объектов, что очень удобно для анализа больших объемов данных, например, при создании отчетов. Однако в силу того, что данные, выбираемые таким способом, содержат не все, а лишь некоторые реквизиты анализируемых объектов, табличный способ доступа не позволяет изменять эти данные.

база данных | Community Creatio

Приветствую, уважаемые коллеги!

В данной статье я хочу привлечь внимание не только разработчиков, но и партнёров Террасофт и их представителей.

Сегодня я расскажу Вам о преимуществах и выгодах использования приложения для оперативной проверки структуры базы данных (далее — БД) на корректность (https://marketplace.terrasoft.ru/app/database-structure-check).

Проблематика.

После накатывания нового функционала на тестовую среду могут появиться ошибки структуры БД. Их особенности:

• не всегда очевидны.
• разработчиков может сбивать с толку тот факт, что на рабочей среде всё работает, а на тестовой – нет.
• поиск и устранение может занять длительное время.

Всё это снижает эффективность разработки/обслуживания, приводит к дополнительным расходам ресурсов. 

После накатывания на промышленную среду могут также появиться ошибки. Они имеют ту же природу, но масштаб их разрушительного действия уже выше, т.к. это промышленная среда, соответственно, плюс к проблемам выше:

• падает надёжность системы.
• повышается вероятность аварии.

Особенно это актуально, когда «окно» для обновления промышленной среды очень небольшое. Чем больше проект в плане доработок, тем больше ошибок структуры БД может возникать.

При использовании приложения все эти проблемы можно успешно решить!

Целевая аудитория.

Обращаю внимание партнёров Terrasoft: приложение предназначено для среднего и крупного бизнеса. То есть, основные преимущества от его использования получает именно клиент. Приложение универсально и подойдёт практически всем клиентам, у которых есть потребность в доработке базовых продуктов.

Степень необходимости приложения может варьироваться. Если в ходе выяснения потребностей выясняется, что:

1. будет большой проект (или уже есть) со сложными связями между сущностями системы.
2. есть потребность в максимальной надёжности.
3. у клиента только небольшие «окна» для обновления промышленной среды.
4. есть потребность в повышении эффективности разработки и обслуживания (клиент хочет как можно скорее получить готовую систему в пользование).
5. есть потребность в повышении устойчивости к авариям системы.

— это всё покажет рост степени необходимости приложения. Я настоятельно рекомендую устанавливать приложение всем клиентам в случае, если имеет место хотя бы один пункт выше.

Выгоды.

Какие выгоды получит клиент от использования приложения? Как правило, это выгоды в долгосрочной перспективе. Клиент:

1. получит дополнительную меру повышения надёжности системы.
2. сэкономит ресурсы на обнаружение ошибок структуры БД.
3. обеспечит повышение эффективности разработки и обслуживания системы.
4. обеспечит повышение устойчивости системы к авариям из-за ошибок структуры БД.

Есть также выгоды для разработчиков, облегчающие некоторые аспекты разработки/сопровождения. Разработчики: 

1. смогут пользоваться самым рациональным решением для проверок структуры БД, которое не имеет аналогов.
2. смогут пользоваться всем функционалом приложения в один клик.
3. смогут проверять структуру БД на корректность в течение нескольких секунд.
4. смогут оперативно выявлять отсутствующие таблицы и/или их колонки, обнаруживать несоответствия типов полей.
5. после проверки структуры БД смогут понять, для каких объектов необходимо произвести повторное обновление структуры БД.
6. после успешного анализа, будут точно знать, что БД целевой среды содержит все требуемые системой таблицы/поля, и что типы всех полей всех таблиц правильные.

Преимущества.

1. Поиск ошибок структуры БД. Приложение выявляет отсутствующие таблицы и/или их колонки, а также обнаруживает несоответствия типов полей.
2. Повышение надёжности. Использование приложения повышает надёжность системы за счёт минимизации времени, в течение которого в структуре БД есть ошибки.
3. Экономия ресурсов. Использование дополнения сокращает расходы на обнаружение ошибок структуры БД. В ряде случаев очень серьёзно сокращает расходы.
4. Подтверждение целостности. После успешного анализа, специалист будет точно знать, что база данных целевой среды содержит все требуемые системой таблицы/поля, и что типы всех полей всех таблиц соответствуют требуемым типам.
5. Повышение эффективности разработки и обслуживания. Это происходит за счёт экономии ресурсов при использовании приложения, а также за счёт ускорения обнаружения ошибок структуры БД.
6. Простота использования. Запуск функционала в один клик.
7. Быстрая скорость работы. Проверка структуры БД в течении нескольких секунд.
8. Простая и удобная форма отчёта приложения. После проверки, в случае наличия ошибок, специалисту будет предоставлено подробное информационное сообщение. Разработчик сразу поймёт, для каких объектов необходимо произвести повторное обновление структуры БД.
9. Локализация на английский язык. Поддержка не только русского языка, но и английского.
10. Самое рациональное решение для проверок структуры БД. На самом деле, можно проверить вручную, но это дольше (просмотреть все разделы, вкладки, детали, а также проверить работоспособность всего разработанного функционала) и не всегда возможно проверить вообще всё. Зачастую такого количества времени просто нет. 
11. Уникальность. Инструмент для проверки структуры БД не имеет аналогов на маркетплейс.
12. Смешная цена. За год использования, то есть возможно продление на следующий год. Продлевать нет смысла только если разработка/обслуживание полностью завершены. Экспертные продажи.
13. Повышение устойчивости системы к авариям, вызванным ошибками структуры БД. Использование приложения позволяет обнаружить ошибки БД сразу же после обновления целевой среды, после чего сразу предпринять действия для исправления найденных ошибок.

Совместимость.

Приложение совместимо со всеми продуктами на платформе bpm’online (с версии 7.11, на остальных нужно тестировать, но скорее всего работать будет).
В данный момент не поддерживается работа на системах, для которых используется СУБД Oracle.

Большое спасибо всем, кто дочитал до конца!

Буду рад любым предложениям по совершенствованию продукта!

С уважением, Сергей Кузнецов.

Тест по теме бд с ответом

Логические поля в базах данных, есть ли противоядие / Хабр

Часто в таблицах содержится большое количество логических полей, проиндексировать все из них нет возможности, да и эффективность такой индексации низка. Тем не менее, для работы с произвольными логическими выражениями в SQL пригоден механизм многомерной индексации о чем и пойдёт речь под катом.

В SQL логические поля используются в основном в двух случаях. Во-первых, когда действительно нужен бинарный атрибут, например, ‘купля/продажа’ в таблице сделок. Такие атрибуты редко меняются со временем.

Во-вторых, для записи состояния конечного автомата, которым описывается запись. Имеется в виду, что логический объект, соответствующий записи таблицы, проходит ряд состояний, число которых и переходы между которыми определяются прикладной логикой. Простой пример — техника “soft-delete”, когда запись физически не уничтожается, а только помечается как удалённая.

Если автомат сложный, таких полей может быть изрядное количество, в одной из наших таблиц 58 (+14 устаревших) таких полей (включая наборы флагов) и это не что-то из ряда вон выходящее. Так не было задумано изначально, но по мере развития продукта и изменения внешних требований развиваются и соответствующие автоматы, приходят и уходят разработчики, меняются аналитики… в какой-то момент может оказаться безопаснее завести новый флаг, нежели разбираться во всех хитросплетениях. Тем более что накопились исторические данные и их состояния обязаны оставаться адекватными.

Чем-то это похоже на эволюционный процесс, когда в геноме хранится масса информации/механизмов, которые на первый взгляд и не нужны вовсе, но избавиться от них невозможно. С другой стороны, стоит относиться с уважением к этим механизмам, ведь именно они позволили эволюционным предшественникам выжить (в том числе во время

) и победить в эволюционной гонке. Опять же, кто знает, куда заведет нас эволюция и что окажется полезным в дальнейшем.

Завести флаг означает не только добавить поле соответствующего типа, но и учесть его в работе автомата, какие состояния оно затрагивает, в каких переходах участвует. На практике это выглядит так:

• процесс или ряд процессов, назовём их “писателями”, создают новые записи в начальном состоянии (возможно, в одном из начальных состояний)
• ряд процессов, назовём их “читателями”, время от времени читают объекты, находящиеся в нужных им состояниях
• ряд процессов, назовём их “обработчиками”, следят за конкретными состояниями и исходя из прикладной логики меняют эти состояния. Т.е. осуществляют деятельность конечного автомата.

Для того чтобы выбрать записи, находящиеся в конкретном состоянии, редко когда достаточно фильтрации по одному из булевых полей. Обычно это целое выражение, иногда нетривиальное. Казалось бы, надо проиндексировать эти поля и SQL-процессор сам разберётся. Но не всё так просто.

Во первых, булевых полей может быть много, индексировать их все было бы слишком расточительно.

Во вторых, это может оказаться бесполезным т.к. селективность по каждому из полей будет низкой, а совместная вероятность статистикой SQL-процессора не покрывается.

Пусть, в таблице T1 есть два булевых поля: F1 & F2, а запрос

select F1, F2, count(1) from T1 group by F1, F2

выдаёт

Т.е. хотя, по F1 & F2 выпадение true и false равновероятно, сочетание (true,false) выпадает только один раз из тысячи. В результате, если раздельно проиндексировать F1 & F2

, SQL-процессору пришлось бы прочитать по половине обоих индексов и пересечь результаты. Возможно, дешевле прочитать всю таблицу и вычислить выражение для каждой строчки.

И даже если собирать статистику по исполненным запросам, толку от нее будет мало т.к. статистика конкретно по полям, отвечающим за состояние автомата очень сильно плавает. Ведь в любой момент может прийти “обработчик” и половину строк из состояния S1 перевести в S2.

Для работы с такими выражениями напрашивается многомерный индекс, алгоритм которого был представлен ранее и неплохо себя зарекомендовал.

Но прежде требуется разобраться каким образом произвольное логическое выражение превратится в запрос(ы) к индексу.

Дизъюнктивная нормальная форма

Единичный запрос к многомерному индексу представляет собой многомерный прямоугольник, ограничивающий пространство запроса. Если поле участвует в запросе, для него задаётся ограничение. Если нет, прямоугольник по этой координате ограничен только разрядностью данной координаты. Логические координаты имеют разрядность 1.

Поисковый запрос в таком индексе является цепочкой из & (конъюнкцией), например, выражение: v1 & v2 & v3 & (!v4), эквивалентно v1:[1,1], v2:[1,1], v3:[1,1], v4:[0,0]. А все остальные поля имеют диапазон: [0,1].

Учитывая это, наш взор сразу обращается в сторону ДНФ — одной из канонических форм логических выражений. Утверждается, что любое выражение может быть представлено к виду дизъюнкции конъюнкций литералов. Под литералом здесь понимается логическое поле или его отрицание.

Иными словами, путём нехитрых манипуляций, любое логическое выражение может быть представлено в виде дизъюнкции нескольких запросов к многомерному логическому индексу.

Есть и одно НО. Такое преобразование в некоторых случаях может привести к экспоненциальному росту размера выражения. Например, преобразование из

приводит к выражению размером в 2**n термов. В таких случаях прикладному разработчику стоит задуматься о физическом смысле того, что он делает, а со стороны SQL процессора всегда можно отказаться от использования логического индекса, если число конъюнкций превышает пределы разумного.

Алгоритм многомерной индексации

Для многомерной индексации используются свойства самоподобной нумерующей кривой на основе гипер-кубических симплексов со стороной 2. Как

, практическое значение имеют два варианта таких кривых — Z-кривая и кривая Гильберта.

Фиг.1 двумерная Z-кривая, 3 и 6 итерации

Фиг.2 двумерная кривая Гильберта, 3 и 6 итерации

• N-мерный симплекс со стороной 2 имеет 2**n вершин и (2**n-1) переходов между ними.
• Элементарная итерация симплекса превращает каждую вершину симплекса в симплекс нижнего уровня.
• Проделав нужное число итераций, можно построить гипер-кубическую решетку любого размера.
• При этом каждый узел этой решетки будет иметь свой уникальный номер — путь, проделанный по нумерующей кривой от ее начала. При этом каждый узел этой решетки имеет значение по каждой из координат. Фактически, нумерующая кривая переводит многомерную точку в одномерное значение, пригодное для индексации обычным B-деревом.
• Все узлы, находящиеся внутри симплекса любого уровня, находятся в пределах одного интервала и этот интервал не пересекается ни с одним симплексом того же уровня.
• Следовательно, любой поисковый прямоугольник (параллелепипед) может быть разбит на небольшое число гипер-кубических подзапросов, в пределах каждого из которых индекс может быть прочитан одним поиском/траверзом.
  
• К этому добавим магию низкоуровневой работы с B-деревом для того, чтобы не делать бесполезные запросы и … алгоритм готов.

Вот как это работает на практике:

Фиг.3 Пример поиска в двумерном индексе (Z-кривая)

На фиг.3 показано разбиение исходного поискового экстента на подзапросы и найденные при этом точки. Использовался двумерный индекс, построенный на случайном равномерно распределенном наборе 100 000 000 точек в экстенте [1 000 000, 1 000 000].

Логический многомерный индекс

Раз уж речь зашла о многомерном индексировании, самое время задуматься, а насколько многомерным он может быть? Есть ли какие-то объективные ограничения?

Конечно, ведь B-дерево имеет страничную организацию и для того, чтобы быть деревом, на странице должно гарантированно помещаться не менее двух элементов. Если принять страницу за 8К, значит на хранение одного элемента не может уходить больше 4К. В 4К без сжатия влезает около 1000 32-разрядных значений. Это довольно много, выше пределов любого разумного применения, можно сказать, что физические пределы практически не доступны.

Есть и другая сторона, каждое дополнительное измерение отнюдь не бесплатно, на него уходит дисковое пространство и замедляется работа. С точки зрения “физического смысла”, в один индекс должны попадать поля, которые меняются одновременно и поиск по ним тоже идёт совместно. Никакого смысла индексировать всё подряд нет.

С логическими полями всё по другому. Как мы видели, в одних и тех же механизмах могут быть задействованы десятки логических полей. А затраты на хранение/чтение довольно малы. Есть соблазн собрать всё без исключения логические поля в одном индексе и посмотреть что получится.

Правда, есть нюансы:

• До сих пор в индексируемом значении разряды разных координат перемешивались, в младших разрядах ключа оказывались младшие разряды координат … Поэтому порядок следования полей при индексации не имел значения.
• Теперь же на хранение значения одного логического поля тратится один разряд. Т.е. какие-то логические поля попадут в конец ключа, а какие-то в начало. А это означает, что фильтрация по части полей будет проходить очень эффективно, а по некоторым очень неэффективно. В самом деле, если мы делаем поиск по самому младшему разряду, придётся прочитать весь индекс чтобы получить ответ. Но это (скорее всего) лучше, чем прочитать всю таблицу, чтобы ответить на тот же вопрос.
• Возникает проблема выбора — все логические поля равны, но некоторые окажутся равнее прочих. Из общих соображений, необходимо смотреть на перекосы статистики, чем сильнее соотношение true/false для конкретного поля отстоит от равновесного, тем старше должен быть разряд, в котором окажется его значение.
• Исчезает разбиение по типу нумерующей кривой, если раньше приходилось выбирать между Z-кривой и кривой Гильберта, на одноразрядных данных практической разницы нет.
• NULL-ы. Если исходить из того, что NULL — это не неизвестное значение, а отсутствие какого бы то ни было значения, то такие записи не должны попадать в индекс. В одномерных индексах так и происходит. Но в нашем случае может оказаться, что часть логических полей содержит значения, а часть нет. В результате мы не можем положить это в индекс т.к. алгоритм поиска не умеет работать с троичной логикой. А следовательно, такие записи должно быть невозможно вставить в таблицу (при наличии многомерного индекса, необязательно логического, кстати)

Ожидается, что логический многомерный индекс может в некоторых случаях работать не слишком эффективно. Строго говоря, любой индекс может работать неэффективно, если слишком большое количество данных попадает в область поиска. Но для логического многомерного индекса это усугубляется описанной выше зависимостью от порядка полей, когда ради небольшого результата придётся прочитать весь индекс. Насколько это является проблемой на практике, может показать только эксперимент.

Численный эксперимент

Построение индекса:

• индекс будет 128-разрядным, т.е. построен по 128 логическим полям
• и будет содержать 2**30 элементов
• значением элемента индекса будет число от 0 до 2**30
• ключом элемента индекса будет то же число, сдвинутое на 48 разрядов влево, т.е. логические поля с 48 по 78 будут заполнены разрядами числа в том же порядке
• в результате получим 30 значимых логических полей в середине ключа, остальные разряды будут заполнены 0
  
• Каждое из логических полей имеет равную статистику true/false
• Все они статистически независимы

Поиск:

• Каждому эксперименту соответствует выбор нескольких подряд идущих логических полей и задание для них поисковых значений. Не потому, что алгоритм умеет искать только полосами, а из-за того, что так можно нагляднее представить результаты эксперимента, имеем всего две размерности — ширина полосы и её положение
• Всего 24 серии экспериментов. В каждой серии будем искать такие значения, где полоса логических полей соответствующей ширины N (от 1 до 24 разрядов) принимает значение true.
• В каждой серии будет подсерия экспериментов, в которой полоса логических полей выбранной ширины располагается с различными сдвигами S от начала полосы в 30 значимых логических полей. Всего (30-N) экспериментов в подсерии.
• В каждом эксперименте делается поиск всех элементов индекса, удовлетворяющих условию, т.е. поля с номерами в интервале [48 + S, 48 + S + N -1] будем искать в интервале [1,1], остальные — в интервале [0,1]
  
• Поиск делается с холодного старта
• Результатом является число прочитанных дисковых страниц, с учетом кэширования (кэш на 4096 страниц)
• Контроль правильности работы делается двумя путями — число найденных элементов должно быть равно 2**(30-N) и в найденных значениях можно проверить соответствующие разряды
  

Итак,

Фиг.4 Результаты, число прочитанных страниц в разных сериях

По Y — отложены количества прочитанных страниц.
По X — сдвиг полос от самого младшего (48) разряда к старшему. Полосы разной ширины подписаны и отмечены разными цветами.

Фиг.5 Те же данные что и Фиг.4, другое представление

По X — сдвиг полосы
По Y — ширина полосы

Что следует отметить:

• хотя на картинках это прямо не видно, индекс работает правильно, это видно и по числу найденных элементов и по содержанию самих элементов
• все полосы шириной не больше 10 со сдвигом 0 требуют сплошного чтения индекса
• полосы шириной от 1 до 18 с ростом сдвига выходят на асимптоту 2**(-N) от размера всего индекса, что логично
• для более широких полос асимптота — высота дерева, меньше неё чтений быть не может
• на листовой странице индекса помещается чуть больше 1000 элементов, это видно по полосе шириной 10, которая при сдвиге 0 уже не требует чтения всего индекса, некоторые страницы удаётся пропускать
• низкоуровневая фильтрация работает на удивление хорошо. Рассмотрим полосу шириной 10. Идеальный для поиска вариант — со сдвигом 20 (всего 30 значимых полей), когда в префиксе вообще нет неопределенных полей, данные можно найти единственным траверзом. В этой ситуации при поиске читается примерно 1/1000 индекса — 779 страниц.
  Промежуточный случай — сдвиг 10, у нас префикс и суффикс в 10 неизвестных полей. Число страниц — 2484, всего втрое хуже, чем в идеальном случае.
  И даже в худшем случае со сдвигом в 0 (префикс в 20 неизвестных полей) удаётся пропускать какие-то страницы.

В целом можно признать алгоритм многомерной индексации работоспособным даже в таком доведенном до абсурда случае.

Эксперимент на реальных данных

Таблица

, всего 278 479 918 строк, данные одного из тестовых контуров.

Результаты выполнения некоторых запросов в таблице ниже:

На чтение/обработку одной страницы в среднем уходит 0.8 мсек.

Нет необходимости описывать смысл конкретных запросов, они здесь просто для демонстрации работоспособности. Которая, кстати, подтверждена.

Но прежде чем данная техника сможет принести практическую пользу, предстоит еще очень много сделать. Так что, продолжение следует.

Введение в типы данных и свойства полей

Определяет способ отображения поля при его отображении или печати в таблицах данных, а также в формах или отчетах, привязанных к полю. Вы можете использовать предопределенный формат или создать свой собственный формат.

Список предустановленных форматов

• Общая дата По умолчанию, если значение представляет собой только дату, время не отображается; если значение — только время, дата не отображается.Этот параметр представляет собой комбинацию параметров короткой даты и длительного времени.

  Примеры

  • 03.04.07

  • 17:34:00

  • 03.04.07 17:34:00

• Long Date То же, что и настройка Long Date в региональных настройках Windows.Пример: суббота, 3 апреля 2007 г.

• Средняя дата Дата отображается в формате дд-ммм-гггг. Пример: 3 апреля 2007 г.

• Short Date То же, что и настройка Short Date в региональных настройках Windows. Пример: 03.04.07.

  Предупреждение: Параметр «Краткая дата» предполагает, что даты между 01.01.00 и 31.12.29 являются датами двадцать первого века (то есть предполагается, что годы будут с 2000 по 2029 годы).Даты между 30 января и 31 декабря 1999 года считаются датами двадцатого века (т. Е. Предполагается, что это года с 1930 по 1999 годы).

• Long Time То же, что и настройка на вкладке Time в региональных настройках Windows. Пример: 17:34:23.

• Среднее время Отображает время в часах и минутах, разделенных символом-разделителем времени, за которым следует индикатор AM / PM.Пример: 17:34.

• Краткое время Отображает время в виде часов и минут, разделенных разделителем времени, в 24-часовом формате. Пример: 17:34.

Списки компонентов, которые можно использовать в пользовательских форматах

Введите любую комбинацию следующих компонентов, чтобы создать собственный формат.Например, чтобы отобразить неделю года и день недели, введите ww / w .

Важно: Пользовательские форматы, несовместимые с настройками даты и времени, указанными в региональных настройках Windows, игнорируются. Дополнительные сведения о региональных настройках Windows см. В справке Windows.

Детали сепаратора

Примечание. Разделители устанавливаются в региональных настройках Windows.

: Разделитель времени. Например, чч: мм

/ Разделитель даты. Например, ммм / гггг

Любая короткая строка символов, заключенная в кавычки ( «» ) Пользовательский разделитель. Кавычки не отображаются. Например, «,» отображает запятую.

Компоненты формата даты

d День месяца в виде одной или двух цифр, по мере необходимости (от 1 до 31).

dd День месяца в виде двух цифр (от 01 до 31).

ddd Первые три буквы дня недели (с воскресенья по субботу).

dddd Полное название дня недели (с воскресенья по субботу).

w День недели (с 1 по 7).

ww Неделя года (с 1 по 53).

m Месяц года в виде одной или двух цифр, по мере необходимости (от 1 до 12).

мм Месяц года в виде двух цифр (от 01 до 12).

ммм Первые три буквы месяца (с января по декабрь).

мммм Полное название месяца (с января по декабрь).

q Квартал года (с 1 по 4).

y Число дня в году (от 1 до 366).

yy Последние две цифры года (от 01 до 99).

гггг Отображает все цифры в году от 0001 до 9999 в зависимости от поддерживаемого диапазона даты и времени.

Компоненты формата времени

ч Час, состоящий из одной или двух цифр, по мере необходимости (от 0 до 23).

чч Час в двух цифрах (от 00 до 23).

n Минуты, состоящие из одной или двух цифр, в зависимости от необходимости (от 0 до 59).

nn Минуты, состоящие из двух цифр (от 00 до 59).

с Секунда, состоящая из одной или двух цифр, по мере необходимости (от 0 до 59).

ss Секунда, состоящая из двух цифр (от 00 до 59).

Компоненты формата часов

AM / PM Двенадцатичасовые часы с прописными буквами «AM» или «PM», в зависимости от ситуации. Например, , 21:34, .

am / pm Двенадцатичасовые часы со строчными буквами «am» или «pm», в зависимости от ситуации.Например, 21:34 .

A / P Двенадцатичасовые часы с прописной буквой «A» или «P», в зависимости от ситуации. Например, 9: 34P .

a / p Двенадцатичасовые часы со строчной буквой «a» или «p», в зависимости от случая. Например, 9: 34p .

AMPM Двенадцатичасовые часы с соответствующим обозначением утра / дня, как определено в региональных настройках Windows.

Стандартные форматы

c То же, что и предварительно определенный формат «Общая дата».

ddddd То же, что и предопределенный формат короткой даты.

dddddd То же, что и предопределенный формат длинной даты.

ttttt То же, что и предопределенный формат Long Time.

Определение полей в таблицах — ArcMap | Документация

Поля — это компоненты, которые обеспечивают структуру таблицы. У вас не может быть таблицы без полей. Например, вы можете создать пустую таблицу, в которой определены поля, но нет строк (записей).

В базах данных поля используются для поддержания отношений между таблицами. Это делается путем создания совпадающих полей в двух или более таблицах. Например, если вы сохранили таблицу с именем toy_store в базе данных, а также сохранили таблицу персонала для отслеживания сотрудников в каждом магазине, вы должны создать общее поле между двумя таблицами, которое будет заполнено, например, идентификатором магазина. .Значение идентификатора магазина для конкретного магазина игрушек будет одинаковым в обеих таблицах.

Ниже в таблицу toy_store добавлено поле STORE_ID:

Таблица toy_store связана с таблицей сотрудников по идентификатору магазина. В таблице ниже показаны три сотрудника Play House:

Некоторые поля также используются для поддержания отношений между таблицами и их индексами атрибутов.

Поля в таблице хранят данные одной и той же категории с одним и тем же типом данных. Например, если у вас есть поле имени в таблице клиентов, все записи для этого поля представляют собой имена клиентов и хранятся в виде текста. Вы не будете смешивать записи, то есть вы не будете помещать имя клиента в это поле для одной записи и название продукта в то же поле для другой записи.

Когда вы создаете таблицу или добавляете поля в существующую таблицу, вы определяете тип данных, используемый для хранения данных в каждом поле.В некоторых случаях вы также указываете длину поля.

Имена полей

Имена полей — это имена, которые вы даете столбцам в таблице. Имена должны указывать, какие данные содержатся в каждом столбце. Например, когда вы создаете класс пространственных объектов в ArcCatalog, таблица предварительно заполняется полем идентификатора объекта и полем формы. Поле идентификатора объекта содержит уникальный номер идентификатора для каждого объекта в классе пространственных объектов. Поле формы определяет тип формы, хранящейся в классе пространственных объектов: точка, линия, многоугольник, мультиточка или мультипатч.

Вы также можете использовать заданные фразы для обозначения типа столбца. Например, если вы создаете отдельный уникальный идентификатор для таблицы, которую будете использовать для целей индексации, вы можете назвать поле ID_UK, указав UK, что это уникальный ключ.

Имена полей в одной таблице должны быть уникальными; например, у вас не может быть двух столбцов с именем ObjectID. Имена полей также должны начинаться с буквы и не могут содержать пробелов или зарезервированных слов. См. Раздел Ограничения размера и имени файловой базы геоданных или Данные базы данных и ArcGIS для получения дополнительной информации об ограничениях, связанных с базой данных.

Некоторые имена полей отображаются в ArcGIS вместе с их полными именами для таблиц, хранящихся в многопользовательской базе геоданных. Например, если вы создаете или импортируете класс полигональных объектов, который содержит поле с именем Area, к нему добавляются база данных, схема и имя таблицы. Это имя, которое вы видите в таблице атрибутов класса пространственных объектов. Это означает, что для класса полигональных объектов с именем archsites, хранящегося в схеме prof базы данных музея, поле Area будет MUSEUM.PROF.ARCHSITES.ПЛОЩАДЬ.

В следующем списке содержатся все имена полей, которые полностью определены в многопользовательской базе геоданных:

• FID
• AREA
• LEN
• POINTS
• NUMOFPTS
• ENTITY
• EMINX
9000MA EINY
• EMINZ
• EMAXZ
• MIN_MEASURE
• MAX_MEASURE

Для таких случаев вы можете рассмотреть возможность использования другого имени поля или псевдонима поля.

Переименование полей

Вы можете переименовать поля в таблице или классе пространственных объектов на вкладке Поля диалогового окна Свойства. Поля в базе геоданных из выпуска ArcGIS 10 и более поздних версий поддерживают переименование, а поля в таблицах базы данных можно переименовывать.

Чтобы переименовать поле, щелкните правой кнопкой мыши класс пространственных объектов или таблицу в дереве Каталога и выберите Свойства. Щелкните вкладку Поля, чтобы увидеть список полей в этой таблице или классе объектов. Щелкните текст поля, которое вы хотите переименовать, и введите новое имя.Нажмите ОК, чтобы применить изменения и закрыть диалоговое окно «Свойства».

Следующие поля не могут быть переименованы:

• Поля ObjectID и globalID
• Любые поле, связанное с формой; Форма, длина формы, площадь формы
• включенные, вспомогательные роли или поля веса сети в сети класс пространственных объектов
• Поля представления
• Поля в классе пространственных объектов, участвующих в наборе сетевых данных, ландшафте, или набор данных участков
• Поля, используемые для отслеживания редактора
• Поля первичного и внешнего ключа класса отношений
• поле подтипа
• Растровые поля

Правила и ограничения имени поля

В следующей таблице перечислены поддерживаемые правила символов имени поля:

Дополнительные правила и ограничения имени поля следующие:

• Имена полей не могут содержать зарезервированные слова, например все или результат.

  Дополнительные зарезервированные слова см. В документации по вашей системе управления базами данных (СУБД).

• Длина имен полей (столбцов) зависит от базовой базы данных.

  См. Раздел Ограничения размера и имен файловой базы геоданных или Данные базы данных и ArcGIS для получения дополнительной информации об ограничениях, связанных с базой данных.

Псевдонимы полей

Псевдонимы полей позволяют назначать альтернативное имя для поля. Обычно вы используете как можно более короткие имена полей, чтобы передать, какие данные хранятся в этом поле.Вы также не можете использовать пробелы или специальные символы в имени поля, и, как показано выше, некоторые поля отображаются в таблице с их полностью определенными именами. В этих случаях вы можете использовать псевдоним поля, чтобы дать полю более информативное имя. Например, если у вас есть поле с именем ST_SUFX, в котором хранится тип улицы, который обозначается суффиксом, используемым в названии улицы, вы можете дать этому полю псевдоним суффикса названия улицы.

Узнайте, как установить псевдоним поля.

Совет:

Методы геообработки позволяют проверять имена таблиц и полей.

Использование доменов для управления значениями полей

Домены атрибутов — это правила, указывающие допустимые значения для поля в таблице в базе геоданных. Они обеспечивают целостность данных, ограничивая значения данных, которые пользователь может добавить в определенное поле.

Вы можете применять домены атрибутов к полям, только если для этого поля существует определяемый набор или диапазон конкретных значений. Например, поле, в котором хранится ответ на вопрос анкеты. Какая ваша любимая еда? сложно применить домен, так как можно дать большое количество ответов.Однако полю, хранящему данные о цвете глаз, может быть назначен атрибутный домен, потому что существует только несколько возможных допустимых значений.

• Черный
• Коричневый
• Синий
• Зеленый
• Хейзел
• Серый
• Фиолетовый

Использование атрибутивного домена для поля, в котором хранятся данные о цвете глаз, обеспечит согласованность значений. Если бы сборщикам данных было разрешено вводить любой цвет в текстовое поле для определения цвета глаз, вы могли бы получить любой из следующих значений для голубых глаз:

• Azure
• Navy
• Sky blue
• Cobalt
• Aquamarine

Домены атрибутов также предотвращают орфографические ошибки или опечатки.Даже если бы сборщики данных знали, что термин «синий» используется только для обозначения голубых глаз, они могли бы неправильно написать слово (bleu) или по ошибке нажать не ту клавишу при вводе слова (vlue) в текстовое поле.

Типы доменов атрибутов

Существует два типа доменов атрибутов, которые можно использовать для ограничения значений полей: домен кодированных значений и домен диапазона.

Область кодированных значений использует коды для определения набора допустимых значений для поля, в котором хранятся дискретные данные.

Вы можете использовать домен кодированных значений для любого типа данных.Для поля цвета глаз вы можете создать кодированный домен, используя один из следующих наборов кодов:

• Пример 1
  • Blk = Черный
  • Brn = Коричневый
  • Синий = Синий
  • Grn = Зеленый
  • Hzl = Орешник
  • Gra = серый
  • Vlt = фиолетовый

• Пример 2
  • 1 = черный
  • 2 = коричневый
  • 3 = синий
  • 4 = зеленый
  • 5 = ореховый
  • 6 = серый
  • 7 = фиолетовый

Домен диапазона определяет диапазон допустимых числовых значений для поля.

Поле должно иметь числовой тип данных или тип данных даты, чтобы использовать домен диапазона. Например, вы можете применить домен диапазона к полю, в котором хранятся данные о весе при рождении для одиноких живорождений западных низинных горилл в зоопарках. Диапазон может варьироваться от наименьшего веса (1 кг) до наибольшего (2,5 кг).

Для получения дополнительной информации об атрибутивных доменах см. Краткий обзор атрибутных доменов.

Чтобы узнать, как создать домен атрибутов, см. Создание нового домена диапазона атрибутов и Создание нового домена кодированных значений.

Использование подтипов

Подтипы — это классификации в классе пространственных объектов или таблице в базе геоданных. Они позволяют логически группировать функции на основе уникальных характеристик или поведения данных. Эта характеристика или поведение представлены значениями одного поля в таблице. Например, для таблицы гидрологии у вас могут быть подтипы для типов водных путей, таких как ручьи, ручьи, каналы, каналы и реки. Для каждого из этих подтипов можно применять различные правила топологии, правила подключения, значения по умолчанию и правила отношений.

Использование подтипов для хранения групп связанных функций может повысить производительность запросов. Если вы сохранили различные типы данных в отдельных классах пространственных объектов вместо использования подтипов, у вас будет большее количество классов пространственных объектов в базе данных, и поиск может занять больше времени.

При использовании подтипов применяются следующие правила:

• Только одно поле в таблице или классе пространственных объектов может иметь подтипы.
• Поле, на котором вы основываете подтип, должно быть длинным или коротким целочисленным полем.
• К разным подтипам можно применять разные правила топологии и отношений.
• К другим полям таблицы можно применять различные атрибуты или закодированные домены в зависимости от подтипов.

Чтобы применить подтипы, выполните следующие действия:

1. Убедитесь, что поле, к которому будет применяться подтип, является коротким или длинным целочисленным полем. Если это не так, добавьте короткое или длинное целочисленное поле в таблицу или класс пространственных объектов. В большинстве случаев достаточно короткого целого числа.Однако, если есть вероятность, что значения вашего подтипа превысят 32 767, используйте поле длинного целого числа.

   Например, для класса пространственных объектов рек вы можете добавить короткое целочисленное поле с именем Водораздел для создания подтипов на основе водосбора, в который река вносит свой вклад.

2. На вкладке «Подтипы» диалогового окна «Свойства» для таблицы или класса пространственных объектов укажите поле подтипа, выбрав его в первом раскрывающемся списке.

   В примере с реками выберите поле Watershed из списка Subtype Field.

   Новый подтип автоматически добавляется в таблицу подтипов. Этот подтип по умолчанию имеет код 0 и описание нового подтипа.

3. Дважды щелкните каждое из этих полей и введите код подтипа и описание.

   Например, измените первый код на 1 и описание на название первого водораздела.

4. При желании можно продолжить добавление кодов и описаний подтипов в таблицу подтипов.

   В поле под кодом 1 вы можете добавить код 2 с соответствующим именем водораздела в поле Описание, а под ним добавить код 3 с соответствующим именем водораздела и так далее, пока вы не создадите коды и описания для все водоразделы, представленные в вашем классе пространственных объектов рек.

5. Чтобы указать разные значения по умолчанию или домены для каждого подтипа, щелкните подтип в списке Подтипы. В списке «Значения по умолчанию и домены» при желании введите значение по умолчанию для любого поля в списке. Чтобы применить кодированный или атрибутный домен к полям в списке, щелкните поле «Домен» и выберите домен из раскрывающегося списка. Если доменов не существует, создайте его, нажав кнопку «Домены» в нижней части диалогового окна «Свойства», которая приведет вас к диалоговому окну «Домены рабочей области».

   Указанные вами значения по умолчанию и домены применяются только к подтипу, который вы выбрали из списка «Подтипы». Если вы щелкните другой подтип в списке Подтипы, значения и домены по умолчанию будут либо пустыми (если вы не указали значения по умолчанию и домены для этого подтипа), либо содержат другие значения.

Дополнительные сведения о подтипах

Связанные темы

00294: Редактируемые сервисы объектов не могут содержать представления базы данных. это представление базы данных — ArcGIS Pro

Редактируемый векторный слой вы пытались опубликовать, включает представление базы данных.Представления часто используются для объединения двух или более таблиц вместе и не могут редактироваться в программном обеспечении ArcGIS; следовательно, вы не можете разрешить редактирование на векторном слое, который содержит вид, если векторный слой ссылается на зарегистрированную базу данных.

Совет:

Представления базы данных включают представления, зарегистрированные в базе геоданных, а также те, которые не зарегистрированы.

Решение

Как вы будете действовать, зависит от того, что вам нужно сделать. Используйте одно из следующих предложений для публикации необходимых данных в веб-слое или слоях:

• Если вам нужно отредактировать другие данные на карте и вам нужны только данные из представления в качестве справки, вы можете сделать следующее:
  1. Удалите вид с карты и опубликуйте другие данные на редактируемом векторном слое.
  2. Создайте отдельную карту, содержащую вид, и опубликуйте слой изображения карты или слой объектов только для чтения.
  Это делает те же данные доступными через веб-слои, позволяя редактировать данные, которые поддерживают редактирование.
• Если ваше зарегистрированное хранилище данных является многопользовательской базой геоданных и вы используете представление для представления объединенных таблиц, которые необходимо отредактировать, вы можете сделать следующее:
  1. Удалить представление с карты.
  2. Создайте класс отношений между таблицами, которые вы объединяли вместе с помощью представления.
  3. Добавьте на карту таблицы, которые участвуют в классе отношений.
  4. Опубликуйте редактируемый векторный слой.
• Если вам не нужно редактировать какие-либо данные на карте (например, вы не изменили свойства векторного слоя по умолчанию перед попыткой публикации, даже если вам не нужно редактировать), снимите флажок Разрешить редактирование и разрешить редакторам устанавливать флажок, чтобы отключить редактирование и опубликовать векторный слой, доступный только для чтения.

Дополнительная информация

Дополнительные сведения см. В разделах Настройка векторного веб-слоя и Анализ вашего ГИС-ресурса.

Отзыв по этой теме?

Свяжите свои данные — Таблица

Отношения — это динамический и гибкий способ объединения данных из нескольких таблиц для анализа. Отношение описывает, как две таблицы связаны друг с другом, на основе общих полей, но не объединяет таблицы вместе. Когда между таблицами создается связь, таблицы остаются отдельными, сохраняя свой индивидуальный уровень детализации и доменов.

Думайте о взаимоотношениях как о контракте между двумя таблицами. Когда вы создаете визуализацию с полями из этих таблиц, Tableau вводит данные из этих таблиц, используя этот контракт для построения запроса с соответствующими соединениями.

Узнать больше : Возможность связать ваши данные — важная особенность новых возможностей моделирования данных Tableau. Для получения дополнительной информации см. Что изменилось с источниками данных и анализом.Узнайте больше о том, как работают отношения, в этих сообщениях блога Tableau:

Посмотреть видео : Обзор улучшений источника данных и введение в использование отношений в Tableau см. В этом 5-минутном видео.

Что такое отношения?

Отношения — это гибкие соединительные линии, создаваемые между логическими таблицами в источнике данных.Некоторые люди нежно называют отношения «лапшой», но мы обычно называем их «отношениями» в нашей справочной документации.

Мы рекомендуем использовать отношения в качестве первого подхода к объединению данных, поскольку они упрощают подготовку и анализ данных и делают их более интуитивно понятными. Используйте объединения только в случае крайней необходимости (ссылка открывается в новом окне).

Отношения обеспечивают несколько преимуществ по сравнению с использованием объединений для данных из нескольких таблиц:

• Типы соединения между таблицами настраивать не нужно.Вам нужно только выбрать поля, чтобы определить отношения.
• Связанные таблицы остаются отдельными и отличными друг от друга; они не объединяются в одну таблицу.
• Отношения используют объединения, но они автоматические. Tableau автоматически выбирает типы соединений на основе полей, используемых в визуализации. Во время анализа Tableau интеллектуально настраивает типы соединений и сохраняет исходный уровень детализации ваших данных.
• Tableau использует отношения для создания правильных агрегатов и соответствующих объединений во время анализа на основе текущего контекста полей, используемых на листе.
• В одном источнике данных поддерживается несколько таблиц с разными уровнями детализации. Вы можете создавать модели данных, содержащие больше таблиц, и уменьшать количество источников данных, необходимых для построения визуализации.
• Несовпадающие значения меры не удаляются (без случайной потери данных).
• Избегает дублирования данных и проблем с фильтрацией, которые иногда могут возникать в результате объединений.
• Tableau будет генерировать запросы только для данных, относящихся к текущему представлению.

Дополнительную информацию см .:

Требования к отношениям

• При связывании таблиц поля, определяющие отношения, должны иметь один и тот же тип данных.
• Вы не можете определять отношения на основе географических полей.
• Круговые отношения не поддерживаются в модели данных.
• Вы не можете редактировать отношения в опубликованном источнике данных.
• Вы не можете определить отношения между опубликованными источниками данных.
• Ваша книга должна использовать встроенный источник данных, чтобы вы могли редактировать отношения и параметры производительности на странице «Источник данных» в Tableau Online или Tableau Server.

Факторы, ограничивающие преимущества использования связанных таблиц:

• Грязные данные в таблицах (т.е. таблицы, которые не были созданы с учетом хорошо структурированной модели и содержат сочетание мер и измерений в нескольких таблицах), могут усложнить многотабличный анализ.
• Использование фильтров источника данных ограничит возможность Tableau выполнять отсечение соединений в данных. Отбор объединений — это термин для обозначения того, как Tableau упрощает запросы, удаляя ненужные объединения.
• Таблицы с множеством несогласованных значений в отношениях.
• Взаимосвязь нескольких таблиц фактов с несколькими таблицами измерений (попытка моделирования общих или согласованных измерений).

Данные, которые нельзя связать

Большинство типов реляционных соединений полностью поддерживаются. Кубы, SAP HANA (с атрибутом OLAP), JSON и Google Analytics ограничены одной логической таблицей в Tableau 2020.2. Хранимые процедуры можно использовать только в одной логической таблице.

Опубликованные источники данных не могут быть связаны друг с другом. Вы также не можете редактировать опубликованные источники данных.

не поддерживается

• Базы данных куба не поддерживают новый логический уровень.Подключение к кубу предлагает те же возможности, что и до 2020 г. 2.
• Хранимые процедуры: не поддерживают федерацию, отношения или объединения. Они представлены в единой логической таблице и не позволяют открывать холст Join / Union (физический уровень).
• Splunk: не поддерживает левые соединения (и, следовательно, связанные логические таблицы).
• JSON: не поддерживает федерацию, настраиваемый SQL, объединения или отношения (только объединения).
• Источники данных, которые не поддерживают вычисления LOD. Дополнительные сведения см. В разделе Ограничения источника данных для выражений с уровнем детализации.

Ограниченная поддержка

• Стандартные соединения Salesforce и WDC: они представлены в виде объединенных таблиц в логической таблице. Добавление этих подключений в настоящее время поддерживается только для источников данных с одной логической таблицей. Стандартные соединения не могут присоединиться к существующей таблице.
• SAP HANA: в настоящее время не поддерживает связывание логических таблиц, если для соединения установлен атрибут OLAP.

Создание и определение отношений

После перетаскивания первой таблицы на основу верхнего уровня источника данных каждая новая таблица, которую вы перетаскиваете на основу, должна быть связана с существующей таблицей. Когда вы создаете связи между таблицами на логическом уровне, вы строите модель данных для своего источника данных.

Примечание : Вы не можете редактировать модель данных опубликованного источника данных.

Создать отношения

Вы создаете отношения на логическом уровне источника данных. Это представление по умолчанию для холста, который вы видите на странице источника данных.

1. Перетащите таблицу на холст.

2. Перетащите другую таблицу на холст. Когда вы увидите «лапшу» между двумя столами, опустите этот стол.

   Откроется диалоговое окно «Изменить взаимосвязь». Tableau автоматически пытается создать взаимосвязь на основе существующих ключевых ограничений и совпадающих полей для определения взаимосвязи. Если он не может определить совпадающие поля, вам нужно будет выбрать их.

   Чтобы изменить поля : Выберите пару полей, а затем щелкните в списке полей ниже, чтобы выбрать новую пару совпадающих полей.

   Чтобы добавить несколько пар полей : После выбора первой пары щелкните Закрыть , а затем щелкните Добавить дополнительные поля .

   Примечание : В Таблице 2020.3 и более поздних версий, вы можете создавать отношения на основе вычисляемых полей и сравнивать поля, используемые для отношений, используя операторы в определении отношения. Обратите внимание, что следующие соединители не поддерживают операторы неравенства: Google BigQuery, MapR, Salesforce.

   Если ограничения не обнаружены, создается отношение «многие ко многим» , а ссылочная целостность устанавливается на . Некоторые записи соответствуют . Эти настройки по умолчанию являются безопасным выбором и обеспечивают максимальную гибкость для вашего источника данных.Настройки по умолчанию поддерживают полные внешние объединения и оптимизируют запросы путем агрегирования табличных данных перед формированием объединений во время анализа. Все данные столбцов и строк из каждой таблицы становятся доступными для анализа.

   Во многих аналитических сценариях использование настроек по умолчанию для отношения предоставит вам все данные, необходимые для анализа. Использование отношения «многие ко многим» будет работать, даже если ваши данные на самом деле относятся к числу «многие к одному» или «один к одному». Если вы знаете конкретную мощность и ссылочную целостность ваших данных, вы можете настроить параметры производительности (ссылка открывается в новом окне), чтобы более точно описать ваши данные и оптимизировать то, как Tableau запрашивает базу данных.

3. При необходимости добавьте дополнительные таблицы, выполнив те же действия.

После того, как вы создали свой многотабличный связанный источник данных, вы можете погрузиться в изучение этих данных. Дополнительные сведения см. В разделах «Как работает анализ для источников данных с несколькими таблицами, которые используют отношения» и «Устранение неполадок с анализом нескольких таблиц».

Переместите таблицу, чтобы создать другую связь

Чтобы переместить таблицу, перетащите ее рядом с другой таблицей. Или наведите указатель мыши на таблицу, щелкните стрелку и выберите Переместить .

Совет : перетащите таблицу поверх другой таблицы, чтобы заменить ее.

Удалить таблицу из отношения

Чтобы переместить таблицу, наведите на нее курсор, щелкните стрелку и выберите Удалить .

Посмотреть отношения

• Наведите указатель мыши на линию связи (лапшу), чтобы увидеть соответствующие поля, которые ее определяют. Вы также можете навести указатель мыши на любую логическую таблицу, чтобы увидеть, что она содержит.

  
  

Изменить отношение

• Щелкните линию взаимосвязи, чтобы открыть диалоговое окно «Изменить взаимосвязь». Вы можете добавлять, изменять или удалять поля, используемые для определения отношения.Добавьте дополнительные пары полей, чтобы создать сложную связь.

  Чтобы добавить несколько пар полей: После выбора первой пары щелкните Закрыть , а затем щелкните Добавить дополнительные поля .

Советы по созданию отношений

• Первая таблица, которую вы перетаскиваете на холст, становится корневой таблицей для модели данных в вашем источнике данных. После того, как вы вытащите корневую таблицу, вы можете растягивать дополнительные таблицы в любом порядке.Вам нужно будет подумать, какие таблицы должны быть связаны друг с другом, и какие пары полей вы определяете для каждого отношения.
• Перед тем, как вы начнете создавать отношения, просмотр данных из источника данных до или во время анализа может быть полезным, чтобы дать вам представление об объеме каждой таблицы. Для получения дополнительной информации см. Просмотр базовых данных. Вы также можете использовать View Data, чтобы увидеть базовые данные таблицы, когда связь недействительна.
• Если вы создаете звездообразную схему, может быть полезно сначала перетащить таблицу фактов, а затем связать таблицы измерений с этой таблицей.
• Каждое отношение должно состоять как минимум из одной совпадающей пары полей. Добавьте несколько пар полей, чтобы создать сложную связь. Соответствующие пары должны иметь один и тот же тип данных. Изменение типа данных на странице «Источник данных» не меняет этого требования. Tableau по-прежнему будет использовать тип данных в базовой базе данных для запросов.
• Отношения могут быть основаны на вычисляемых полях. Вы также можете указать, как поля должны сравниваться, используя операторы при определении отношения.
• При удалении таблицы на холсте автоматически удаляются и связанные с ней потомки. Если вы удалите корневую таблицу, все остальные таблицы в модели также будут удалены.

Проверить отношения в источнике данных

У вас есть несколько вариантов проверки вашей модели данных для анализа. При создании модели для источника данных мы рекомендуем перейти к листу, выбрать этот источник данных, а затем создать визуализацию для исследования количества записей, несогласованных значений, нулевых значений или повторяющихся значений мер.Попробуйте работать с полями в разных таблицах, чтобы убедиться, что все выглядит так, как вы ожидаете.

На что обращать внимание:

• Используют ли ваши отношения в модели данных правильные совпадающие поля для своих таблиц?
• Каковы результаты перетаскивания в представление различных измерений и мер?
• Вы видите ожидаемое количество строк?
• Могут ли сложные отношения сделать отношения более точными?
• Если вы изменили какие-либо настройки параметров производительности по сравнению с настройками по умолчанию, соответствуют ли значения, которые вы видите в визуализации, ожидаемым? Если это не так, вы можете проверить настройки или сбросить настройки до значений по умолчанию.

Опции для проверки взаимосвязей и модели данных:

• Каждая таблица включает счетчик своих записей в виде поля с именем TableName (Count) на уровне детализации этой таблицы. Чтобы увидеть счетчик для таблицы, перетащите его поле «Счетчик» в представление. Чтобы увидеть счетчик для всех таблиц, выберите поле «Счетчик» для каждой таблицы на панели «Данные», а затем щелкните текстовую таблицу в «Показать меня».
• Щелкните Просмотр данных на панели данных, чтобы увидеть количество строк и данных в таблице.Кроме того, перед тем, как вы начнете создавать отношения, просмотр данных из источника данных до или во время анализа может быть полезным, чтобы дать вам представление об объеме каждой таблицы. Для получения дополнительной информации см. Просмотр базовых данных.
  
• Перетащите размеры на строки, чтобы увидеть количество строк в строке состояния. Чтобы увидеть несопоставленные значения, щелкните меню Analysis , а затем выберите «Макет таблицы»> «Показать пустые строки» или «Показать пустые столбцы». Вы также можете перетаскивать в представление различные меры, например (Count) , из одной из таблиц, представленных в вашем viz.Это гарантирует, что вы увидите все значения измерений из этой таблицы.
  

Совет : Если вы хотите увидеть запросы, которые создаются для отношений, вы можете использовать средство записи производительности в Tableau Desktop.

1. Щелкните меню «Справка» и выберите «Параметры и производительность »> « Начать запись производительности ».
2. Перетащите поля в представление, чтобы построить визуализацию.
3. Щелкните меню «Справка» и выберите «Настройки и производительность »> « Остановить запись производительности ».
4. На панели мониторинга «Сводка производительности» в разделе «События, отсортированные по времени» щелкните панель «Выполнение запроса» и просмотрите запрос ниже.

Еще один более продвинутый вариант — использовать Tableau Log Viewer (ссылка открывается в новом окне) на GitHub.Вы можете выполнить фильтрацию по определенному ключевому слову, используя end-protocol.query . Для получения дополнительной информации начните с вики-страницы Tableau Log Viewer (ссылка открывается в новом окне) в GitHub.

Визуализации только для измерений

При использовании источника данных из нескольких таблиц со связанными таблицами: если вы строите визуализацию только для измерений, Tableau использует внутренние соединения, и вы не увидите полный несопоставленный домен.

Чтобы увидеть частичные комбинации значений измерений, вы можете:

• Используйте Показать пустые строки / столбцы, чтобы увидеть все возможные строки.Щелкните меню Analysis , а затем выберите «Макет таблицы»> «Показать пустые строки» или «Показать пустые столбцы».
• Добавьте меру в представление, например (Count) из одной из таблиц, представленных в вашем viz. Это гарантирует, что вы увидите все значения измерений из этой таблицы.
  

Дополнительные сведения см. В разделах «Как работает анализ для источников данных с несколькими таблицами, которые используют взаимосвязи» и «Устранение неполадок с анализом нескольких таблиц».

Отношения (логические таблицы) по сравнению с объединениями (физические таблицы)

Несмотря на то, что они похожи, объединения и отношения в Tableau ведут себя по-разному и определяются на разных уровнях модели данных. Вы создаете отношения между логическими таблицами на верхнем логическом уровне вашего источника данных. Вы создаете соединения между физическими таблицами на физическом уровне вашего источника данных.

Объединяет данные из двух таблиц в единую таблицу перед началом анализа.Объединение таблиц вместе может привести к дублированию или фильтрации данных из одной или обеих таблиц; это также может привести к добавлению к вашим данным строк NULL, если вы используете левое, правое или полное внешнее соединение. При анализе объединенных данных необходимо убедиться, что вы правильно обрабатываете влияние объединения на ваши данные.

Примечание : Если может потребоваться дублирование или фильтрующие эффекты объединения, используйте объединения для объединения таблиц вместо отношений.Дважды щелкните логическую таблицу, чтобы открыть физический уровень и добавить соединенные таблицы.

Отношение описывает, как две независимые таблицы связаны друг с другом, но не объединяют таблицы вместе. Это позволяет избежать дублирования данных и проблем с фильтрацией, которые могут возникнуть при объединении, и может упростить работу с вашими данными.

Отношения против смесей

Хотя и отношения, и смеси поддерживают анализ на разных уровнях детализации, между ними есть явные различия.Одна из причин, по которой вы можете использовать смешение вместо отношений, — это объединение опубликованных источников данных для анализа.

Особенности различных вариантов объединения данных: отношения, объединения и смешения

Есть много способов объединить таблицы данных, каждая со своими предпочтительными сценариями и нюансами.

Размеры, фильтры и типы параметров

Размеры, фильтры и типы параметров

Эта страница относится к параметру типа , который является частью измерения или фильтра.

тип также может использоваться как часть меры, описанной на странице документации по типам мер.

тип также может использоваться как часть группы измерений, описанной на странице параметра Dimension_group .

view: view_name {
Dimension: field_name {
type: field_type
}
}

На этой странице содержатся дополнительные сведения о различных типах, которые могут быть назначены параметру размерности , , фильтру или параметру . Измерение, фильтр или параметр могут иметь только один тип, по умолчанию строка , если тип не указан.

Некоторые типы имеют вспомогательные параметры, которые описаны в соответствующем разделе.

d = Размер

dg = Группа измерений

f = Фильтр

p = параметр

тип: расстояние используется для вычисления расстояния наиболее прямого пути («по прямой») между двумя измерениями типа : местоположение .

Параметр sql для типа : расстояние измерений исключается.Вместо этого вы указываете ссылку на измерение типа : положение в параметрах start_location_field и end_location_field .

Использование:

view: view_name {
Dimension: field_name {
type: distance
start_location_field: field_name_1
end_location_field: field_name_2
units: km
}
}

Единица расстояния определяется параметром единиц , который может принимать следующие значения:

• футов
• км
• метра
• миль
• морских_миль
• ярдов

Например, вы можете рассчитать расстояние, пройденное клиентом, чтобы получить прокат, например:

Dimension: distance_to_pickup { тип: расстояние start_location_field: customer.home_location end_location_field: rental.pickup_location единицы: мили }

Отметим, что рассчитанное расстояние будет представлять собой наиболее прямой путь («по прямой») между двумя точками, а не обязательно расстояние, пройденное по дороге.

Обратите внимание, что вам не следует использовать синтаксис $ {view_name.field_name} в параметрах start_location_field и end_location_field . Вместо этого используйте сами по себе имя представления и имя поля, например имя_представления.имя_поля .

тип: продолжительность используется в сочетании с группой измерений для создания набора вычисленных разниц во времени между измерениями и / или выражениями SQL.

type: duration работает только с размером_группы , а , а не , будет работать с обычным размером . Однако вы можете указать отдельные измерения на основе продолжительности, как описано в этом разделе ниже.

Для получения информации о группах измерений с типом : продолжительность см. Страницу параметра Dimension_group .

type: location используется в сочетании с параметрами sql_latitude и sql_longitude для создания координат, которые вы хотите нанести на карту или визуализацию статической карты (точки) (используйте поле штата или страны для статической карты (регионы) )), или то, что вы хотите использовать в расчете типа : расстояние .

Схема использования:

view: view_name {
Dimension: field_name {
type: location
sql_latitude: $ {field_name_1} ;;
sql_longitude: $ {field_name_2} ;;
}
}

Параметр sql для измерений типа : расположение исключается.Вместо этого вы предоставляете любое допустимое выражение SQL, которое приводит к десятичной широте или долготе, в параметры sql_latitude и sql_longitude . Обычно это ссылки на поля LookML, которые содержат информацию о широте или долготе, но они могут быть статическими значениями, если вы хотите узнать местоположение своей штаб-квартиры или что-то в этом роде.

Например, вы можете создать измерение store_location следующим образом:

Dimension: store_location { тип: расположение sql_latitude: $ {store_latitude} ;; sql_longitude: $ {store_longitude} ;; }

Если вы не хотите наносить на карту местоположения или рассчитывать расстояния, вы можете использовать более простой тип, например тип : число .Когда вы просматриваете местоположение в таблице, оно покажет значение из вашей базы данных, а также автоматически создаст ссылку на это местоположение в Google Maps:

Поддерживаемые диалекты базы данных для местоположения