Hvad bruges ODBC til: en komplet og praktisk guide

Hvis du arbejder med data dagligt, dukker det frygtede akronym ODBC før eller siden op, og mere end én person spekulerer på, hvad det præcist er for. ODBC er en af ​​de tavse standarder, der gør det muligt for meget forskellige applikationer og databaser at forstå hinanden., uden at skulle omskrive al din kode hver gang du skifter udbyder.

Selvom der findes nyere teknologier i dag, er ODBC fortsat nøglen i mange miljøer: fra Office-værktøjer som Excel eller AccessFra BI-løsninger som Tableau eller Qlik Sense til ældre virksomhedsapplikationer, der stadig håndterer kritiske data, vil vi se nærmere på, hvad det er, hvad det bruges til, hvordan det fungerer internt, og hvordan man konfigurerer det i praksis.

Hvad er ODBC, og hvad bruges det egentlig til?

ODBC står for Åbn databaseforbindelseDette er en grænseflade til programmering af åben standardapplikation (API), der er designet til at tilgå databaser ensartet, uanset det underliggende databasestyringssystem (DBMS).

Ideen er simpel, men utrolig kraftfuld: Du skriver din applikation én gang ved hjælp af ODBC-kald og standard SQL-sætninger, og lader en driver håndtere at tale "modersmålet" for hver database.Dette giver dig mulighed for at skifte fra Access til SQL Server, fra MySQL til Oracle eller endda til en simpel tekstfil uden at skulle omskrive al dataadgangslogikken.

ODBC fungerer som en bro mellem klientapplikationen og DBMS'et. Applikationen sender SQL-anmodninger ved hjælp af ODBC API'en, og driveren oversætter disse anmodninger til et format, som den specifikke DBMS forstår. og returnerer resultaterne tilbage til applikationen. Takket være dette behøver programmet ikke at kende de proprietære egenskaber for hver database.

Denne standard blev skabt i starten af ​​90'erne af SQL Access Group og Microsoft var den største drivkraft i verden Windowsmed den første driver SIMBA.DLL (udviklet i samarbejde med Simba i 1992). I dag findes der implementeringer i Windows, UNIX, Linux, OS/2 og macOS, hvilket gør ODBC til en udbredt løsning på tværs af platforme.

ODBC's historie og udvikling

ODBC's historie er tæt forbundet med udviklingen af ​​dataadgang i Microsoft-miljøer og åbne standarder. ODBC er baseret på SQL Call-Level Interface (CLI)-specifikationen fra The Open Group og ISO/IEC., som definerede, hvordan API'er til databaseadgang på kaldsniveau skulle være.

Den første version af ODBC blev udgivet i September 1992 (ODBC 1.0)Derfra fulgte versioner med nye funktioner og forbedringer af ydeevnen: ODBC 2.0 (omkring 1994), 2.5, ODBC 3.0 (omkring 1995, med vigtige bidrag fra IBM og Intersolv), ODBC 3.5 (1997) og ODBC 3.8 omkring 2009, som blev integreret med Windows 7.

Parallelt forsøgte Microsoft at gå ud over ODBC ved at skabe andre dataadgangsmodeller: OLE DB, ADO, DAO, RDS, Jetmotor og senere ADO.NET. Den oprindelige plan var, at teknologier som OLE DB og ADO skulle erstatte ODBC som den primære standard for dataadgang, især i mere objektorienterede scenarier og med datakilder, der ikke nødvendigvis er SQL.

Markedets virkelighed var dog anderledes: ODBC fastholdt sin position som de facto standarden for adgang til SQL-kilderDen massive støtte fra udbydere som Oracle og IBM, dens multiplatform-natur og den enorme eksisterende applikationspark sikrede, at det forblev den foretrukne løsning i mange projekter.

Når vi i dag taler om adgang til SQL-databaser, er de to vigtigste standarder, der fortsat er fuldt ud gældende. ODBC og JDBCAndre modeller som OLE DB eller nogle ADO-lag har mistet meget relevans og bliver i mange tilfælde opgivet eller forbliver kun for kompatibilitet med ældre applikationer.

ODBC-arkitektur: hvordan den fungerer indvendigt

For fuldt ud at forstå, hvad ODBC er til for, er det nyttigt at se på dens arkitektur. ODBC introducerer et mellemlag mellem applikationen og DBMS'en. således at appen ikke kommunikerer direkte med databasen, men med et standard API.

