Přehled databázových připojení¶

Obsah¶

1. Jak fungují připojení
2. Návody pro jednotlivé technologie
3. Předpoklad: instalace ovladače ODBC na hostitele digna
4. Vytvoření databázového připojení
5. Vlastnosti ODBC
6. Šifrování hodnot vlastností
7. Testování připojení
8. Kterou databázi připojení vidí
9. Režim profilování a Work Schema
10. Použití DSN
11. Odstraňování problémů

Jak fungují připojení¶

digna přistupuje ke každé zdrojové technologii přes ODBC. Připojení je seznam vlastností ODBC, které zadáváte jako dvojice klíč/hodnota. Když digna připojení otevírá, spojí tyto dvojice do připojovacího řetězce — Key=Value, oddělené ;, v pořadí, v jakém jste je uvedli — a předá jej správci ovladačů ODBC na hostiteli digna.

Právě to, že vlastnosti zadáváte sami, dělá nastavení DSN-less: připojení nese vše, co ovladač potřebuje, takže na hostiteli není nutné registrovat žádný zdroj dat ODBC (DSN). Toto je doporučený způsob konfigurace digna, protože definice připojení je celá uložena v digna a přesouvá se spolu s ní.

Proč ODBC¶

Dřívější verze nabízely volbu mezi ovladačem specifickým pro technologii a ODBC, vybíranou přepínačem Use ODBC. Od Release 2026.06 staví digna výhradně na ODBC. Jediné standardní rozhraní vám dává víc, než dokáže sada ovladačů na míru:

• Ověřování — ověřování je součástí ODBC, takže připojení může používat cokoli, co jeho ovladač podporuje: hesla, tokeny a PAT, Kerberos a Active Directory, MFA a jednotné přihlášení v prohlížeči, cloudovou identitu, klientské certifikáty a TLS. Nové metody přicházejí s aktualizací ovladače a nemusí čekat na verzi digna.
• Ovladače udržované dodavateli databází — vlastní ovladač dodavatele drží krok s novými verzemi serveru a bezpečnostními opravami a můžete jej aktualizovat podle vlastního plánu, nezávisle na digna.
• Jeden způsob konfigurace všeho — každá technologie je seznam vlastností klíč/hodnota se stejným rozhraním, stejným šifrováním citlivých hodnot a stejným odstraňováním problémů, místo odlišné sady polí pro každý zdroj.
• Ladění a dosah — volby na úrovni ovladače, jako jsou časové limity, nastavení TLS, proxy a velikosti načítaných dávek, jsou dostupné pro každý zdroj a připojit lze jakoukoli technologii s vyhovujícím ovladačem ODBC, včetně těch, pro které digna nezveřejňuje samostatný návod.

Návody pro jednotlivé technologie¶

Názvy vlastností se liší podle ovladače a každá technologie má jeden či dva detaily, které ostatní nemají. Níže uvedené návody pokrývají tuto část; tato stránka pokrývá stranu digna, která je pro všechny stejná.

Předpoklad: instalace ovladače ODBC na hostitele digna¶

digna otevírá zdrojová připojení ze serveru, na kterém běží backend digna, nikoli z prohlížeče. Ovladač ODBC proto musí být nainstalován na tomto počítači a jeho název musí být registrován u místního správce ovladačů.

odbcinst -q -d

odbcinst -q -d

Místo registrovaného názvu všichni běžní správci ovladačů přijímají i úplnou cestu ke knihovně ovladače, například Driver=/opt/simba/spark/lib/64/libsparkodbc_sb64.so. To se hodí, když je ovladač nainstalován, ale není registrován.

Vytvoření databázového připojení¶

Otevřete Admin Panel, přejděte na kartu Database Connections a klikněte na Add DB Connection. Obrazovka vyžaduje pět údajů:

Připojení se spravuje centrálně a poté se přiřazuje jednomu nebo více projektům, takže stejné připojení může sloužit několika projektům.

Vlastnosti ODBC¶

Pro každou vlastnost klikněte na Add Property a vyplňte Key, Value a u tajných hodnot zaškrtněte políčko Encrypted. Každý návod pro technologii uvádí vzorovou sadu pro danou technologii, kterou přizpůsobíte své verzi ovladače a serveru — viz poznámku výše.

Bez ohledu na ovladač pokrývá sada vlastností stejné čtyři věci:

