구글와이드(336x280)_상단 2개


(영문) OLE DB (위키 백과사전) DataBase(MS SQL)

OLE DB

From Wikipedia, the free encyclopedia

Jump to: navigation, search
OLE DB (Object Linking and Embedding, Database, sometimes written as OLEDB or OLE-DB) is an API designed by Microsoft for accessing different types of data stores in a uniform manner. It is a set of interfaces implemented using the Component Object Model (COM); it is otherwise unrelated to OLE. It was designed as a higher-level replacement for, and successor to, ODBC, extending its feature set to support a wider variety of non-relational databases, such as object databases and spreadsheets that do not necessarily implement SQL.
OLE DB separates the data store from the application that needs access to it through a set of abstractions that include the datasource, session, command and rowsets. This was done because different applications need access to different types and sources of data and do not necessarily want to know how to access functionality with technology-specific methods. OLE DB is conceptually divided into consumers and providers.
The consumers are the applications that need access to the data, and the provider is the software component that implements the interface and therefore provides the data to the consumer. OLE DB is part of the Microsoft Data Access Components (MDAC) stack. MDAC is a group of Microsoft technologies that interact together as a framework that allows programmers a uniform and comprehensive way of developing applications for accessing almost any data store. OLE DB providers can be created to access such simple data stores as a text file and spreadsheet, through to such complex databases as Oracle, SQL Server and Sybase ASE. It can also provide access to hierarchial datastores such as email systems.
However, because different data store technologies can have different capabilities, OLE DB providers may not implement every possible interface available to OLE DB. The capabilities that are available are implemented through the use of COM objects - an OLE DB provider will map the data store technologies functionality to a particular COM interface. Microsoft calls the availability of an interface to be "provider-specific" as it may not be applicable depending on the database technology involved. Additionally, however, providers may also augment the capabilities of a data store - these capabilities are known as services in Microsoft parlance.

[edit] OLE DB providers

========================================================================
What is OLE-DB?
OLE-DB is the next step in the evolution of the anonymous data store. As well as being more generic than ODBC, Microsoft has done a great deal of work to ensure that OLE-DB is faster and easier to use than ODBC. Eventually it may well replace ODBC, although that won't be for a long time yet, if only for the reasons that you often have to rely on third parties writing new OLE-DB providers and then when they are available they are often more expensive than existing ODBC drivers. So, consequently, there's a lot more ODBC drivers out there still in use.
The following diagram begins to build up a picture of data access using OLE-DB:
543636_pg467.jpg
As you can see, the idea behind OLE-DB is very similar to the idea behind ODBC – but in fact it allows access to a much broader range of data stores. In fact, you'll notice that OLE-DB even supports database connections through ODBC – so that effectively your generic OLE-DB layer will allow you to connect to your legacy databases through your existing ODBC connections.

Data Providers and Data Consumers

OLE-DB introduces the notion of data providers and data consumers. The relationship between a data provider and a data consumer is fairly obvious: a data provider is something that provides data, and the data consumer is something that uses that data. In reality, you might have several data providers – one for each different type of data store.
At the time of writing, Microsoft itself has made available quite a number of OLE-DB providers for different types of data store, including data providers for their Access, SQL Server, Oracle, Exchange Server, Excel and Foxpro. If you're interested in other external OLE-DB providers here's a list of some of the companies currently in the market:
Company
Product name/support
URL
ASNA
Acceller8DB, DataGate/400
IBM
AS/400
ISG
Oracle, Sybase, RDB, Informix, Inres, D_ISAM, C_ISAM, RMS, Adabas C, VSAM, DB2, IMS/DB
(No valid urls found for this as of 2007)
Merant (formally Intersolv and Micro Focus)
DataDirect (Connect OLE DB and SequeLink OLE DB), Lotus Notes, MAPI-based email, Microsoft Exchange

MetaWise
AS/400, VSAM
(No valid urls found for this as of 2007)
SAS
SAS datasets, SAS/SHARE server
Sequiter
Codebase (FoxPro, dBase, Clipper)
Don't worry if you're not familiar with some of these names. The point to take from all this is that, although this is a fairly new technology, it's got a lot of industry support.
As we said above, the data consumer is just something that uses the data that the data provider provides. So, in this book, the data consumers will be our ASP pages (or more specifically, the ADO objects within our ASP pages that will manipulate the data for display on the page). In another context, we might use the OLE-DB data providers to provide data for other data consumers, such as an application written in a language like Visual Basic or Visual C++.

ASP and OLE-DB