Generelt set er flowet som følger: Applikationen sender SQL-anmodninger til ODBC Driver Manager, som finder og indlæser den relevante driver til måldatabasen.Controlleren oversætter anmodningen til DBMS'ens native protokol, databasen behandler forespørgslen, og resultaterne returneres ad samme sti tilbage til applikationen.

Denne arkitektur muliggør ikke kun leverandøruafhængighed, men også løsning af Emner som versionskompatibilitet, fejlhåndtering, datatypekonvertering og forskelle i SQL-syntaks mellem motorer. Alt gøres så transparent som muligt for den person, der programmerer applikationen.

I Windows-sammenhæng er ODBC en del af Windows Open Services-arkitektur (WOSA), en åben servicearkitektur, hvor desktopapplikationer kan oprette forbindelse til forskellige computermiljøer uden at skulle omskrives for hver platform.

Hovedkomponenter i ODBC

Den typiske implementering af ODBC på Microsoft-systemer og på mange platforme følger en fælles struktur. Vi kan skelne mellem flere nøglekomponenter, der arbejder sammen for at skabe den åbne forbindelse.

På den ene side er ODBC APIEn SQL API er et sæt af kaldfunktioner, fejlkoder og standard SQL-konventioner, som applikationen bruger til at arbejde med data. Denne API definerer, hvordan forbindelser åbnes, forespørgsler sendes, resultater hentes, og transaktioner administreres, uden at være afhængig af det specifikke databasesystem.

Et andet væsentligt element er ODBC-driverhåndtering (På Windows, Odbc32.dll-biblioteket). Dette dynamiske linkbibliotek sidder mellem programmet og de specifikke drivere, indlæses transparent og er ansvarligt for at finde, indlæse og downloade de relevante drivere samt administrere versioner og kompatibilitet.

Så fandt vi ODBC-databasedrivereHvert DBMS (SQL Server, Oracle, MySQL, DB2 osv.) har sin egen driver, normalt i form af en eller flere DLL'er. Disse drivere er det, der rent faktisk oversætter ODBC API-kaldene til native DBMS-kald, og håndterer den specifikke SQL-syntaks, interne datatyper og hver motors særlige egenskaber.

I nogle miljøer, en ODBC-markørbibliotek (for eksempel Odbccr32.dll på Windows), som er placeret mellem Driver Manager og selve driverne for at administrere rulning gennem resultatsæt, avancerede markører og andre datanavigationshandlinger.

Endelig har vi ODBC-datakildeadministratorEt grafisk værktøj eller konfigurationsværktøj, der giver dig mulighed for at definere og ændre systemets datakilder (DSN). Derfra bestemmer du, hvilken driver du skal bruge, hvilken server eller fil du skal oprette forbindelse til, og med hvilke godkendelsesparametre.

ODBC-aktiverede applikationer og datakildetyper

Enhver software, der kan åbne en forbindelse ved hjælp af standard-API'en, kan betragtes som en ODBC-aktiveret applikationI den virkelige verden omfatter dette alt fra kontorsoftware til analyseværktøjer og brugerdefinerede forretningsapplikationer.

Nogle typiske eksempler er Microsoft Excel, Microsoft Access, Power BI, Tableau, Crystal Reports, Qlik Sense og en lang række administrationsapplikationer (ERP, CRM, vertikale løsninger osv.), der skal læse eller skrive data i forskellige systemer.

For at applikationen kan vide, hvordan den skal tilgå dataene, anvendes ODBC-datakilder, som kombinerer dataoprindelsen med Nødvendige forbindelsesoplysninger: serverplacering, databasenavn, brugernavn, adgangskode og driverspecifikke indstillingerDenne konfiguration er normalt indkapslet i et DSN (datakildenavn) eller en forbindelsesstreng.

I Windows administreres ODBC-datakilder via ODBC-datakildeadministratorDer kan du konfigurere forskellige typer DSN'er, hver med sit eget omfang og tilstand. opbevaringDette giver betydelig fleksibilitet ved implementering af applikationer på individuelle computere eller delte servere.

En vigtig detalje er det Dataadgangsklasser og -biblioteker kan fungere med enhver kilde, der har en tilgængelig ODBC-driver.Dette inkluderer relationelle databaser, ISAM-motorer, Excel-regneark, tekstfiler eller endda live-datakilder, der eksponerer deres data i et tabelformat, der er tilgængeligt via SQL.

DSN-typer og forbindelsesstrenge i ODBC

