Model danych dla analizy

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Model danych analizy dla usługi Azure DevOps składa się z zestawów jednostek, których elementy członkowskie (jednostki) zawierają właściwości, które można filtrować, agregować i podsumowywać. Ponadto zawierają właściwości nawigacji, które odnoszą jednostki do siebie, zapewniając dostęp do innych właściwości do wybierania, filtrowania i grupowania.

Omówienie modelu danych analizy

Usługa Analiza zapewnia ustrukturyzowane podejście do uzyskiwania dostępu do danych usługi Azure DevOps za pośrednictwem punktów końcowych OData. Ten model danych umożliwia:

• Wykonywanie zapytań dotyczących danych śledzenia pracy: uzyskiwanie dostępu do elementów roboczych, obszarów, iteracji i powiązanych metadanych
• Analizowanie informacji o potoku: wykonywanie zapytań dotyczących danych potoku kompilacji i wydania
• Raport dotyczący wyników testów: Uzyskiwanie dostępu do danych dotyczących wykonywania testów i planowania
• Tworzenie niestandardowych raportów: Tworzyć raporty w Power BI i tworzyć inne rozwiązania analityczne

Przestrzenie nazw schematów

Model danych analitycznych działa w dwóch przestrzeniach nazw schematu:

• Microsoft.VisualStudio.Services.Analytics.Model
• Microsoft.VisualStudio.Services.Analytics

Te przestrzenie nazw organizują jednostki i definiują ich strukturę, zapewniając spójne wzorce dostępu do danych w różnych funkcjach usługi Azure DevOps.

Zestawy jednostek i typy jednostek

Typy jednostek są nazywane typami ustrukturyzowanymi z kluczem. Definiują one nazwane właściwości i relacje każdej jednostki. Klucz EntityType powstaje z podzbioru podstawowych właściwości — na przykład WorkItemId, PipelineId, ReleasePipelineId — oraz innych właściwości typu encji.

Zestawy jednostek są nazwane kolekcjami jednostek. Na przykład WorkItems to zestaw jednostek zawierający WorkItem jednostki. Klucz jednostki jednoznacznie identyfikuje jednostkę w zestawie jednostek. Jeśli wiele zestawów jednostek używa tego samego typu jednostki, ta sama kombinacja wartości kluczy może pojawić się w więcej niż jednym zestawie jednostek i zidentyfikować różne jednostki, jeden na zestaw jednostek, w którym pojawia się ta kombinacja. Każda z tych jednostek ma inny identyfikator jednostki. Zestawy jednostek zapewniają punkty wejścia do modelu danych.

Zestawy jednostek są opisane w metadanych OData i różnią się w zależności od projektu. Pełną listę zestawów jednostek, typów jednostek i właściwości można eksplorować, żądając metadanych OData dla projektu. Aby dowiedzieć się, jak to zrobić, zobacz Konstruowanie zapytań OData na potrzeby analizy.

Jednostki złożone

Jednostki złożone obsługują określone scenariusze. System komponuje je z prostszych jednostek, często wymaga więcej zasobów obliczeniowych do wygenerowania i może zwrócić większe zestawy wyników. Aby uzyskać najlepszą wydajność i uniknąć niepotrzebnego ograniczania przepustowości, upewnij się, że wykonasz zapytanie o poprawną jednostkę dla danego scenariusza.

Na przykład WorkItemSnapshot łączy WorkItemRevisions i Dates w taki sposób, że każda data ma jedną poprawkę dla każdego elementu roboczego. Ta reprezentacja obsługuje zapytania OData, które koncentrują się na danych trendu dla filtrowanego zestawu elementów roboczych. Nie należy jednak używać tej jednostki złożonej do wykonywania zapytań dotyczących bieżącego stanu elementów roboczych. Zamiast tego należy użyć WorkItems zestawu jednostek, aby szybciej generować uruchomione zapytanie.

Podobnie niektóre jednostki mogą zawierać wszystkie wartości historyczne, a inne mogą zawierać tylko bieżące wartości. WorkItemRevisions zawiera całą historię elementów roboczych, których nie należy używać w scenariuszach, w których bieżące wartości są interesujące.

Relacje

Aby wygenerować bardziej złożone wyniki zapytania, można połączyć jednostki przy użyciu relacji. Relacje można stosować do rozszerzania, filtrowania lub podsumowywania danych.

Niektóre właściwości nawigacji powodują utworzenie pojedynczej jednostki, a inne powodują zbieranie jednostek. Na poniższym diagramie przedstawiono wybieranie jednostek i ich właściwości nawigacji. W celu zapewnienia przejrzystości pominięto niektóre złożone jednostki i relacje.