In fact, each OLE-DB data provider is a unit of code, written in a language such as C++ or Java, which uses OLE-DB objects to provide the instructions required to communicate and pass data between the data store and the data consumer. Once you know this, you may be tempted to ask: "Why don't we use the OLE-DB objects directly within our ASP pages, and cut out these OLE-DB providers?"
There's a good reason: the OLE-DB objects themselves are very low-level objects. Scripting languages like VBScript (and even languages like Visual Basic), are simply not sufficiently powerful to allow us to manipulate the OLE-DB objects (although, of course, languages such as C++ and Java are!). That's why we take advantage of the data provider/data consumer mechanism, to pass the data between the data store and the ASP page across a number of intermediate layers.
We've already discussed the data providers – but what of the data consumer? It comes in the form of a set of objects known as the ActiveX Data Objects (or ADO). ADO is an interface that allows our ASP pages to talk to OLE-DB. So, when we use ASP to talk to a data store, we're actually using ASP to talk to ADO, which in turn talks to OLE-DB, which in turn gets information from our data store.
=======================================================================
Visual C++
OLE DB Programming Overview
What is OLE DB, and what makes it distinct from other database technologies? OLE DB is a high-performance, COM-based database technology produced by Microsoft. What sets OLE DB apart from Microsoft's other database technologies is how it provides Universal Data Access.
Universal Data Access provides a common way to access data regardless of the form in which it is stored. In a typical business situation, a vast amount of information is stored outside of corporate databases. This information is found in file systems (such as FAT or NTFS), indexed-sequential files, personal databases (such as Access), spreadsheets (such as Excel), project planning applications (such as Project), and email (such as Outlook).
Accessing this data using the various associated applications presents a major bottleneck in workflow or at least an annoyance. Most companies find themselves in this situation and deal with the problem by consolidating the information in a database management system (DBMS). However, such a move is expensive, time consuming, and in many cases not practical.
The alternative is to develop a Universal Data Access solution. OLE DB and ADO provide Universal Data Access capability. Of the two, OLE DB is the more performance intensive and is recommended for use with Visual C++ applications.
Universal Data Access implies two capabilities: the first is distributed query or uniform access to multiple (distributed) data sources and the second is the ability to make non-DBMS data sources accessible to database applications.
  • Distributed query
The ability to access data uniformly on multiple (that is, distributed) data sources. The data sources can be of the same type (such as two separate Access databases) or of different types (such as a SQL Server database and an Access database). Uniformly means that you can meaningfully run the same query on all data sources.
  • Non-DBMS access
The ability to make non-DBMS data sources accessible to database applications. Examples of DBMS data sources include IMS, DB2, Oracle, SQL Server, Access, and Paradox. Examples of non-DBMS data sources include information in file systems, email, spreadsheets, and project management tools.
Consider a scenario in which a sales department needs to find all email messages received within a one-week period from customers in a certain area. This query might require a search on an email application's mailbox file and a search on an Access table of customers to specify the customers' names. While Access is a DBMS application, Outlook is not.
OLE DB allows you to develop applications that access diverse data sources, whether they are DBMS or not. OLE DB makes universal access possible by using COM interfaces that support the appropriate DBMS functionality for a given data source. COM reduces unnecessary duplication of services and maximized interoperability not only among data sources but also among other applications.
This is where COM comes in. OLE DB is a set of COM interfaces. By accessing data through a uniform set of interfaces, you can organize a database into a matrix of cooperating components.
Based on the COM specification, OLE DB defines an extensible and maintainable collection of interfaces that factor and encapsulate consistent, reusable portions of DBMS functionality. These interfaces define the boundaries of DBMS components such as row containers, query processors, and transaction coordinators, which enable uniform transactional access to diverse information sources.
Typically, OLE DB applications are written as DLLs, but its COM implementation overcomes the disadvantages of DLLs (such as naming and version problems) by using componentized code. In OLE DB, you call interfaces or access other components using their globally unique identifiers (GUIDs).
Finally, COM keeps track of component usage by using reference counting. When you call a method on an interface, the reference count is incremented; when the method returns, the reference count is decremented. When the count equals zero, the component to which the method belongs is released.



바보들의 영문법 카페(클릭!!)

오늘의 메모....

시사평론-정론직필 다음 카페
http://cafe.daum.net/sisa-1

바보들의 영문법 다음 카페
http://cafe.daum.net/babo-edu/

티스토리 내 블로그
http://earthly.tistory.com/

내 블로그에 있는 모든 글들과 자료에 대한 펌과 링크는 무제한 허용됩니다.
(단, 내 블로그에 덧글쓰기가 차단된 자들에게는 펌, 트랙백, 핑백 등이 일체 허용되지 않음.)

그리고 내 블로그 최근글 목록을 제목별로 보시려면....
바로 아래에 있는 이전글 목록의 최근달을 클릭하시면 됩니다.
그러면 제목을 보고 편하게 글을 골라 보실 수 있습니다.

그리고 내 블로그내 글을 검색하시려면 아래 검색버튼을 이용하시면 됩니다.


가가챗창

flag_Visitors

free counters