Når vi taler om konfiguration af ODBC, dukker konceptet DSN næsten altid op. DSN (Data Source Name) grupperer alle de data, der er nødvendige for at åbne forbindelsen: hvilken driver der skal bruges, hvilken server den peger på, hvilken specifik database, legitimationsoplysninger og yderligere muligheder.

I Windows-systemer skelnes der mellem tre typer DSN'er. bruger-DSN De gemmer kun indstillingerne i registreringsdatabasen for den aktuelle brugerprofil, så kun den konto kan bruge dem. De er nyttige, når du vil isolere forbindelser efter bruger og forhindre andre i at se indstillingerne.

masse System-DSN Disse indstillinger gemmes også i registreringsdatabasen, men er synlige for alle brugere af computeren, inklusive systemtjenester. De er den anbefalede mulighed for servere eller delte installationer, da de tillader forskellige konti at bruge den samme forbindelseskonfiguration uden duplikering.

På den anden side er der fil-DSNDisse DSN'er gemmer forbindelsesoplysninger i en tekstfil med filtypenavnet .dsn i stedet for i registreringsdatabasen. Disse DSN'er er generelt mere fleksible, da de kan kopieres til andre computere med den samme driver installeret eller placeres på en delt server for at centralisere konfigurationen.

Ud over delbare DSN'er er der ikke-delbare arkiv-DSN'er, der De findes på en enkelt computer og fungerer som en pointer til et maskinens DSN.Dette giver dig mulighed for at udnytte eksisterende datakilder uden at eksponere hele konfigurationen offentligt.