• Driver — registrovaný název ovladače, jak je popsáno výše.
• Adresa serveru — klíč se liší podle ovladače: SERVER, HOST, DBCNAME, Server nebo u Oracle connect descriptor DBQ.
• Přihlašovací údaje — obvykle UID a PWD; Snowflake používá UID plus token a Databricks používá doslovného uživatele token plus osobní přístupový token v PWD.
• Databáze nebo katalog, se kterým se pracuje, pokud jej technologie má — viz Kterou databázi připojení vidí.

Cokoli dalšího, co ovladač dokumentuje, lze přidat stejným způsobem — sdružování připojení (connection pooling), časové limity soketů, nastavení Kerberos, nastavení proxy. digna vlastnosti neinterpretuje; pouze je předává dál.

Šifrování hodnot vlastností¶

Zaškrtněte Encrypted u každé vlastnosti, která obsahuje tajnou hodnotu — PWD, token, tajný klíč klienta. Hodnota se pak před uložením do repozitáře digna zašifruje, na obrazovce se zobrazí maskovaně a dešifruje se až při sestavování připojovacího řetězce.

Vlastnosti, které nejsou tajné — název ovladače, hostitel, port, databáze — je nejlepší ponechat nešifrované, aby zůstaly čitelné pro toho, kdo bude připojení později spravovat.

Testování připojení¶

V dialogu Add DB Connection klikněte na Test před uložením. Test použije hodnoty, které jsou aktuálně ve formuláři, a provede skutečné připojení, takže nahlásí přesně to, na co by narazila inspekce — chybný název ovladače, odmítnuté heslo, nedostupného hostitele. Nic se neukládá: testovací připojení se vrátí zpět (rollback), ať uspěje, nebo selže.

U již existujícího připojení najeďte myší na jeho řádek na kartě Database Connections a kliknutím na ikonu zástrčky jej otestujte znovu. To je nejrychlejší způsob, jak ověřit, zda je zdroj dostupný po změně hesla nebo úpravě firewallu.

Kterou databázi připojení vidí¶

Když přidáváte zdroj dat, digna nabízí katalogy, schémata a tabulky, na které připojení dosáhne. Jak daleko tento dosah sahá, závisí na technologii:

Režim profilování a Work Schema¶

Režim profilování určuje, jak digna zpracovává data a počítá metriky:

• Standard: Metriky se počítají přímo na zdrojových tabulkách bez kopírování dat.
• Permanent: Data za inspektovaný den se zkopírují do trvalé tabulky a metriky se počítají na zkopírovaných datech.
• Session: Data se zkopírují do tabulky relace nebo dočasné tabulky a metriky se počítají na těchto dočasných datech.

Režim rozhoduje o tom, co musí mít uživatel připojení povoleno:

Standard pouze čte, a proto je to režim, který zvolíte, když má digna přidělen přístup pouze pro čtení. Work Schema se čte jen u režimu Permanent, ale i tak stojí za to jej vyplnit, aby připojení fungovalo i v případě, že se režim později změní.

Použití DSN¶

DSN stále funguje — DSN je jen další vlastnost:

Key: DSN        Value: my_registered_dsn
Key: UID        Value: <user>
Key: PWD        Value: <password>        [Encrypted]

DSN musí být registrováno na hostiteli digna, pro stejný uživatelský účet, pod kterým běží backend digna, a jako System DSN, pokud digna běží jako služba. Vše, co je nakonfigurováno v DSN, lze přepsat tím, že to přidáte i jako vlastnost.

DSN-less je zdokumentovaná výchozí volba, protože se vyhýbá tomuto stavu na straně hostitele: připojení je plně popsáno v digna a nový hostitel digna potřebuje pouze nainstalovaný ovladač, bez jakékoli konfigurace.

Odstraňování problémů¶

Data source name not found / no default driver specified¶

Příznaky: - Tlačítko Test hlásí chybu zmiňující data source name not found, přestože je nastavení DSN-less

Příčiny a řešení: 1. Hodnota Driver neodpovídá žádnému registrovanému názvu ovladače — porovnejte ji s kartou Drivers v ODBC Data Source Administrator (64-bit) nebo s výstupem odbcinst -q -d 2. Ovladač je nainstalován na vaší pracovní stanici, ale ne na hostiteli digna 3. Ovladač je 32bitový, zatímco digna je 64bitová — nainstalujte 64bitový ovladač 4. Vlastnost Driver úplně chybí a nebylo zadáno ani DSN 5. V Linuxu a macOS je ovladač nainstalován, ale není registrován — zadejte místo toho úplnou cestu ke knihovně ovladače, nebo jej registrujte v odbcinst.ini

