Drukuj      Otwórz Pomoc bezpośrednią w wersji PDF


Poprzedni temat

Następny temat

Projektowanie struktur rejestrów — informacje podstawowe

Aby ustanowiona struktura rejestrów była efektywna, trzeba starannie zaplanować hierarchie rejestrów. Projektując i dopracowując hierarchie rejestrów dla swojej firmy, warto skorzystać z następujących wytycznych:

  • Nie tworzyć standardowych rejestrów powielających rejestry użytkowników.
  • Ustalić organizację danych biznesowych oraz zasady dostępu do nich.
  • Sprawdzić, czy struktura korporacyjna jest właściwa dla procesu zarządzania danymi.
  • Ustalić przynależność danych w obrębie firmy.
  • Zaprojektować rejestry zgodnie z potrzebami użytkowników oraz rozważyć zadania, przy których wykonywaniu użytkownicy najczęściej korzystają z rejestrów.
  • Zaprojektować rejestry tak, aby funkcjonalność wynikająca z pola wyboru "Włączona widoczność dla kierownika" (w profilu firmy) była możliwie rzadko używana.
  • Utrzymywać możliwie minimalną liczbę poziomów w hierarchiach rejestrów.
  • W możliwie maksymalnym stopniu zredukować liczbę podwójnych notowań w strukturze rejestrów. Podwójne notowania to praktyka polegająca na duplikowaniu rekordów w różnych rejestrach.
  • Używać reguł procesu Workflow do automatyzacji zarządzania rejestrami. Ponadto, podczas projektowania nazw rejestrów należy rozważyć wykorzystanie funkcji, która umożliwia użycie jednej czynności procesu Workflow do przydzielania innego rejestru do różnych rekordów za pomocą wyrażenia, które odnajduje nazwę rejestru.

Rejestry użytkowników

Wadą tworzenia niestandardowych rejestrów powielających rejestry użytkowników jest to, że dane w obu tych typach rejestrów muszą być synchronizowane. Dodatkowe zadanie wydłuża czas przetwarzania przez serwer i wpływa na szybkość pobierania rekordów.

UWAGA: Jedną z przyczyn, dla których w firmie rozważa się powielanie (replikację) rejestrów użytkowników, jest konieczność zapewnienia użytkownikowi tymczasowego dostępu do danych innego użytkownika. Lepszym sposobem spełnienia tego wymogu jest dodanie użytkownika, który potrzebuje dane, jako pełnomocnika użytkownika będącego właścicielem tych danych.

Potrzeba dostępu do danych

Struktura rejestrów nie musi odzwierciedlać korporacyjnej hierarchii w firmie. Zamiast tego zaleca się, aby struktura rejestrów możliwie ściśle odzwierciedlała sposób organizowania danych w firmie. Część może być organizowana według położenia geograficznego, a część np. według produktu czy branży. Należy zwrócić szczególną uwagę na sytuacje, w których:

  • Dwa lub większa liczba wydziałów nie mogą uzyskiwać dostępu do danych należących do innego wydziału.
  • Dwa lub większa liczba wydziałów muszą mieć możliwość uzyskania dostępu do danych należących do innego wydziału.

Adekwatność struktury korporacyjnej

W wielu firmach organizacja nadrzędna ma pełny dostęp do wszystkich danych w organizacjach podrzędnych. Członkowie takiej organizacji nadrzędnej zazwyczaj mają globalny dostęp do danych ze wszystkich organizacji podrzędnych.

Mając do czynienia z taką strukturą, zaleca się, aby nie konfigurować rejestrów w sposób odzwierciedlający strukturę organizacyjną na poziomie organizacji nadrzędnej. Należy jednak rozważyć:

  • Skonfigurowanie rejestrów odzwierciedlających strukturę organizacyjną na innych poziomach (takich jak poziom organizacji podrzędnej).
  • Skonfigurowanie innych hierarchii rejestrów na poziomie organizacji nadrzędnej. Na przykład na poziomie organizacji nadrzędnej można utworzyć hierarchię rejestrów umożliwiającą użytkownikom z organizacji nadrzędnej wyświetlanie — ze wszystkich organizacji podrzędnych — możliwości o potencjalnie dużym przychodzie.

Przynależność danych

