Огляд підключень до баз даних¶

Зміст¶

1. Як працюють підключення
2. Посібники для технологій
3. Передумова: встановіть драйвер ODBC на хості digna
4. Створення підключення до бази даних
5. Властивості ODBC
6. Шифрування значень властивостей
7. Тестування підключення
8. Яку базу даних бачить підключення
9. Режим профілювання та робоча схема
10. Використання DSN
11. Усунення несправностей

Як працюють підключення¶

digna звертається до кожної технології джерела через ODBC. Підключення — це список властивостей ODBC, які ви вводите як пари ключ/значення. Коли digna відкриває підключення, вона об'єднує ці пари в рядок підключення — Key=Value, розділені ;, у тому порядку, в якому ви їх вказали — і передає його менеджеру драйверів ODBC на хості digna.

Саме те, що ви вводите властивості самостійно, робить налаштування без DSN: підключення містить усе, що потрібно драйверу, тому на хості не потрібно реєструвати джерело даних ODBC (DSN). Це рекомендований спосіб налаштування digna, оскільки визначення підключення повністю зберігається в digna і переміщується разом із нею.

Чому ODBC¶

Попередні випуски пропонували вибір між драйвером для конкретної технології та ODBC, який здійснювався перемикачем Use ODBC. Починаючи з Release 2026.06, digna працює виключно через ODBC. Єдиний стандартний інтерфейс дає більше, ніж набір окремих драйверів:

• Автентифікація — автентифікація є частиною ODBC, тому підключення може використовувати все, що підтримує його драйвер: паролі, токени та PAT, Kerberos і Active Directory, MFA та єдиний вхід через браузер, хмарну ідентичність, клієнтські сертифікати та TLS. Нові методи з'являються з оновленням драйвера, без очікування нового випуску digna.
• Драйвери, які підтримують постачальники баз даних — власний драйвер постачальника враховує нові версії сервера та виправлення безпеки, і ви можете оновлювати його за власним графіком, незалежно від digna.
• Один спосіб налаштування всього — кожна технологія є списком властивостей ключ/значення з тим самим інтерфейсом, тим самим шифруванням чутливих значень і тим самим усуненням несправностей, замість окремого набору полів для кожного джерела.
• Налаштування та охоплення — параметри рівня драйвера, як-от тайм-аути, параметри TLS, проксі та розміри вибірки, доступні для кожного джерела, і можна підключити будь-яку технологію з сумісним драйвером ODBC, зокрема ті, для яких digna не публікує окремого посібника.

Посібники для технологій¶

Назви властивостей відрізняються залежно від драйвера, і кожна технологія має одну-дві особливості, яких немає в інших. Наведені нижче посібники описують саме цю частину; ця сторінка описує бік digna, який однаковий для всіх.

Передумова: встановіть драйвер ODBC на хості digna¶

digna відкриває підключення до джерел із сервера, на якому працює бекенд digna, а не з браузера. Тому драйвер ODBC має бути встановлений саме на цій машині, а його назва — зареєстрована в локальному менеджері драйверів.

odbcinst -q -d

odbcinst -q -d

Замість зареєстрованої назви всі поширені менеджери драйверів також приймають повний шлях до бібліотеки драйвера, наприклад Driver=/opt/simba/spark/lib/64/libsparkodbc_sb64.so. Це зручно, коли драйвер встановлено, але не зареєстровано.

Створення підключення до бази даних¶

Відкрийте Admin Panel, перейдіть на вкладку Database Connections і натисніть Add DB Connection. Екран запитує п'ять параметрів:

Підключення адмініструється централізовано, а потім призначається одному або кільком проєктам, тому одне підключення може обслуговувати кілька проєктів.

Властивості ODBC¶

Для кожної властивості натисніть Add Property і заповніть Key, Value, а для секретів — позначте прапорець Encrypted. Кожен посібник для технології містить приклад набору для цієї технології, який ви адаптуєте до своєї версії драйвера та сервера — див. примітку вище.

Незалежно від драйвера, набір властивостей охоплює ті самі чотири речі:

