Oracle "псевдо-факт" вид - PullRequest
Новая
       13

Oracle "псевдо-факт" вид

1 голос
/ 13 мая 2011

Предположения:

  1. У меня есть несколько таблиц, состоящих из фактов и внешних ключей (тип «мерный» и «ключ-значение»). Например, ENCOUNTER:

ID - первичный ключ

размеры

  • LOCATION_ID
  • PATIENT_ID

ключ-значение

  • TYPE_ID
  • STATUS_ID
  • PATIENT_CLASS_ID
  • DISPOSITION_ID
  • ...

факты

  • ADMISSION_DATE
  • DISCHARGE_DATE

  • ...

    1. У меня нет возможности создать хранилище данных
    2. Я хотел бы упростить структуру данных для отчетности

Мой подход заключается в создании ряда псевдомерных представлений («D_LOCATION» на основе таблиц DEPARTMENT и LOCATION) и представлений псевдо-фактов («F_ENCOUNTER» на основе таблицы ENCOUNTER). В представлении псевдо-фактов я бы присоединил таблицы значений ключей (например, STATUS, PATIENT_CLASS) к таблице фактов, чтобы включить поля имен (например, STATUS.NAME, PATIENT_CLASS.NAME).

Вопросы:

  • Если запрос выбирает подмножество всех полей из F_ENCOUNTER (т. Е. Не все поля key-value.name), достаточно ли умен оптимизатор Oracle 10g, чтобы исключить некоторые из соединений таблицы ключ-значение (т. Е. те, которые не включены в запрос)?
  • Что я могу сделать, чтобы оптимизировать эту архитектуру (кроме индексов)
  • Есть ли другой подход?

** редактировать ** Цели (в порядке важности):

  • уменьшить сложность запроса; повысить согласованность запросов; уменьшить время разработки отчета
  • оптимизировать обработку запросов
  • минимизировать нагрузку администратора
  • уменьшение хранилища

Ответы [ 2 ]

1 голос
/ 13 мая 2011

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

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

0 голосов
/ 13 мая 2011
  • Я не верю, что Oracle исключил бы любые объединения, сделанные в представлении, потому что объединения могут влиять на количество возвращаемых строк.(Например, когда внутреннее объединение не соответствует ни одной строке, что делает весь набор результатов пустым.)
  • Каковы цели вашей оптимизации?Скорость запроса?простота запроса?эффективность хранения?Если вы можете пожертвовать эффективностью хранения для повышения производительности запросов, замените ссылки ключ-значение самими значениями (TYPE_NAME вместо TYPE_ID, PATIENT_CLASS_NAME вместо PATIENT_CLASS_ID и т. Д.).
  • [Редактировать:] Если исходная архитектура не может быть изменена, рассмотрите возможность использования материализованного представления.По существу, он будет предварительно вычислять объединения и сохранять результирующий набор, предоставляя вам быстрое время запроса за счет дополнительного пространства для хранения и, возможно, не свежих данных.Вы можете управлять последним, указав соответствующую политику обновления.Подробнее см. http://en.wikipedia.org/wiki/Materialized_view и http://download.oracle.com/docs/cd/B10500_01/server.920/a96520/mv.htm.
...