kazminaviktoriya1
В профиль
Выход
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Метаданные полей данных
В предыдущих уроках вы узнали о переходе от логической модели данных к физической. На этом этапе СА работает не только с данными, но и с метаданными.
В этом уроке расскажем о том, что такое метаданные и как СА определяет те или иные метаданные, — на примере СУБД PostgreSQL.
Что такое метаданные
Прежде чем говорить о метаданных, вспомним, что относится к данным, а что нет.
Термин «метаданные» пришёл из библиотечного дела: карточки каталога содержат данные о книгах — название, имя автора, издательство и прочее.
Идея метаданных с тех пор не изменилась — трудно представить себе сообщение, документ или страницу веб-сайта, у которых нет даты создания или редактирования.
Таким образом, метаданные — это описание любой структуры данных, или «данные о данных».
Если речь идёт о хранилище данных, то СА работает прежде всего с метаданными полей данных, то есть смотрит, какие у полей названия, к какому формату они относятся, какие у них есть ограничения и так далее.
Метаданные хранилища включают в себя и другие характеристики — с ними работают другие члены команды разработки. В этом уроке остановимся только на метаданных полей таблиц.
Как и любые данные, метаданные хранятся в базе данных. Их можно получить с помощью SQL-запросов или посмотреть в свойствах таблицы.
Правила именования полей данных
Один из самых важных элементов метаданных — это название поля. Название должно отражать содержимое поля и быть понятным всем, кто пользуется хранилищем данных.
Казалось бы, название можно просто взять из логической модели данных. К сожалению, не всё так просто: у каждой СУБД есть свои правила именования полей.
Язык и допустимые символы
Так как большинство СУБД, включая PostgreSQL, англоязычные, они поддерживают названия полей на английском языке. Поэтому, если в вашей логической модели данных названия атрибутов были на русском, их стоит перевести на английский. Например,
фамилия → surname.Англоязычные названия нужно согласовать со стейкхолдерами, чтобы не возникло разночтений: например,
фамилия — это surname, а не last_name.В PostgreSQL можно использовать следующие символы в названиях полей:
- прописные и строчные буквы латинского алфавита (a–z, A–Z);
- цифры (0–9);
- символ подчёркивания (_).
Длина названия не должна превышать 63 символа. Обратите внимание, что символ пробела добавлять нельзя.
Регистр
Чувствительность к регистру зависит от СУБД. В PostgreSQL, когда вы создаёте таблицу или делаете к ней запрос, по умолчанию используется нижний регистр, даже если вы сделали запрос в верхнем:
SQL
Чтобы изменить чувствительность к регистру, нужно взять название в кавычки:
SQL
Так как постоянно добавлять кавычки неудобно, хорошая практика — именовать поля в нижнем регистре. Важно помнить, что пробелы в названии использовать нельзя, поэтому слова принято отделять друг от друга символом подчёркивания:
first_name.Префикс
Представьте, что есть две таблицы: данные клиента и данные о продажах. В обеих таблицах есть поле
year (год): в первом случае это год рождения клиента, во втором — год продажи. Если объединить таблицы, может возникнуть путаница.
Решить проблему поможет префикс — слово, которое стоит в начале названия поля и указывает на название таблицы. Префикс отделяется от названия поля символом подчёркивания. Например, ко всем полям таблицы
users должен быть добавлен префикс usr. Тогда поле year превратится в usr_year.
Типы данных и размерность
Ещё одна важная характеристика поля таблицы — это тип данных. Вы уже сталкивались с этим понятием в курсе по SQL, а также в уроке о словаре данных. Для начала вспомним главное.
Вот как типы в словаре данных соотносятся с типами в физической модели данных:
В отличие от словаря данных, в физической модели стоит учитывать, сколько места занимает тот или иной тип в памяти. Диапазон возможных значений напрямую связан с размером выделяемой памяти. Чем длиннее строка или число, которые вы хотите записать, тем больше места в памяти нужно зарезервировать. С другой стороны, если вы зарезервируете больше места, чем надо, ресурсы будут потрачены впустую.
Обратите внимание: размер памяти и длина поля — это не одно и то же. Длина измеряется в символах, а размерность — в байтах.
Рассмотрим базовые типы данных и место, необходимое для их хранения.
Числовые типы
Числовые типы отличаются от всех других типов тем, что позволяют совершать математические операции с данными, включая агрегирование. К тому же числа, записанные в числовые данные, занимают меньше места, чем записанные в другие типы.
Вспомним основные числовые типы в PostgreSQL:
integer — это, как правило, небольшие числа фиксированного диапазона, например рост, вес, возраст. bigint — это числа, которые не помещаются в int. Обычно это идентификаторы. Например, порядковый номер заказа в онлайн-магазине может выйти за пределы 9 символов.Наконец,
real — это чаще всего цены, процентные показатели и другие подобные числа.Символьные типы
Символьный тип — это основной тип для хранения текстовых данных. Это могут быть, например, Ф. И. О., электронная почта, адрес. С такими данными нельзя производить математические операции, зато можно менять регистр, обрезать, работать с отдельными символами и так далее.
Вот какие типы относятся к символьным:
Если вы используете тип
char, строка будет занимать ровно столько места, сколько вы указали, а неиспользованные символы будут заполнены пробелами. Например, в char(5) имя Ira превратится в Ira . В varchar(5) такого не произойдёт — имя Ira сохранится как 3 символа и будет занимать место ровно для 3 символов. Если же лимит n=5 будет превышен, в обоих случаях строка обрежется.Тип
varchar, как правило, используют для хранения строк, включая одиночные слова, а тип char(1) — для хранения единичных символов.Логический тип
К логическому типу относятся данные, у которых есть только два состояния: истинное и ложное. Это данные, к которым можно задать вопрос на «да» и «нет». Например, является ли билет возвратным, подписал ли клиент согласие на обработку данных, состоялась ли сделка.
Теоретически можно было бы хранить логические данные в символьном типе, записывая в значение
true или false. Но символьный тип данных занимает больше места, чем тип boolean, поэтому boolean в этом случае предпочтительнее.Типы для работы с датой и временем
Данные, которые содержат дату или время, относятся к типам
date и timestamp. Кроме того, с датами можно производить математические операции. Например, вычитая одну дату из другой, можно найти количество дней между ними.При выборе типа даты стоит ответить на вопрос, есть ли необходимость хранить время, и если да, то нужно ли указывать часовой пояс. Даты с временем и часовым поясом занимают больше всего места — это тип
time.PostgreSQL поддерживает много типов данных, включая геометрические фигуры, перечисления и даже пользовательские типы. Подробнее о каждом типе можно прочитать здесь.
Выберите подходящий тип данных для хранения информации.
Названия городов
varchar(100)Названия городов лучше всего хранить в данных переменного типа
varchar(100), так как количество символов значительно различается от города к городу.Температура воздуха
integerТемпература воздуха, как правило, измеряется целыми числами в пределах от -100 до 100. Для хранения таких данных подойдёт тип
integer.Дата рождения
dateДату рождения без указания времени стоит хранить в типе
date.Средний балл в университете
realСредний балл в большинстве случаев — это дробное значение, например 4,6. Для него подойдёт тип
real.Наличие загранпаспорта
booleanНа вопрос, есть ли у человека загранпаспорт, можно ответить «да» или «нет». Для таких данных подойдёт тип
boolean.Правила валидации данных
Данные, не удовлетворяющие определённым критериям, могут вызвать сбой в работе ПО. Что это означает? Предположим, вы просите пользователя ввести в поле адрес электронной почты, а он по ошибке вводит своё имя — и это значение записывается в базу данных. При попытке отправить электронное письмо в программе возникает ошибка, так как значение имеет некорректный формат. Чтобы избежать подобных ситуаций, нужно валидировать данные перед записью в БД.
Рассмотрим основные правила валидации в хранилище данных.
Пустое значение
При грамотном проектировании баз данных большая часть полей не имеет пустых значений. Это правило относится прежде всего к следующим полям:
- Первичные ключи. Эти поля не могут содержать пустых значений. Например, у клиента всегда должен быть определён
id, еслиidявляется для него первичным ключом. - Обязательные данные. В случае с клиентом это могут быть имя, фамилия, пароль, адрес электронной почты и так далее.
Пустые значения могут быть у опциональных полей данных: например, если при регистрации клиенту необязательно указывать мобильный телефон. Если мобильный телефон не указан, то полю будет присвоено значение
NULL.Не стоит путать
NULL и ноль (0). Например, если клиент не указал свой рост, полю будет присвоено значение NULL — это говорит о том, что значение неизвестно. В большинстве математических операций пустые значения не включаются в расчёт, в отличие от нуля.Если поле данных не должно иметь пустых значений, ему можно присвоить ограничение не-
NULL. При попытке сохранить пустое значение в такое поле БД выдаст ошибку и запись не будет добавлена.Значение по умолчанию
Чтобы исключить пустые значения, можно задать для поля значение по умолчанию. Тогда при создании новой записи пустые поля автоматически заполнятся значениями по умолчанию. Если значение по умолчанию не задано явно, то значением по умолчанию становится
NULL. Значением по умолчанию могут быть как статичные данные, так и функции, которые будут выполняться во время вставки значения. Например, если в поле «День недели» всегда указывать «Воскресенье» по умолчанию — это статические данные, а если указывать текущий день недели — это уже функция.
Значения по умолчанию будут полезны в следующих случаях:
- При логическом типе данных. Например, стоит всегда указывать
false, если значения нет. - При указании текущей даты. Можно использовать специальную функцию, которая подставляет в поле текущую дату и время.
- При создании последовательности. Например, она будет рассчитывать порядковый номер записи в таблице.
Валидация непустых значений
PostgreSQL даёт возможность валидировать значения. Для каждого поля можно задать условия проверки при добавлении новых значений.
Например, для проверки значений цены можно задать следующие условия: цена должна быть положительной, не более 2 знаков после запятой. Значение будет добавлено в базу только в том случае, если оно соответствует всем ограничениям.
Валидация данных в ПО, как правило, происходит ещё до того, как эти данные попадают в базу. Хорошей практикой считается валидировать данные как можно раньше. Проверки на более поздних шагах — это дополнительная гарантия безопасности.
Например, в случае с формой регистрации данные могут валидироваться на стороне клиента. Пользователь просто не сможет нажать кнопку «Зарегистрироваться», если данные введены неправильно. Проверка на уровне хранилища данных защитит базу от непредвиденных ошибок и хакерских атак.
Отображение в физической модели
В физической модели данных обязательно указываются название и тип поля. Также указывается, какие поля являются первичным (PK) и внешним (FK) ключами. Другие свойства поля данных, например правила валидации, тоже указываются, но не всегда.
Подведём итоги
Работая над дизайном физической модели данных, СА должен обратить внимание на метаданные полей, чтобы поведение БД совпадало с ожиданиями стейкхолдеров.
Системному аналитику совместно с командой разработки нужно:
- определить названия полей данных, которые должны согласовываться с правилами именования в СУБД;
- выбрать подходящий тип данных для каждого поля данных;
- описать правила валидации полей данных.
Также СА должен уметь составить физическую модель данных, указав на ней типы полей и существующие ограничения.
