Реляционная база данных по сравнению с кадрами данных R/Python

Question

Я столкнулся с миром таблиц и структур данных в R перед системами РСУБД и другими системами баз данных. В R/Python довольно элегантно создавать таблицы и списки из данных (CSV или других форматов), а затем делать программные операции с данными.

В прошлом году я посетил курс по управлению базами данных и узнал все о структурированных и неструктурированных базах данных. Я также заметил, что нормой является передача данных из нескольких источников данных в базы данных, а не прямое использование их в R (для удобства и дисциплины?).

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

Вопросы, возникающие в связи с этим: Когда использовать R напрямую с помощью таких команд, как read.csv, когда использовать R, создавая базу данных и запрашивая таблицы, используя интерфейс R-SQL?

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

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

Answer 1

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

Процесс, который вы описываете, обычно называется Extract, Transform, Load (ETL), и вы можете найти полезную информацию об ETL и хранилище данных, если вы решите пойти в направлении объединения ваших данных до работы с ним в R.

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

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

Некоторые из преимуществ этого могут включать :

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

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