• Driver — зареєстрована назва драйвера, як описано вище.
• Адреса сервера — ключ залежить від драйвера: SERVER, HOST, DBCNAME, Server або, для Oracle, дескриптор підключення DBQ.
• Облікові дані — зазвичай UID і PWD; Snowflake використовує UID разом із token, а Databricks — буквального користувача token та персональний токен доступу в PWD.
• База даних або каталог для роботи, якщо технологія їх має — див. Яку базу даних бачить підключення.

Усе інше, що описано в документації драйвера, можна додати так само — пул підключень, тайм-аути сокетів, параметри Kerberos, параметри проксі. digna не інтерпретує властивості, а лише передає їх далі.

Шифрування значень властивостей¶

Позначте Encrypted для кожної властивості, що містить секрет — PWD, token, секрет клієнта. Тоді значення шифрується перед збереженням у репозиторії digna, маскується на екрані та розшифровується лише під час складання рядка підключення.

Властивості, які не є секретними — назву драйвера, хост, порт, базу даних — краще залишати незашифрованими, щоб їх міг прочитати той, хто згодом обслуговуватиме підключення.

Тестування підключення¶

Натисніть Test у діалозі Add DB Connection перед збереженням. Тест використовує значення, які зараз є у формі, і виконує справжнє підключення, тому повідомляє саме те, з чим зіткнулася б інспекція — неправильну назву драйвера, відхилений пароль, недоступний хост. Нічого не зберігається: тестове підключення відкочується незалежно від того, успішне воно чи ні.

Щоб повторно перевірити наявне підключення, наведіть курсор на його рядок на вкладці Database Connections і натисніть піктограму штекера. Це найшвидший спосіб перевірити, чи доступне джерело після зміни пароля або змін у брандмауері.

Яку базу даних бачить підключення¶

Коли ви додаєте джерело даних, digna пропонує каталоги, схеми та таблиці, до яких має доступ підключення. Наскільки широкий цей доступ, залежить від технології:

Режим профілювання та робоча схема¶

Режим профілювання визначає, як digna обробляє дані й обчислює метрики:

• Standard: Метрики обчислюються безпосередньо на таблицях джерела без копіювання даних.
• Permanent: Дані за інспектований день копіюються в постійну таблицю, і метрики обчислюються на скопійованих даних.
• Session: Дані копіюються в сесійну або тимчасову таблицю, і метрики обчислюються на цих тимчасових даних.

Режим визначає, що дозволено робити користувачеві підключення:

Standard лише читає дані, тому це режим для випадків, коли digna надано доступ лише для читання. Work Schema використовується лише для Permanent, але її варто заповнити в будь-якому разі, щоб підключення продовжувало працювати, якщо згодом режим буде змінено.

Використання DSN¶

DSN і далі працює — DSN є просто ще однією властивістю:

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

DSN має бути зареєстрований на хості digna для того самого облікового запису користувача, під яким працює бекенд digna, і як System DSN, якщо digna працює як служба. Усе, що налаштовано в DSN, можна перевизначити, додавши це також як властивість.

Налаштування без DSN є задокументованим стандартом, оскільки воно уникає цього стану на боці хоста: підключення повністю описане в digna, а на новому хості digna потрібно лише встановити драйвер без жодного додаткового налаштування.

Усунення несправностей¶

Data source name not found / no default driver specified¶

Симптоми: - Кнопка Test повідомляє про помилку з data source name not found, хоча налаштування виконано без DSN

Причини та рішення: 1. Значення Driver не збігається із зареєстрованою назвою драйвера — порівняйте його з вкладкою Drivers в ODBC Data Source Administrator (64-bit) або з результатом odbcinst -q -d 2. Драйвер встановлено на вашій робочій станції, але не на хості digna 3. Драйвер 32-бітний, а digna — 64-бітна — встановіть 64-бітний драйвер 4. Властивість Driver повністю відсутня, і DSN також не вказано 5. У Linux і macOS драйвер встановлено, але не зареєстровано — замість назви вкажіть повний шлях до бібліотеки драйвера або зареєструйте його в odbcinst.ini

Тест підключення завершується за тайм-аутом¶

