Новичок в проектировании баз данных (Postgres), ищет совета

Question

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

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

Answer 1

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

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

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

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

Определяя как можно более строгий набор правил для данных в SQL, вы защищаете от пропущенных, искаженных и ошибочных вводов. Любая проверка, выполняемая СУБД, является проверкой того, что приложение может быть пропущено и что приложение не будет перехвачено.

Например, вам даны минимальные / максимальные значения скорости ветра и так далее. Эти обещания могут формировать ограничения в базе данных. Если вы получаете отрицательную скорость ветра, что-то не так. Это может быть проблема с датчиком или (более вероятно) ошибка выравнивания данных, потому что был введен новый столбец или был неверно проанализирован ввод. Вместо того, чтобы ошибочно указать в столбце скорости ветра направление ветра направление , СУБД отклоняет ввод, и кто-то может посмотреть, что пошло не так.

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

Answer 2

Один из способов сделать это будет выглядеть примерно так:

TURBINE
  ID_TURBINE         INTEGER PK
  LATITUDE           DECIMAL
  LONGITUDE          DECIMAL

METRIC
  ID_METRIC          INTEGER PK
  METRIC_NAME        VARCHAR UNIQUE
  VALUE_TYPE         VARCHAR
    Allowed values = ('BOOLEAN', 'PERCENTAGE', 'INTEGER', 'DOUBLE', 'STRING')

TURBINE_METRIC
  ID_TURBINE_METRIC        INTEGER PK
  ID_TURBINE               INTEGER
     FOREIGN KEY TO TURBINE
  METRIC_NAME              VARCHAR
     FOREIGN KEY TO METRIC
  BOOLEAN_VALUE            BOOLEAN
  PERCENTAGE_VALUE         DOUBLE
  INTEGER_VALUE            INTEGER
  DOUBLE_VALUE             DOUBLE
  STRING_VALUE             VARCHAR

Fle sh, как вам нужно. Я не знаю, какой длины должны быть ваши поля VARCHAR и т. Д. c, но это позволяет вам гибко определять, какие метрики вы храните для каждой турбины. Я полагаю, вы могли бы также сделать метрики LATITUDE и LONGITUDE - я просто добавил их в таблицу TURBINE, чтобы показать, что там может быть фиксированная информация, которую лучше всего хранить как часть таблицы TURBINE.