Należy sprawdzić obowiązujące w firmie procedury dotyczące przenoszenia użytkownika z jednego wydziału do innego. Przykład:

  • Jeśli dane, którymi użytkownik zarządza, są zawsze przenoszone wraz z użytkownikiem do nowego wydziału (przynależność danych nie ulega zmianie), to najlepiej jest zarządzać danymi poprzez prawa własności rekordów i poprzez funkcje zespołów. Zazwyczaj umówione spotkania i zadania są przenoszone wraz z użytkownikiem na wszystkich poziomach. W niektórych środowiskach handlowych wszystkie dane klientów są przenoszone wraz z użytkownikiem. Taka przynależność danych zazwyczaj obowiązuje w małych i średnich przedsiębiorstwach oraz w firmach koncentrujących się na sprzedaży o małym wolumenie, lecz o dużej wartości.
  • Jeśli dane zawsze są organizowane w sposób niezmienny (np. jest stosowana organizacja geograficzna), tak że występuje organizacyjne prawo własności danych, to najlepiej jest zarządzać nimi poprzez rejestry odzwierciedlające strukturę organizacyjną.
  • Jeśli przez jakiś czas po przeniesieniu użytkownika do innego wydziału obowiązują zarówno przynależność danych do użytkownika, jak i organizacyjne prawo własności, to te dwie hierarchie mogą istnieć jednocześnie.

Potrzeby i zadania użytkowników

Projektując strukturę rejestrów, należy rozważyć zadanie, przy którego wykonywaniu użytkownicy najczęściej korzystają z rejestrów (w tym praca z listami, wyszukiwanie rekordów oraz tworzenie raportów i korzystanie z nich).

Praca z listami

W celu rozpoznania list potrzebnych użytkownikom należy ustalić, jakiego typu listy są najczęściej używane i jakie listy byłyby idealne dla użytkowników. Można tu zapytać się o zdanie użytkowników. Jeśli żaden rejestr ze struktury rejestrów nie zawiera wszystkich rekordów niezbędnych dla idealnej listy, to w strukturze rejestrów prawdopodobnie brakuje hierarchii. Można na przykład skonfigurować zarówno hierarchię geograficzną, jak i hierarchię ukierunkowaną na produkty.

Jeśli użytkownicy wiele czasu pracują z określonym podzbiorem jednego rejestru, warto utworzyć z tego podzbioru rejestr podrzędny. Nadać mu nazwę umożliwiającą użytkownikom rozpoznanie go. Taki rejestr podrzędny można ustawić jako domyślny w selektorze rejestrów, aby użytkownicy nie musieli go wybierać za każdym razem. Więcej informacji o ustawianiu wartości domyślnej selektora rejestrów znajduje się pod hasłem Włączanie rejestrów dla użytkowników i ról użytkowników.

Wyszukiwanie rekordów

Aby ustalić potrzeby użytkowników w zakresie wyszukiwania rekordów, należy wypytać użytkowników o sytuacje, w których szukają konkretnych rekordów. Struktura rejestrów i rozmiary rejestrów powinny odzwierciedlać najczęściej przeprowadzane operacje wyszukiwania oraz stosowane kryteria wyszukiwania.

UWAGA: Jeśli jest dopracowywana już istniejąca struktura rejestrów, należy wypytać użytkowników, czy zazwyczaj potrafią rozpoznać, że dany rekord pochodzi z konkretnego rejestru w hierarchii. Jeśli użytkownicy zgodnie twierdzą, że mają pewność tylko co do rejestru na wyższym poziomie, należy zapytać ich, czy inny podział struktury rejestrów umożliwiłby im zawężenie prowadzonych wyszukiwań. Przeszukiwanie rejestrów wyższych poziomów powinno być przeprowadzane tylko w wyjątkowych sytuacjach stanowiących odstępstwo od zwykłych przeszukiwań.

Na szybkość wyszukiwania rekordów mają także wpływ pola użyte podczas wyszukiwania:

  • Używając indeksowanych pól do wyszukiwania rekordów w rejestrach, uzyskuje się optymalną wydajność. (Indeksowane pola są w sekcjach wyszukiwania wyświetlane z użyciem zielonej czcionki.)
  • Jeśli do wyszukiwania rekordów w rejestrach są zamiast indeksowanych pól używane pola nieindeksowane, to wyszukiwanie odbywa się wolniej, a na wydajność ma wpływ liczba przeszukiwanych rekordów. (Nieindeksowane pola są w sekcjach wyszukiwania wyświetlane z użyciem czarnej czcionki.)

