Кто-либо знает что-нибудь о Внутренностях OLAP?

Question

Кто-либо знает что-нибудь о Внутренностях OLAP?

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

struct Level {
    var values: [String]
}

struct Stage {
    var levels: [Level]
}

let stages = [
    Stage(levels: [
        Level(values: ["One", "Two"])
        Level(values: ["Horse", "Shoe"]),
        Level(values: ["One", "Two"]),
        ]),
    Stage(levels: [
        Level(values: ["Snow", "Sun"]),
        Level(values: ["Smile", "Cry"]),
        Level(values: ["Five", "Six"]),
        ]),
]

var currentStage = 1
var currentLogo = 2

// Remember that arrays are 0-indexed. If "currentStage" is 1-indexed
// you need to adjust it
let level = stages[currentStage - 1].levels[currentLogo - 1]
let words = level.values

if let text = textFieldChangedOut.text, words.contains(text) {
    print("Contains the value")
}

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

28

cubes olap theory data-structures algorithm

задан Steve 10 April 2009 в 21:19

1 ответ

Другие вопросы по тегам:

cubes olap theory data-structures algorithm

Похожие вопросы:

score 19 · Accepted Answer

Я реализовал пару систем, которые имитировали то, что делают кубы OLAP, и вот пара вещей, которые мы сделали чтобы заставить их работать.

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

2) Базовый массив часто был редким, поэтому, как только он был создан, мы использовали, чтобы удалить все пустые ячейки, чтобы сохранить память - много жесткой арифметики указателя ядра, но это работало.

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

4) Мы не реализовали какой-либо язык запросов, но мы поддерживали детализацию по всем осям (до 7 в нашей самой большой кубы), и это было напрямую связано с пользовательским интерфейсом, который понравился пользователям.

5) Мы реализовали основные функции в C ++, но в наши дни я считаю, что C # может быть достаточно быстрым, но я бы беспокоился о том, как реализовать разреженные массивы

Надеюсь, это поможет, звучит интересно.