В вашей таблице 3 столбца, каждый из которых представляет уровень детализации, плюс столбец с ценой. Уровни детализации: от наивысшего до самого низкого уровня абстракции: Имя , код и SLNO .
Есть 3 записи в Таблица. Одна запись - A.A1.1, со значением цены 10. Вторая - A.A1.2, также со значением 10. Третья - A.A2.3, со значением цены 20. Цена, вероятно, указана как мера с совокупной суммой.
В вашем отчете используются имя и цена. Из-за того, что было смоделировано, вы получаете 4 записи, в сумме равные 40.
Вы не думаете, что это правильно, но вам нужно понимать, что, как это было смоделировано, это так.
Впоследствии, учитывая, что вы говорите, что это не то, что является характером ситуации, вам необходимо понять, какова природа рассматриваемых объектов, и, таким образом, вооружившись, затем определить эту природу, что затем позволит нам определить, как смоделируйте его.
Почему вы хотите, чтобы цена A была 30? Какое бизнес-правило определяет это? Какова природа цены? Почему не предполагается агрегировать значения для SLNO 1 и SLNO 2? Дело в том, что зерно для цены - это код, а не SLNO?
Цена - это атрибут или мера? Без дополнительной информации я бы сказал, что это первое, а не второе, поскольку обычно цена слова ассоциируется как фиксированное (по крайней мере, во временном интервале, но, возможно, переменное в более длительном временном интервале) значение, присвоенное объекту.
(вы можете использовать атрибуты в мерах, например, вы можете использовать цену * количество для определения выручки от продажи)
Предполагая, что зернистость факта цены является кодом, а не SLNO, тогда вам следует рассмотреть возможность моделирования соответствующей цепочки зависимостей столбцов Имя ---> Код ---> SLNO с ценой в группе кода. Вам также следует подумать о природе ключей.
Это предварительное значение, учитывая неопределенности.