Test připojení vyprší¶

Příznaky: - Test se zasekne a přibližně po půl minutě selže

Příčiny a řešení: 1. Hostitel nebo port není z hostitele digna dostupný — zkontrolujte firewall a u cloudových zdrojů seznam povolených IP adres 2. Název hostitele je správný, ale port patří jiné službě 3. Zdroj potřebuje k přijetí připojení déle než výchozích 30 sekund — zvyšte DIGNA_SOURCE_LOGIN_TIMEOUT_SEC v sekci [base] souboru config.toml (0 čeká neomezeně) a restartujte backend 4. Serverless endpoint se probouzí z nečinnosti — zkuste to znovu, a pokud se to děje pravidelně, zvyšte časový limit přihlášení, jak je uvedeno výše

Ověření selže, přestože jsou přihlašovací údaje správné¶

Příznaky: - Ovladač hlásí neplatné přihlašovací údaje, ale stejný uživatel funguje v jiném SQL klientovi

Příčiny a řešení: 1. Heslo obsahuje ; — uzavřete hodnotu do složených závorek: {p@ss;word} 2. Do hodnoty se zkopírovala mezera na konci 3. Ovladač očekává konkrétní mechanismus ověřování — například AuthMech u ovladačů Hive a Databricks nebo authenticator u Snowflake 4. Hodnota byla uložena šifrovaně a poté upravena — šifrované hodnoty nelze zpětně přečíst, proto tajnou hodnotu zadejte znovu celou 5. Platnost tokenu vypršela — osobní přístupové tokeny a programové přístupové tokeny se vydávají s datem vypršení

Obrazovka zdroje dat nenabízí očekávanou databázi nebo schéma¶

Příznaky: - Při přidávání zdroje dat chybějí katalogy, schémata nebo tabulky

Příčiny a řešení: 1. Připojení ukazuje na jinou databázi — viz Kterou databázi připojení vidí 2. Uživatel připojení nemá oprávnění ke čtení schématu nebo datového slovníku 3. Technology neodpovídá zdroji, takže digna dotazuje nesprávný datový slovník 4. U Snowflake nemá uživatel přiřazen výchozí warehouse a nebyla zadána vlastnost Warehouse, takže dotazy na metadata nelze spustit

Profilování selže, zatímco test připojení uspěje¶

Příznaky: - Test projde, ale inspekce selže při vytváření pracovních tabulek

Příčiny a řešení: 1. Je zvoleno profilování Permanent a uživatel připojení nemůže vytvářet tabulky ve Work Schema — udělte oprávnění, nebo přepněte na Session či Standard 2. Work Schema je prázdné nebo uvádí schéma, které neexistuje, zatímco je zvoleno profilování Permanent 3. Je zvoleno profilování Session a uživatel připojení nesmí vytvářet dočasné tabulky 4. Dlouho běžící dotaz profilování narazí na časový limit dotazu — zvyšte DIGNA_SOURCE_QUERY_TIMEOUT_SEC v sekci [base] souboru config.toml (výchozí hodnota 3600 sekund, 0 časový limit vypíná)

Osvědčené postupy¶

CO DĚLAT:

• Před konfigurací připojení nainstalujte a registrujte ovladač na hostiteli digna
• Zaškrtněte Encrypted u každého hesla a tokenu
• Před uložením klikněte na Test a po změně hesla test zopakujte
• Pojmenovávejte připojení podle zdroje a prostředí, například sales_dwh_prod
• Dejte digna vyhrazeného uživatele databáze, s přístupem pouze pro čtení tam, kde stačí profilování Standard
• Pro každou zdrojovou databázi mějte jedno připojení a raději přidejte druhé, než abyste přepínali to první

CO NEDĚLAT:

• Neukládejte tajné hodnoty nešifrované a nesdílejte jednoho uživatele databáze mezi digna a jinými nástroji
• Nepoužívejte 32bitový ovladač s 64bitovou instalací digna
• Nespoléhejte na User DSN, když digna běží jako služba — nebude viditelné
• Nevkládejte do vlastnosti hodnotu obsahující ; bez složených závorek
• Nesměrujte Work Schema na schéma, které obsahuje zdrojová data

Podpora¶

Potřebujete pomoc s databázovým připojením?

• E-mail: support@digna.ai
• Dokumentace: https://docs.digna.ai
• Web: https://www.digna.ai

Release: 2026.06
© 2026 digna GmbH — www.digna.ai