Wielu właścicieli w pojedynczej bazie danych

W procesie przekształcania wykorzystywana jest poniższa konfiguracja własności tabel w systemowej bazie danych:

  • Właściciel produkcji jest połączony z tabelami, które są używane w systemie produkcyjnym. Te tabele mają ID właściciela o wartości CISADM.

  • Właściciel ładowania jest połączony z tabelami, do których należy wstawić dane przed sprawdzeniem. Te tabele mają ID właściciela o wartości CISSTG.

Schemat właściciela ładowania jest niemal identyczny ze schematem produkcyjnym, z następującymi wyjątkami:

  • Tabele kontrolne nie są rzeczywistymi tabelami w środowisku ładowania, a raczej widokiem odpowiadających im tabel produkcyjnych.

  • W schemacie ładowania istnieją tabele specyficzne dla przekształcenia, zaprojektowane wyłączanie w celu obsługi procesu przekształcenia. Są to na przykład tabele służące do zarządzania przydzielaniem kluczy i rozwiązaniem XML.

W tej sekcji opisano niektóre ważne koncepcje związane z właścicielami tych tabel.

Walidacja zawsze wykorzystuje dane kontrolne z produkcji

W momencie uruchomienia procesów zadań walidacji dla danych ładowania, procesy walidują te dane w tabelach pliku kontrolnego produkcji (i wstawiają błędy do tabeli błędów ładowania). Oznacza to, że instrukcje SQL, które uzyskują dostęp do jednostek lub je aktualizują, muszą korzystać z właściciela ładowania, podczas gdy instrukcje SQL, które uzyskują dostęp do tabel kontrolnych muszą korzystać z właściciela produkcji. Należy zauważyć, że kiedy te same procesy zadania walidacji działają na produkcyjnej bazie danych, instrukcje SQL nie mogą uzyskać dostępu do właściciela ładowania. Zamiast tego wszystkie wskazują na właściciela produkcji.

Droga do uzyskania takiej sytuacji wygląda następująco:

  • Dla każdego właściciela musi istnieć oddzielny serwer aplikacji. Każdy serwer aplikacji wskazuje na określony ID użytkownika bazy danych.
    Uwaga: w przypadku instalacji w chmurze serwer aplikacji w dowolnym momencie może wskazywać tylko na określony ID użytkownika bazy danych. Więcej informacji o przełączaniu właścicieli można znaleźć w sekcji "Obsługa przekształcania danych dla wdrożeń w chmurze".
  • W ID użytkownika bazy danych powiązanym z właścicielem ładowania dla właściciela tabel głównych i tabel transakcji używana jest wartość CISSTG , ale dla właściciela tabel pliku kontrolnego produkcji używana jest wartość CISADM.
  • W ID użytkownika bazy danych powiązanym z właścicielem produkcji dla właściciela wszystkich tabel używana jest wartość CISADM.

Użytkownik może się zastanawiać, dlaczego stwarzamy sobie taki problem. Istnieje kilka powodów:

  • Chcemy ponownie użyć logiki sprawdzania istniejącej w programach, które sprawdzają dane produkcyjne. Aby to osiągnąć takie rozwiązanie, programy te muszą czasami wskazywać na właściciela ładowania, a innym razem na właściciela produkcji (rozwiązanie to musi być transparentne dla programów, w innym wypadku konieczne będą dwa zestawy poleceń SQL).
  • Chcemy, aby w aplikacji możliwe było wyświetlanie i poprawianie danych ładowania. Można to osiągnąć, tworząc serwer aplikacji, który wskazuje na bazę danych ładowania z opisanymi wyżej charakterystykami własności.
  • Chcemy, aby programy sprawdzania mogły sprawdzać dane produkcyjne (poza danymi ładowania). Po co sprawdzać dane produkcyjne, jeśli do produkcji można dodawać tylko czyste dane? Rozważmy następujące przypadki:
    • Po aktualizacji użytkownik może sprawdzić dane produkcyjne, aby upewnić się, czy logika wyjścia użytkownika nadal działa.
    • Użytkownik może również przeprowadzić eksperyment dotyczący konsekwencji, zmieniając logikę sprawdzania. Aby tego dokonać, można tymczasowo zmienić logikę wyjścia użytkownika (w produkcji), a następnie uruchomić zadania sprawdzania w trybie losowego próbkowania.
    • Użytkownik zapomniał uruchomić program sprawdzania przed wypełnieniem produkcji i chce zobaczyć uszkodzenia. Jeśli instrukcje z tego dokumentu będą wykonywane we właściwej kolejności, taka sytuacja nie powinna się nigdy zdarzyć. Wypadki się jednak zdarzają. Jeśli się jednak zdarzą, można je rozwiązać, określając konsekwencje.

Tylko walidacja może działać dla obu właścicieli

Skoro przekierowanie ID właściciela jest użyteczną metodą w procesach zadania walidacji, dlaczego nie można jej użyć w procesach zadań przydzielania klucza i wstawiania danych produkcyjnych? Ponieważ te procesy muszą mieć dostęp do tych samych tabel, ale różnych właścicieli w tym samym czasie. Muszą one również odwoływać się do tabel specyficznych dla przekształcania, które nie istnieją w środowisku produkcyjnym. Na przykład proces zadania służący do wstawiania wierszy w środowisku produkcyjnym musi wybierać wiersze z odpowiadającej tabeli ładowania, rozstrzygać klucze z tabel odwzorowania starego/nowego klucza na potrzeby przekształcenia i wstawiać rozstrzygnięte rekordy do tabeli produkcyjnej.

Droga do uzyskania takiej sytuacji wygląda następująco:

  • W środowisku ładowania dla każdej tabeli kwalifikującej się do przekształcenia istnieje widok wersji produkcyjnej. Te widoki mają na stałe zakodowanego właściciela bazy danych wskazującego na środowisko produkcyjne. Na przykład istnieje widok o nazwie CX_PER, który wskazuje na tabelę osoby w produkcji.
  • Programy przydzielania kluczy i wstawiania korzystają z tych widoków, gdy wymagany jest dostęp do danych produkcyjnych.