So you might be getting an idea of what ODBC does, but where did it come from? Around 1990, the UNIX database vendors, including Oracle, Informix, and IBM as part of the SQL Access Group, put forth a CLI (Call-Level Interface) to allow the use of SQL in a portable fashion.
Prior to the SAG CLI, the only way to use SQL was as Embedded SQL, which means that SQL statements in your programming language had to be passed into a language-specific precompiler that broke the statements down into the native database API language. Embedded SQL was understandably unwieldy, and the database vendors got together in SAG and the related X/Open group to develop a portable SQL interface that could be used across databases and without the language specific precompiler.
The SAG CLI was based on a subset of the SQL specification called Static SQL, also known as ANSI SQL86. This was expanded to cover Dynamic SQL and several vendors such as IBM and Informix quickly adopted this CLI as the de facto standard for SQL in their databases.
In 1992 Microsoft implemented the SQL CLI in a set of interfaces called ODBC, extending the SAG CLI to include functions for querying and controlling drivers and accessing the database catalog. Microsoft took the SAG CLI further in its usability, understanding that a set of GUI tools and SDKs would enable adoption, and began championing ODBC to its partners and customers.
After several years, Microsoft implemented OLE-DB as an alternative to ODBC. OLE-DB initially could be viewed as an object layer bolted onto ODBC, but Microsoft soon implemented OLE-DB drivers that did not require ODBC underpinnings. This may be seen as a strategic business move by Microsoft to control data-access, since OLE-DB was bound to the Windows platform, but it was unsuccessful. ODBC had become the de facto standard for accessing SQL-based engines and was cross- platform to boot.