SCD typu II z podmiotami, które łączą się w czasie

Question

Załóżmy, że mamy wymiar reprezentujący biura sprzedaży. Biura mogą się poruszyć, co oznaczałoby zmianę typu II. Chcielibyśmy śledzić operacje, które miały miejsce w lokalizacji starego biura, i operacje, które teraz będą miały miejsce w nowym, i wiedzieć, kiedy nastąpiła zmiana. Jak dotąd, tylko standardowy projekt typu II. Teraz powiedzmy, że biuro łączy się z innym biurem. Oznacza to, że działalność operacyjna dwóch pierwotnie odrębnych urzędów ("biur macierzystych") odbywa się obecnie w jednym biurze ("połączonym biurze"), co może być kontynuacją (fizycznie lub pod względem personelu) jednego lub dwóch pierwotnych biur, lub może to być nowe biuro, to znaczy z biznesowego punktu widzenia kontynuacja poprzednich dwóch.

Wymagania/analiza sprawozdań są następujące:

• Chcemy, aby móc zobaczyć wszystkie bieżącej działalności do nowego biura scalonego.
• Chcemy widzieć wszystkie czynności, które kiedykolwiek zostały wykonane przez połączone biuro lub przez biura macierzyste.
• Chcemy mieć możliwość zobaczenia w czasie aktywności, która miała miejsce w jednym z biur macierzystych zarówno przed, jak i po fuzji, bez oglądania aktywności z drugiego biura macierzystego (przynajmniej przed połączeniem).

Nie jestem pewien, jak to modelować z dowolnym typem SCD. Jeśli po prostu zastąpimy dwie pozycje nadrzędnego biura pojedynczą nową i zaktualizujemy odpowiednio wszystkie tabele faktów, to zmienimy typ. To pozwala nam zobaczyć bieżącą aktywność w porządku, ale tracimy historię. Jeśli zachowamy oddzielne zapisy, nie dowiemy się o fuzji. Jeśli dodamy trzeci rekord do reprezentowania połączonego biura, stracimy także historię (który klucz naturalny by miał - żaden z kluczy naturalnych urzędów macierzystych nie byłby odpowiedni).

Czy muszę używać tabeli mostów/wielu do wielu? To wprowadza złożoność, której chciałbym uniknąć. Jeśli jednak jest to najlepszy sposób, to niech tak będzie. Nadal nie jestem pewien, jak to będzie zorganizowane. Być może tabela faktów wskazywałaby na wpis w biurze, a biura byłyby zgrupowane w wiele do wielu. Raportowanie byłoby przeprowadzane na podstawie grup, a nie bezpośrednio w wymiarze biura.

Odpowiedzi na ElectricLlama na pytania

• Większość interakcji z użytkownikiem odbywa się za pomocą gotowych raportów, więc każdy złożoność z podstawowej struktury będzie ukryta przed nimi.
• Niektórzy użytkownicy używają SQL lub SAS, aby uzyskać dostęp do danych. W tej chwili jest mało prawdopodobne, aby zajmowali się tym konkretnym problemem, ale to może się zmienić, ponieważ wprowadzamy więcej użytkowników za pomocą tych narzędzi.
• Nie mamy pisarza zapytań w tym miejscu.
• Nie sądzę, że będą fuzje wielopoziomowe, ale nie mogę definitywnie odmówić. Byłbym zaskoczony, gdyby tak było.
• Nie wiem, jak uczynić tego rodzaju rzeczy łatwym dla użytkownika końcowego, co może być argumentem wystarczającym do złagodzenia pewnych wymagań.

Answer 1

Wolałbym najprostsze możliwe rozwiązanie, które klient mógłby zaakceptować, więc zrobiłbym następujące. chciałbym zapewnić dwa biura terenowego w wymiarze biurowej:

1. Office_as_today
2. Office_original

(oczywiście trzeba wybrać nazwy, które są dobre dla klienta) na początku tych dwóch pola będą ustawione równe. Kiedy dwa biura się połączą, powrócę do dwóch oryginalnych biur i zaktualizuję pole Office_as_today, z nazwą połączonego biura.

Nowe fakty (od scalenia) zostaną zarejestrowane w nowym wierszu z dwoma polami ponownie równymi.

Rozwiązanie jest bardzo proste i spełnia niemal wszystkie wymagania, z wyjątkiem braku możliwości śledzenia oryginalnych biur po scaleniu (tutaj podkreślam twoje "co najmniej").