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

Различные типы данных

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

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

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

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

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

Все началось с текстового файла

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

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

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

Переход к столам

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

Добавление индексов

В реляционной базе данных вы получите таблицы и индексы. Индексы позволяют вам сказать: «Я забочусь о получении информации на основе значения этого поля, сделайте это быстрее». Они работают, сохраняя дополнительную информацию («указатели») на жестком диске, указывая на записи на основе значения данного поля, и они позволяют очень быстро получить информацию на основе этого значения индексированного поля.

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

Это особенно хороший компромисс для данных, которые вы читаете чаще, чем пишете. Например, оптимизация производительности чтения для статьи в The New York Times намного важнее, чем оптимизация производительности записи, потому что любая данная история обновляется всего несколько раз (при условии, что есть некоторые правки / исправления), но читаются сотни тысяч раз. .

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

Удаление дублирования

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

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

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

Еще важнее риск ошибки. В программировании есть важный принцип, который называется СУХОЙ или Не повторяйся. Идея состоит в том, что если вы напишете один и тот же код в нескольких местах, в какой-то момент вы, вероятно, измените код и можете забыть изменить его в одном из мест. То же самое и с данными. Во-первых, вы можете ошибиться при вводе данных при первоначальном вводе. Что еще более важно, если данные изменятся в будущем (возможно, вы измените профессора, который преподает курс), вы можете забыть обновить одну из строк, запутав студентов, потому что они не будут знать, какой профессор будет их инструктором!

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

Как видите, в этом случае мы использовали целое число с автоинкрементом для индекса. Это просто причудливый способ сказать, что идентификатор для данного столбца начинается с «1» и увеличивается на 1 для каждой новой записи.

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

И вы увидите, что в таблице у нас есть поле, которое связано с таблицей, поэтому первые три книги могут быть «присоединены» к курсу с идентификатором 1 - «Введение в Ruby». Таким образом, если нам нужно обновить профессора, связанного с курсом, мы можем сделать это, обновив только одну строку в таблице курсов.

И это суть реляционной базы данных - использование нескольких «связанных» таблиц для уменьшения дублирования.

Денормализация базы данных

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

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

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

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

Подведение итогов

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

Первоначально опубликовано на https://flatironschool.com.