🎯 Definicja
Component Rules to reużywalne fragmenty logiki w Ataccama ONE, które mogą być używane do Detekcji (jaki to typ danych?) lub Ewaluacji (czy dane są poprawne?). Są tworzone jako pliki .comp w ONE Desktop.
🔑 Kluczowe punkty
- Detection Rules: Służą do automatycznego przypisywania terminów słownikowych (Glossary Terms) do kolumn. Np. “Jeśli kolumna ma 11 cyfr i zaczyna się od ‘PL’, oznacz ją jako PESEL”. Nie oceniają jakości, tylko klasyfikują.
- DQ Evaluation Rules: Służą do oceny jakości. Zwracają status
VALID/INVALID. Mogą być podpięte pod Terminy. - Web vs Desktop: Proste reguły wyklikasz w przeglądarce (Web App). Skomplikowane (z logiką Lookup, regexami) budujesz w ONE Desktop jako komponenty.
📚 Szczegółowe wyjaśnienie
Proces tworzenia zaawansowanej reguły DQ:
- ONE Web: Tworzysz “Validation Component” (definiujesz wejście/wyjście). Status: “Draft”.
- ONE Desktop: Pobierasz komponent. Widzisz go w zakładce
Components. - Logika: W środku “pudełka” układasz klocki (kroki), np.
Regex Matching→Condition. - Publish: Wysyłasz gotowy komponent z powrotem do Web App.
- Użycie: W Data Quality Rule wybierasz typ “Component” i wskazujesz swój plik.
💡 Przykład zastosowania
Reguła walidacji kodu IBAN.
Ponieważ walidacja IBAN wymaga skomplikowanej matematyki (modulo 97), nie zrobisz tego prostym SQL-em w przeglądarce.
Tworzysz komponent Validate_IBAN.comp w ONE Desktop, używasz wbudowanej funkcji isIban(), publikujesz. Teraz każdy analityk w firmie może użyć tej reguły, nie wiedząc jak działa w środku.
📌 Źródła
- Ataccama ONE Documentation - Component Rules.
👽 Brudnopis
- Reguły detekcji NIE mogą być używane w Monitoring Projects.
- Wewnątrz komponentu nie wolno zmieniać wejść/wyjść (Integration Input/Output).