تحقیق در مورد ODBC
مقــدمه :
ODBC یک API ارتباطی مستقل از سیستم عامل و پایگاه داده ها می باشد که به یک برنامه سرویس گیرنده امکان می دهد تا از طریق فراخوانی توابع مبتنی بر استاندارد به پایگاه داده back – end و بدون تکیه بر پروتکل های ارتباطی اختصاصی مختص پایگاه داده ارتباط برقرار کند .
چرا این مهم است ؟ چرا نباید فقط با Oracle یا SQL Server یا Informix کار کرد و کار را با آنها به پایان برد ؟ چندین دلیل وجود دارد . مشخص نبودن سکو و پایگاه داده در یک برنامه ، قابلیت حمل و آزادی را فراهم می کند . اهمیت این آزادی وقتی به سرعت مشخص می شود که محدودیت های فقط یک پایگاه داده و سکو را در مورد مقیاس پذیری ، سرعت ، گواهی یا هر عامل متغیر دیگری بین سیستم های تولید مختلف در نظر بگیریم . ODBC همچنین امکان ایجاد برنامه ها بر روی محیط های ایجاد و توسعه desktop را با حداکثر استفاده روی سکو فراهم می کند .
همچنین هر پایگاه داده ای برای هر کاری خوب نیست . MySQL به شکل کنونی خود یک پایگاه داده فقط خواندنی است که برای سایت های وب ، محتویات را فراهم می کند ، ولی ممکن است ترجــیح دهید که برای یک warehouse داده ها یا Virtuoso ازOracle به عنوان پایگاه داده استفاده کنید .
تاریخچــه و اهداف ODBC :
حدود سال 1990 ، عرضه کنندگان پایگاه داده UNIX شامل Oracle ، Informix و IBM به عنوان بخشی از SQL Access Group ، یک CLI (Call – Level Interface) را ارائه کردند تا امکان استفاده از SQL را به روش قابل انتقال فراهم کند .
قبل از SAG CLI ، تنها راه استفاده از SQL به صورت Embedded SQL بود ، به این معنی که دستورات SQL در زبان برنامه نویسی شما می بایستی از یک پیش کامپایلر مختص زبان رد می شد که دستورات را به زبان API پایگاه داده مورد نظر می شکست . Embedded SQL ، دست و پا گیر بود و عرضه کنندگان پایگاه داده در SAG و گروه X/Open مربوطه جمع شدند تا یک واسط SQL قابل حمل را ایجاد کنند که بتواند بین پایگاه داده های مختلف و بدون پیش کامپایلر خاص زبان مورد استفاده قرار گیرد .
SAG CLI مبتنی بر یک زیر مجموعه از مشخصات SQL بنام Static SQL می باشد که ANSI SQL86 نیز نامیده می شود . این مشخصه طوری گسترش یافت که Dynamic SQL را نیز پوشش داد و عرضه کنندگان مختلفی مثل IBM و Informix به سرعت این CLI را به عنوان استاندارد بدون چون و چرا ، برای SQL در پایگاه داده های خود اتخاذ کردند .
در سال 1992 ، مایکروسافت ، SQL CLI را در یک مجموعه از واسط ها به نام ODBC پیاده سازی کرد و SAG CLI را طوری گسترش داد که شامل توابعی برای پرس و جو و کنترل درایورها و دستیابی به کاتالوگ پایگاه داده شود . مایکروسافت با درک این مطلب که یک مجموعه از ابزارهای گرافیکی و SDK ها اتخاذ را ممکن می کنند ، قابلیت استفاده از SAG CLI را بهبود بخشید و شروع به حمایت شدید از ODBC در برابر شرکاء و مشتریان خود کرد .
بعد از چند سال ، مایکروسافت OLE – DB را به عنوان جایگزین ODBC پیاده سازی کرد . OLE – DB در ابتدا می تواند به صورت یک لایه آبجکتی تلقی شود که به ODBC اضافه شده است ، ولی مایکروسافت خیلی زود درایورهای OLE – DB را پیاده سازی کرد که نیاز به پشتیبانی از ODBC نداشتند . این می تواند به عنوان یک حرکت تجاری استراتژیک برای کنترل دستیابی به داده ها توسط مایکروسافت تلقی شود ، زیرا OLE – DB فقط به سکوی ویندوز محدود است ، ولی این ناموفق بود . ODBC استاندارد بدون چون و چرا برای دستیابی به موتورهای مبتنی برSQL شده بود و برای رابطه های بین سکویی به کار می رفت .
معمــاری ODBC :
معماری ODBCاز چند بخش تشکیل شده است . بیایید با شروع از سرویس گیرنده در یک اتصال ساده حرکت کنیم . برای این بحث ، سرویس گیرنده را به وسیله محل برنامه ( مثلا PHP ) شناسایی می کنیم .
برنامه PHP مثل یک سرویس گیرنده برای سرور پایگاه داده عمل می کند . با حرکت از PHP در طول این اتصال معمولا به یک Data Source Name ( DSN ) ، درایور ODBC ، مدیر درایور ( DM ) ODBC ، یک لایه ارتباطی و خود سرور پایگاه داده ، برخورد می کنیم :
فهرست مطالب
مقدمــه 1
تاریخچه و اهداف ODBC 1
معماری ODBC 3
استانداردهای SQL 5
نصب PHP و ODBC بر روی ویندوز 6
API برای ODBC در PHP 7
اتصال به پایگاه داده 7
کار با فرا داده ( Meta Data ) 9
کار با تراکنش ها ( Mainpulating Transaction ) 10
بازیابی داده ها و Cursor ها 11
مشکلات معمول 13
پیش نیازهای اتصالات ODBC 13
استفاده از Ms SQL Server 14
استفاده از Ms Access 15
انتراع پایگاه داده 15
آشنایی با مفاهیم ADO و ODBC 17
تعریف کردن نام منابع داده های ODBC 20
باز کردن مدیر منابع داده های ODBC 20
نکات دیگری درباره ODBC 21
منابع مورد استفاده 25