Informacje o relacjach między jednostkami

Model danych analizy używa kilku typów relacji:

• Jeden do wielu: jedna jednostka nadrzędna odnosi się do wielu jednostek podrzędnych (np. jednego obszaru do wielu elementów roboczych)
• Wiele do jednego: wiele jednostek odnosi się do pojedynczej jednostki nadrzędnej (np. wiele elementów roboczych do jednego obszaru)
• Jeden do jednego: jedna jednostka jest powiązana z dokładnie jedną inną jednostką
• Wiele do wielu: Wiele encji jest powiązanych z wieloma innymi encjami (np. Elementy robocze do tagów)

Klucze relacji

Relacje między jednostkami są również reprezentowane jako klucze obce, dzięki czemu narzędzia zewnętrzne mogą łączyć jednostki. Te właściwości mają sufiks "SK" i są typami danych: liczba całkowita lub GUID. Właściwości daty mają odpowiadające właściwości klucza daty liczbowej o następującym formacie: RRRRMMDD.

Typy jednostek i zestawy jednostek śledzenia pracy

Następujące typy jednostek i zestawy jednostek są obsługiwane w przypadku wskazanych wersji interfejsu API. Aby uzyskać pełną dokumentację, zobacz Dokumentacja metadanych śledzenia pracy dla usługi Azure Boards Analytics.

Kluczowe jednostki śledzenia pracy na potrzeby raportowania

Podczas tworzenia raportów należy wziąć pod uwagę następujące podstawowe zestawy jednostek:

• Bieżące raporty o stanie: użyj WorkItems do określenia bieżącego stanu elementu roboczego
• Historyczne raporty trendów: używanie WorkItemSnapshot do analizy trendów w czasie
• Szczegółowe śledzenie zmian: użyj WorkItemRevisions do pełnego zapisu historii
• Raporty dla określonej tablicy: używaj WorkItemBoardSnapshot do analizy tablic Kanban

Najlepsze rozwiązania dotyczące korzystania z modelu danych analizy

Optymalizacja wydajności

1. Wybierz odpowiedni element: użyj jednostek informujących o stanie (WorkItems) dla raportów o stanie i elementów migawkowych dla trendów
2. Filtruj wcześnie: zastosuj filtry na poziomie jednostki, a nie po pobraniu danych
3. Ogranicz zakresy danych: użyj filtrów dat, aby ograniczyć zapytania dotyczące danych historycznych
4. Użyj odpowiednich agregacji: korzystaj z wbudowanych funkcji agregacji, jeśli jest to możliwe

Wzorce projektowe zapytań

Bieżące zapytania dotyczące stanu

/WorkItems?$filter=State ne 'Closed'&$select=WorkItemId,Title,State

Zapytania dotyczące trendów historycznych

/WorkItemSnapshot?$filter=DateSK ge 20241001&$select=WorkItemId,State,DateSK

Nawigacja w relacjach

/WorkItems?$expand=Area($select=AreaPath),AssignedTo($select=UserName)

Typowe pułapki do unikania

• Używanie jednostek poprawek dla bieżącego stanu: Nie używaj WorkItemRevisions, gdy WorkItems wystarcza
• Nadmierne rozszerzanie relacji: rozwiń tylko niezbędne właściwości nawigacji
• Brakujące filtry: Zawsze filtruj duże zestawy jednostek, aby zwiększyć wydajność
• Ignorowanie jednostek złożonych: użyj jednostek złożonych, takich jak WorkItemSnapshot na potrzeby analizy trendów

Zagadnienia dotyczące wersji

Różne wersje interfejsu API zapewniają różne możliwości:

• Wersja 1.0: Podstawowe obiekty śledzenia pracy
• Wersja 2.0: Dodano proces i ulepszone możliwości filtrowania
• Wersja 3.0-preview: dodano potok i elementy testowe
• Wersja 4.0-preview: ulepszone jednostki złożone (composite entities) i dodatkowe metryki przetwarzania

Wybierz odpowiednią wersję na podstawie wymagań raportowania i jednostek, do których chcesz uzyskać dostęp.

Powiązane artykuły

• Wytyczne dotyczące zapytań usługi OData Analytics
• Analiza WIT
• Agregowanie danych
• Eksplorowanie analitycznych metadanych OData
• Śledzenie pracy, przetwarzanie i limity projektu
• Projektowanie zestawu danych widoków analitycznych
• Konstruowanie zapytań OData na potrzeby analizy
• Zabezpieczenia i uprawnienia analizy