Na przykład, jeśli zostanie stwierdzone, że użytkownicy zazwyczaj wyszukują rekordy osób kontaktowych, posługując się indeksowanymi polami, to liczba rekordów w rejestrze najniższego poziomu (zwanym rejestrem węzła-liścia) może dla każdego z typów rekordów osiągnąć liczbę do 100 000. Jeśli jednak użytkownicy zazwyczaj wyszukują rekordy osób kontaktowych, posługując się nieindeksowanymi polami, to rozmiar rejestrów najniższego poziomu można ograniczyć do 20 000–30 000 dla każdego z typów rekordów.

Konfiguracja danych jest różna w różnych firmach. Dlatego też nie ma zalecanej liczby rekordów w rejestrach. Rozmiarami rejestrów trzeba zarządzać w sposób ciągły. Rejestry umożliwiają szybsze wyszukiwanie poprzez zredukowanie liczby przeszukiwanych rekordów.

Tworzenie raportów i korzystanie z nich

Do wszystkich użytkowników, z wyjątkiem administratorów, są stosowane reguły widoczności danych w raportach. Jeśli w selektorze rejestrów używanym do raportów określono rejestr użytkowników lub rejestr niestandardowy, w raportach są uwzględniane następujące dane:

  • Cała zawartość analiz historycznych (w tym analiz historycznych uzyskiwanych z poziomu kart "Raporty" i "Pulpity informacyjne") jest ograniczona do rejestru i obejmuje wszystkie poziomy podrzędne wybranego rejestru. Rekordy, których właścicielem jest użytkownik lub zespół użytkownika, nie są uwzględniane, chyba że są również zawarte w wybranym rejestrze lub w jednych z jego rejestrów podrzędnych.
  • Raporty tworzone w czasie rzeczywistym są ograniczone do danych powiązanych bezpośrednio z rejestrem (rejestrem niestandardowym lub rejestrem użytkowników) wybranym w selektorze rejestrów. Jeśli wybrany rejestr ma rejestry podrzędne lub mu podporządkowane, dane z nich są pomijane w raportach tworzonych w czasie rzeczywistym.

UWAGA: Mimo że zazwyczaj nie trzeba zmieniać ustanowionej struktury rejestrów, to jednak można to zrobić. Aby wprowadzić takie zmiany nie trzeba stosować żadnych wyłączeń systemu — zmiany są od razu stosowane. Zmiany te nie są jednak natychmiast odzwierciedlane w raportach tworzonych w czasie rzeczywistym.

Więcej informacji o widoczności rekordów w raportach znajduje się pod hasłem Raporty.

Widoczność dla kierownika

Projektując hierarchie rejestrów, należy uwzględniać następujące zasady:

  • Funkcjonalność wynikająca z pola wyboru "Włączona widoczność dla kierownika" (w profilu firmy) powinna być możliwie rzadko używana.
  • Opcja "Uwzględnij pozycje podrzędne" jest rzadko używana lub nigdy nieużywana podczas przeszukiwania dużych wolumenów danych. (Liczba rekordów, którą określa się mianem dużego wolumenu jest różna w różnych firmach i zmienia się w zależności od wzorca wyszukiwania.)

    Istnieją sytuacje, w których trzeba użyć opcji "Uwzględnij pozycje podrzędne". Na przykład kierownicy potrzebują uzyskiwać listy oparte na rejestrach użytkowników, wśród których występują podwładni, ponieważ podwładni nie mogą wzajemnie udostępniać sobie danych. W przypadku dużych wolumenów czas wyszukiwania ulega wydłużeniu. W celu uzyskania optymalnej wydajności należy korzystać z opcji "Uwzględnij pozycje podrzędne" jedynie wtedy, gdy jest to faktycznie niezbędne.

Poziomy hierarchii

Hierarchie rejestrów z dużą liczbą poziomów i rekordami na każdym poziomie funkcjonują podobnie do struktur zespołowych, w których jest włączona widoczność dla kierownika. Takie hierarchie dobrze się sprawdzają w przypadku małych zbiorów danych. Jeśli jednak wolumen danych rośnie, rejestry z niewielką liczbą poziomów hierarchii (lub bez poziomów hierarchii) działają o wiele lepiej niż struktury zespołowe.