Симптоми: - Test зависає, а приблизно через пів хвилини завершується помилкою

Причини та рішення: 1. Хост або порт недоступні з хоста digna — перевірте брандмауер, а для хмарних джерел — список дозволених IP-адрес 2. Ім'я хоста правильне, але порт належить іншій службі 3. Джерелу потрібно більше стандартних 30 секунд, щоб прийняти підключення — збільште DIGNA_SOURCE_LOGIN_TIMEOUT_SEC у розділі [base] файлу config.toml (0 — очікування без обмежень) і перезапустіть бекенд 4. Безсерверна кінцева точка виходить зі стану простою — повторіть спробу, а якщо це трапляється регулярно, збільште тайм-аут входу, як описано вище

Автентифікація не вдається, хоча облікові дані правильні¶

Симптоми: - Драйвер повідомляє про недійсні облікові дані, але той самий користувач працює в іншому клієнті SQL

Причини та рішення: 1. Пароль містить ; — візьміть значення у фігурні дужки: {p@ss;word} 2. У значення скопійовано пробіл у кінці 3. Драйвер очікує певний механізм автентифікації — наприклад, AuthMech для драйверів Hive і Databricks або authenticator для Snowflake 4. Значення збережено зашифрованим, а потім відредаговано — зашифровані значення неможливо прочитати назад, тому введіть секрет повністю заново 5. Термін дії токена минув — персональні токени доступу та токени програмного доступу видаються з датою закінчення терміну дії

Екран джерела даних не пропонує очікувану базу даних або схему¶

Симптоми: - Під час додавання джерела даних бракує каталогів, схем або таблиць

Причини та рішення: 1. Підключення вказує на іншу базу даних — див. Яку базу даних бачить підключення 2. Користувач підключення не має прав на читання схеми або словника даних 3. Technology не відповідає джерелу, тому digna запитує не той словник даних 4. Для Snowflake користувачеві не призначено склад за замовчуванням і властивість Warehouse не вказано, тому запити метаданих не можуть виконатися

Профілювання не вдається, хоча тест підключення успішний¶

Симптоми: - Test проходить, але інспекція завершується помилкою під час створення робочих таблиць

Причини та рішення: 1. Вибрано профілювання Permanent, а користувач підключення не може створювати таблиці в Work Schema — надайте права або перейдіть на Session чи Standard 2. Work Schema порожня або вказує на схему, якої не існує, при вибраному профілюванні Permanent 3. Вибрано профілювання Session, а користувачеві підключення не дозволено створювати тимчасові таблиці 4. Тривалий запит профілювання досягає тайм-ауту запиту — збільште DIGNA_SOURCE_QUERY_TIMEOUT_SEC у розділі [base] файлу config.toml (за замовчуванням 3600 секунд, 0 вимикає тайм-аут)

Найкращі практики¶

РОБІТЬ:

• Встановіть і зареєструйте драйвер на хості digna перед налаштуванням підключення
• Позначайте Encrypted для кожного пароля та токена
• Натискайте Test перед збереженням і перевіряйте повторно після зміни пароля
• Називайте підключення за джерелом і середовищем, наприклад sales_dwh_prod
• Надайте digna окремого користувача бази даних, лише для читання, якщо достатньо профілювання Standard
• Тримайте одне підключення на одну базу даних джерела і додавайте друге замість того, щоб перемикати перше

НЕ РОБІТЬ:

• Не зберігайте секрети незашифрованими і не використовуйте одного користувача бази даних спільно для digna та інших інструментів
• Не використовуйте 32-бітний драйвер із 64-бітною інсталяцією digna
• Не покладайтеся на User DSN, коли digna працює як служба — його не буде видно
• Не вводьте у властивість значення, що містить ;, без фігурних дужок
• Не вказуйте як Work Schema схему, що містить дані джерела

Підтримка¶

Потрібна допомога з підключенням до бази даних?

• Електронна пошта: support@digna.ai
• Документація: https://docs.digna.ai
• Вебсайт: https://www.digna.ai

Випуск: 2026.06
© 2026 digna GmbH — www.digna.ai