Обработка измерения «многие ко многим», когда все значения измерений имеют 100% важность

Question

Я по крайней мере постараюсь сохранить эту краткость.

Предположим, мы отслеживаем остатки на счетах с течением времени.Таким образом, в нашей таблице фактов будут столбцы, такие как ...

Таблица фактов баланса счета

• (FK) AccountID
• (FK)DateID
• ...
• Баланс
• ...

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

Но вот к чему больше всего ... Учетные записи могут принадлежать группам - любое количество групп на определенную дату.Группы - это просто логические абстракции, и они не имеют осмысленного значения, кроме целей отчетности.Аккаунт из 0, 1 или 17 групп никак не влияет на его баланс.Например, AccountID 1 может быть в группах 38, 76, 104 и 159. Учетная запись 2 может быть в группе 1 (которая имеет описание группы «Негруппированный». Учетная запись 3 может быть в семнадцати группах (реальный пример).

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

Итак, давайте посмотрим на наши варианты ...

Булев метод Булев метод неосуществим. У нас около 570 000 различных учетных записей, но, что более важно, 26 000 различных групп. Это также было быдьявол для конечных пользователей, чтобы фильтровать, так как они нетехнические и полагаются наg на очень простых инструментах, чтобы сделать это.

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

Таблица бриджа Этот подсчет работает, но у нас есть 26 000 различных групп.Я не нахожу это удобным для пользователя.

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

---

ОБНОВЛЕНИЕ: Для пояснения, пример, который я думаю, что каждый здесь может относиться, - представьте, что вы можете перечислитьнавыки ключевых слов в резюме.Все они относятся к одному и тому же человеку, но вы можете иметь любое количество навыков.Навыки не влияют ни на одну из отдельных мер на резюме - то есть «C ++» не более ценен, чем «C #» - вы не можете поместить все комбинации резюме / навыка в таблицу фактов, иначе вы бы закончилидо двойного счета (или более чем в два раза;)).

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

Так что теперь у нас есть ...

Таблица фактов баланса счета

• (FK) AccountID
• (FK) DateID
• ...
• Баланс
• ...

Размер учетной записи

• (PK) AccountID
• Имя учетной записи
• ...
• (FK) Ключ группы счетов

Аутригер группы счетов

• (PK) AccountGroupID
• (PK) AccountID)
• Название группы счетов

Answer 1

Я бы сказал, что вы должны начать с интерфейса. Как бы пользователи хотели выполнять фильтрацию в идеальном мире?

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

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

Answer 2

Если я правильно понял ваш вопрос, все будет в порядке:

CREATE TABLE IF NOT EXISTS `accounts` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;

CREATE TABLE IF NOT EXISTS `accounts_groups` (
  `account_id` int(11) NOT NULL,
  `group_id` int(11) NOT NULL,
  `start_date` date NOT NULL,
  `end_date` date DEFAULT NULL,
  UNIQUE KEY `account_group` (`account_id`,`group_id`,`start_date`),
  KEY `group_id` (`group_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

CREATE TABLE IF NOT EXISTS `account_balances` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `account_id` int(11) NOT NULL,
  `date` date NOT NULL,
  `balance` decimal(11,2) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `account_id` (`account_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;

CREATE TABLE IF NOT EXISTS `groups` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;

ALTER TABLE `accounts_groups`
  ADD CONSTRAINT `accounts_groups_ibfk_1` FOREIGN KEY (`account_id`) REFERENCES `accounts` (`id`),
  ADD CONSTRAINT `accounts_groups_ibfk_2` FOREIGN KEY (`group_id`) REFERENCES `groups` (`id`);

ALTER TABLE `account_balances`
  ADD CONSTRAINT `account_balances_ibfk_1` FOREIGN KEY (`account_id`) REFERENCES `accounts` (`id`);