I mange sprog (f.eks. Visual Basic eller C#) kan du også vælge ikke at definere et DSN og videregive en direkte forbindelsesstreng til ODBC Driver ManagerDenne streng indeholder de samme parametre som et DSN, men er integreret i koden, hvilket forenkler programdistributionen på bekostning af tab af administrativ fleksibilitet.

Praktisk ODBC-konfiguration i Windows

Den typiske proces for at begynde at bruge ODBC i Windows følger et par klare trin. Først, Du skal installere den relevante ODBC-driver til mål-DBMS'en.Nogle gange følger det med selve Windows (for eksempel generiske drivere til SQL Server eller Access), og andre gange leveres det af databaseproducenten eller en specialiseret tredjepart.

Når driveren er installeret, åbnes værktøjet. "Datakilder (ODBC)" Fra Kontrolpanel → Administration. Dette værktøj åbner ODBC Data Source Manager, hvor du kan vælge, om du vil oprette et bruger-, system- eller fil-DSN, afhængigt af dine sikkerheds- og delingsbehov.

Det næste trin er at klikke på "Tilføj", vælge den tilsvarende controller (f.eks. "SQL Server", "Microsoft Access-driver (*.mdb, *.accdb)"osv.) og følg guiden: Du vil normalt blive bedt om det beskrivende navn på kilden, den server eller fil, den peger på, og i mange tilfælde legitimationsoplysninger eller godkendelsestilstand.

I 64-bit miljøer skal man være opmærksom på arkitekturen: en 64-bit Windows-installation inkluderer to versioner af ODBC Manager (Odbcad32.exe)64-bit versionen findes i %systemdrive%\Windows\System32 og 32-bit versionen i %systemdrive%\Windows\SysWOW64. En 32-bit driver vises kun i 32-bit driverhåndteringen, og det samme gælder for 64-bit drivere.

Applikationer som Access, Qlik Sense eller Tableau oprette forbindelse til eksterne databaserNogle tilbyder også deres egne connectorer, der indkapsler licenserede ODBC-drivere (for eksempel Qliks ODBC Connector Package), så brugeren ikke engang behøver at gå gennem Windows Data Source Manager.

Brug af ODBC med værktøjer som Access, Qlik Sense eller Tableau

I Microsoft Access bruges ODBC til at link eller importér data fra eksterne kilder, som Access ikke har en indbygget driver tilsåsom SQL Server, Oracle eller tredjepartsdatabaser. Processen er den sædvanlige: Access opretter forbindelse til ODBC Driver Manager, som bruger den specifikke driver (f.eks. SQL Server-driveren), og forbindelsen til databasen åbnes.

Med Qlik Sense har vi to muligheder. På den ene side, brug forbindelser, der er inkluderet i Qlik ODBC Connector PackageDisse metoder eksponerer optimerede "Qlik-xxx"-drivere, der konfigureres direkte fra Qlik-grænsefladen og omgår Windows ODBC-manageren. Alternativt kan du manuelt installere en ODBC-driver til DBMS'et og oprette en bruger- eller system-DSN, som Qlik Sense bruger, når dataforbindelsen etableres.

I Qlik Sense Desktop kan DSN-listen vise både DSN'er oprettet i Windows og interne pakkedrivere (identificeret med præfikset "Qlik-"). Disse interne drivere kan ikke bruges til at oprette generiske ODBC-forbindelser. uden for Qlik-økosystemet; de er designet udelukkende til de databaseforbindelser, der følger med selve produktet.

I tilfældet med Tableau er der en samling af fintunede, native connectors til specifikke databaser (Snowflake, SQL Server, Oracle osv.), men En generisk ODBC-forbindelse tilbydes også Denne forbindelse er nyttig, når du har brug for at få adgang til en database, som der ikke findes en specifik forbindelse til. Den udnytter ODBC-standarden til at kommunikere med stort set enhver kilde, der implementerer SQL og ODBC API'en.

Tableau udfører en opdagelsesfase, når de opretter forbindelse via ODBC, hvor Forespørg ODBC-driveren for at finde ud af, hvilke funktioner den understøtter.skalar- og aggregeringsfunktioner, datohåndtering, underforespørgselsfunktioner, tilgængelige JOIN-typer, oprettelse af midlertidige tabeller osv. Afhængigt af hvad driveren deklarerer, klassificerer den forbindelsen som fuldt funktionel, med mindre begrænsninger, med betydelige begrænsninger eller direkte ubrugelig.

Forholdet mellem ODBC og JDBC

Inden for dataadgangsøkosystemet har ODBC sin naturlige ækvivalent i Java-verdenen: JDBC (Java Database Connectivity)Begge søger det samme mål: at levere en standard for applikationer, der kan oprette forbindelse til forskellige databaser ved hjælp af SQL, men med tilgange tilpasset deres miljø.

Selvom ODBC primært er beregnet til applikationer skrevet i C, C++ eller andre sprog, der understøtter dets API Og det bruges i vid udstrækning i Windows (dog også på andre platforme), JDBC er en del af selve Java-økosystemet og er per definition tværplatform, da det kører på den virtuelle maskine.

JDBC-arkitekturen er opdelt i en API-laghvilke er de Java-grænseflader og -klasser, der bruges af udviklere, og en driverlag som implementerer disse grænseflader og kommunikerer med den faktiske database. Der er fire typer JDBC-drivere: Type 1 (ODBC-bro), Type 2 (native/delvis API), Type 3 (netværksprotokol) og Type 4 (100 % Java "tynd" driver).

Den gamle controller JDBC-ODBC-broen (Type 1) tillod Java-applikationer at få adgang til databaser, der var tilgængelige via ODBC.Det var nyttigt som en overgangsløsning, men med El tiempo Det blev frarådet på grund af ydeevne og kompleksitet, og er endt med at forsvinde fra moderne versioner af Java.

I JDBC opbygges forbindelsen til en database fra en URL i et format, der ligner jdbc::/// Flere valgfrie egenskaber. For eksempel: jdbc:mysql://localhost:3306/mydatabase. Fra denne URL finder Java DriverManager den relevante driver og åbner forbindelsen, ligesom ODBC Manager vælger driveren i ODBC-verdenen.

Med hensyn til praktiske forskelle, ODBC og JDBC adskiller sig primært ved det sprog og økosystem, de er rettet mod.ODBC integrerer dybt med Windows og native applikationer, mens JDBC integrerer problemfrit med Java-verdenen, understøtter Java-specifikke datatyper og leverer sine egne værktøjer som ResultSet til håndtering af resultater. I visse scenarier kan en Type 4 JDBC-driver tilbyde yderst konkurrencedygtig ydeevne ved at eliminere mellemliggende lag.

I sidste ende bestemmes valget mellem den ene og den anden af ​​applikationens teknologi: Java-applikationer bruger typisk JDBC; native applikationer bruger ODBCUnder alle omstændigheder repræsenterer begge den samme filosofi om standardiseret og leverandør-agnostisk adgang med hensyn til databaseudbyderen.

ODBC forbliver en nøgle I dataadgangsgåden: den giver programmer af alle slags mulighed for at oprette forbindelse til meget forskellige databaser via et fælles API, skjuler forskellene i hver applikation takket være dens drivere, passer til værktøjer så forskellige som Access, Qlik Sense eller Tableau og sameksisterer med andre standarder som JDBC i Java-verdenen, så hvis du forstår, hvordan ODBC fungerer, er du halvvejs derhen til at bevæge dig problemfrit gennem næsten ethvert moderne databasemiljø.