Jeśli któryś z poziomów hierarchii rejestrów nie wnosi nic do zabezpieczeń danych bądź do organizacji danych, to taki nadmiarowy rejestr (oraz jego rejestry podrzędne) należy scalić. Można wypytać użytkowników, czy zazwyczaj potrafią rozpoznać, czy jakiś rekord znajduje się w tym bądź w innym rejestrze podrzędnym tego samego rejestru nadrzędnego; jeśli nie potrafią tego rozróżnić, to najlepszym rozwiązaniem jest zwinięcie obu rejestrów podrzędnych do ich rejestru nadrzędnego.

Prostym sposobem zmniejszenia liczby poziomów w hierarchii rejestrów jest używanie w nazwach rejestrów podrzędnych nazwy rejestru nadrzędnego jako prefiksu. Na przykład, mając rejestr podrzędny o nazwie "Północ", którego rejestrem nadrzędnym jest rejestr "Europa", można usunąć rejestr nadrzędny i zmienić nazwę rejestru podrzędnego na "EU - Północ".

Podwójne notowania

Podwójne notowania to praktyka polegająca na duplikowaniu rekordów w różnych rejestrach. Podwójne notowania przyczyniają się do zwiększenia obciążeń użytkowników, ponieważ trzeba przeprowadzać synchronizację, co z kolei prowadzi do wielu operacji "odczyt-zapis" mających negatywny wpływ na wydajność serwera. Podwójne notowania należy stosować w możliwie minimalnym stopniu.

Zautomatyzowane zarządzanie rejestrami

Zazwyczaj kryteria przydziału rejestrów są odwzorowywane na jedno lub większą liczbę pól w typie rekordów. Można utworzyć regułę procesu Workflow, która automatycznie zmieni przydział rejestru, gdy zmieni się wartość w jednym z tych pól.

Na przykład, mając hierarchię rejestrów o nazwie Terytorium, można utworzyć regułę procesu Workflow, która będzie monitorowała pole w typie rekordów (na przykład pole "Terytorium" dla podmiotów), a następnie dla tej reguły utworzyć czynność "Przydziel rejestr" aktualizującą rejestr "Terytorium" dla rekordu, gdy ulegnie zmianie wartość pola "Terytorium" podmiotu.

Podczas projektowania nazw rejestrów należy rozważyć wykorzystanie czynności procesu Workflow "Przydzielanie rejestru" w sposób, który umożliwia użycie jednej czynności procesu Workflow do przydzielania innego rejestru do różnych rekordów za pomocą wyrażenia, które odnajduje nazwę rejestru.

Załóżmy na potrzeby przykładu, że użytkownik ma podmioty w Ameryce Północnej oraz podmioty na obszarze EMEA. Użytkownik może chcieć założyć dwa oddzielne rejestry dla różnych lokalizacji i przydzielić odpowiedni rejestr do podmiotu w zależności od lokalizacji tego podmiotu. Aby ustawić tę konfigurację, można utworzyć dwa rejestry - jeden o nazwie Ameryka Północna, a drugi o nazwie EMEA. Można następnie utworzyć niestandardowe pole listy wyboru o nazwie "Lokalizacja sprzedaży" z wartościami "Ameryka Północna" i "EMEA" oraz dodać niestandardowe pole do układu strony dla typu rekordu "Podmiot" dla odpowiednich ról. Następnie można utworzyć czynność procesu Workflow "Przydzielanie rejestru", która wykonuje następujące czynności, gdy rekord podmioty zostanie zaktualizowany:

  • Ocenia wyrażenie w celu określenia wartości, która jest wybierana w polu "Lokalizacja sprzedaży" w rekordzie podmiotu.
  • Tworzy powiązanie rekordu podmiotu z rejestrem, którego nazwa jest zgodna z wartością zwróconą przez wyrażenie.

Tematy pokrewne

Pokrewne informacje są zawarte w następującym temacie:


Opublikowano: Październik 2016 Copyright © 2005, 2016, Oracle. Wszelkie prawa zastrzeżone. Legal Notices.