Home » Поля имени — основы работы с данными

Поля имени — основы работы с данными

В этой статье мы сосредоточимся на записи имя поля. Эти поля предназначены для содержания распознаваемого пользователем значения, по которому человек или вещь известны, адресуются или упоминаются. В отличие от записать бизнес-идентификатор обсуждается в части 5, значение поля имени может меняться со временем. Кроме того, существуют «реальные» имена для вещей (например, людей, городов), для которых могут существовать действительные повторяющиеся значения.

ПРИМЕЧАНИЕ. Эта статья является частью 6 Основы данных информационной системы для бизнес-аналитиков. Видеть Часть 1. Введение в серию ссылки на другие статьи серии, а также определения терминов Информационная система, Записывать, и Поле в контексте этого сериала.

Уникальность значения поля имени

Некоторые записи информационной системы представляют вещи, «принадлежащие» организации. Например:

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

Другие записи информационной системы представляют вещи, внешние по отношению к организации. Например:

  • ОБЛАСТЬ (например, города, страны)

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

Полные, сокращенные и кодированные названия

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

Полные имена – Если имя должно быть описательным, его значение содержит полные слова. Например, «Тройниковая петля 200 мм, оцинкованная», «Отдел кадров», «Калифорния». Поля полного имени часто содержат термин имя или этикетка как часть имени поля.

Сокращенные имена – Сокращенное наименование предназначено для «повседневного использования» организацией. Слова, составляющие полное имя, могут быть сокращены, сокращены до инициалов или превращены в аббревиатуру. Новичок в организации может не сразу распознать сокращенное имя, но это имя, под которым вещь обычно известна внутри организации. Например, «T-hng 200 мм Zn Plt», «HR», «Cal».

Read more:  Apple убирает iPhone 12 из своих магазинов раньше, чем ожидалось

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

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

Если что-то является общим для нескольких организаций, например, СТРАНА или ВАЛЮТА, могут быть доступны стандартизированные кодовые значения. Международная организация по стандартизации (ISO) поддерживает коды стран, регионов внутри стран (штатов или провинций), языков и валют. Другие организации предлагают стандарты для более отраслевых кодов. Примером может служить Международная ассоциация воздушного транспорта (IATA), которая поддерживает трехзначные коды, используемые для идентификации аэропортов (например, «LAX» для международного аэропорта Лос-Анджелеса).

Имена без слов

Не все имена состоят из слов или сокращений. Названия улиц являются хорошим примером. Большинство названий улиц содержат такие слова, как «Главная» или «Клен», или названы в честь людей или мест. Но есть также названия улиц, основанные просто на цифрах или буквах, например «1».ул. проспект», «2й Авеню», «Улица А», «Улица Б».

Другим примером имен, не состоящих из слов, являются этажи внутри многоэтажного дома. Этажи будут иметь полные названия, такие как «Первый этаж», «Пятый этаж», «Первый уровень парковки» или «Пентхаус». Но организация может хотеть иметь только закодированный версии названий этажей (например, «G», «5», «P1», «PH»).

Имена людей

Для записей, которые представляют людей, таких как ШТАТНЫЙ СОТРУДНИК или КЛИЕНТсуществует четыре основных типа имен, которые могут потребоваться для поддержки информационных потребностей организации в бизнес-процессах:

  • Юридическое название – Требуется для поддержки бизнес-процессов, в которых участвуют регулирующие органы, такие как налоговые органы, где эти организации требуют идентификации физических лиц (и компаний) по их полному юридическому имени. Например, «Томас Альберт Джонс».
  • Контактное лицо – Имя, под которым человек хочет, чтобы его узнавали в точках контакта, например, при получении обычной почты или при общении по телефону. Ожидается (но не обязательно) включение одного или нескольких имен плюс фамилия. Например, «Том Джонс».
  • Предпочитаемое имя – Имя, по которому человек предпочитает, чтобы к нему обращались внутри организации и/или клиенты. Например, «Томми» — отображается на бейдже сотрудника. Для клиентов это имя, которое человек предпочитает видеть как часть своего пользовательского опыта в Интернете. Например, «С возвращением, Том».
  • ID пользователя — Имя, выбранное или присвоенное онлайн-пользователю информационной системы. Обычно это какая-то версия имени человека. От этих имен может потребоваться, чтобы они были уникальными в контексте системы (но при необходимости может быть разрешено изменять их с течением времени). Например, ‘TJones’ для внутреннего пользователя, ‘[email protected]’ для пользователя, внешнего по отношению к организации.
Read more:  Правило о вырубке лесов повлияет на экспорт в ЕС на сумму $1,3 млрд: GTRI

Когда ожидается, что информационная система будет обрабатывать «части» имени человека как отдельно управляемые поля (например, имя, фамилия, отчество), ИМЯ ЛИЦА следует рассматривать как отдельный тип записи, содержащий отдельное поле для каждой значимой части имени. Это позволяет определить эти поля один раз и повторно использовать (связать) любое количество записей, содержащих имена людей. (Видеть ИМЯ ЛИЦА записывать и полевые примеры в Trips-R-You Словарь тематических исследований).

ПРИМЕЧАНИЕ. Некоторые организации предпочитают ставить перед именем человека титул, например «мистер» или «миссис». Точно так же организация может захотеть представить имя человека, за которым следует одна или несколько признанных квалификаций, таких как «MD», «PhD» или «QC». Если такие префиксы и суффиксы предназначены для выбора из заранее установленных наборов значений, они могут считаться информацией об имени, но их следует учитывать. классификация поля (см. Часть 9 – Поля классификации).

Свойства поля имени

Поле имени должно находиться в контексте записи, для идентификации которой предназначены значения, например ДОЛЖНОСТЬ, СЧЕТ GL, СОТРУДНИК, КЛИЕНТ. Для записей, экземпляры которых имеют только одно имя, поле можно просто назвать Имя. В идеале определение поля должно включать один или несколько примеров, поясняющих, что ожидается в отношении значений экземпляров.

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

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

Read more:  Тен Хаг хочет, чтобы «Манчестер Юнайтед» добился отказа Моуринью на фоне интереса Саудовской Аравии

Что касается ограничения допустимых символов в имени, имена, созданные внутри компании, могут быть ограничены, если для этого есть бизнес-причина (например, только буквенные символы и пробелы). Имена из внешних источников лучше не ограничивать, если нет бизнес-причины ограничивать разрешенные символы. Возникает вопрос: «Что должна делать система, если получено допустимое внешнее имя, содержащее один или несколько запрещенных символов?» Если оставить их без ограничений, этот вопрос исчезнет.

Имя Значения — Итог

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

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

Следующая статья – Часть 7 – Количественные поля


И ТаскерыАвтор: И Таскер

Дэн является автором более 30 связанных с требованиями статьи и другие ресурсы. Его более чем 45-летняя карьера в области информационных технологий включала организации в различных отраслях промышленности в США, Канаде, Австралии и Новой Зеландии. Его опыт бизнес-анализа включает проекты, связанные с собственной разработкой программного обеспечения, разработкой решений поставщиков программного обеспечения, а также приобретением и внедрением программного обеспечения COTS. Он по-прежнему увлечен требованиями к качеству и помогает бизнес-аналитикам в их разработке. С ним можно связаться по [email protected].

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.