از مدل معماری مشتری-سرور استفاده شده است. معماری سرویس گیرنده-سرور

تفاوت اصلی بین معماری سرویس گیرنده-سرور و معماری فایل-سرور، انتزاع از نمایش داخلی داده ها (شکل داده های فیزیکی) است. برنامه های مشتری اکنون داده ها را در سطح طرحواره منطقی دستکاری می کنند.

بنابراین، استفاده از معماری سرویس گیرنده-سرور، ایجاد سیستم اطلاعاتی چند کاربره قابل اعتماد (از نظر یکپارچگی داده ها) با یک پایگاه داده متمرکز، مستقل از بخش سخت افزاری (و اغلب نرم افزاری) سرور پایگاه داده و پشتیبانی کننده را ممکن ساخت. رابط کاربری گرافیکیکاربر (GUI) در ایستگاه های مشتری متصل به یک شبکه محلی. علاوه بر این، هزینه های توسعه برنامه ها به طور قابل توجهی کاهش یافته است.

ویژگی های کلیدی:

برنامه مشتری با داده ها از طریق درخواست به نرم افزار سرور کار می کند.

عملکردهای اساسی برنامه بین مشتری و سرور به اشتراک گذاشته می شود.

پشتیبانی کامل از چند کاربر

تضمین یکپارچگی داده ها

منطق تجاری برنامه ها در نرم افزار مشتری باقی ماند. با هر تغییری در الگوریتم ها، لازم است نرم افزار کاربر روی هر کلاینت به روز شود.

الزامات بالا برای پهنای باند کانالهای ارتباطیبا سرور، که از استفاده از ایستگاه های مشتری به جز در شبکه محلی جلوگیری می کند.

حفاظت ضعیف از داده ها در برابر هک، به ویژه از سوی کاربران بی پروا سیستم.

پیچیدگی بالای مدیریت و پیکربندی ایستگاه های کاری کاربر سیستم.

نیاز به استفاده از رایانه های شخصی قدرتمند در سایت های مشتری.

پیچیدگی بالای توسعه سیستم به دلیل نیاز به پیاده سازی منطق تجاری و ارائه رابط کاربریدر یک برنامه

به راحتی می توان متوجه شد که بسیاری از کاستی های معماری کلاسیک یا 2 لایه ای مشتری-سرور از استفاده از ایستگاه مشتری به عنوان یک مجری منطق تجاری IS ناشی می شود. بنابراین، یک گام آشکار در تکامل بیشتر معماری‌های IS، ایده یک "Tin Client" بود، یعنی تقسیم الگوریتم‌های پردازش داده به بخش‌های مربوط به عملکرد عملکردهای تجاری و مربوط به نمایش اطلاعات در یک انسان. -نمایندگی دوستانه در عین حال، تنها قسمت دوم بر روی ماشین کلاینت باقی می ماند که مربوط به بررسی اولیه و نمایش اطلاعات است و تمام قابلیت های واقعی سیستم را به قسمت سرور منتقل می کند.

معماری انتقالی به سه لایه (2.5 لایه)

استفاده از رویه های ذخیره شده و محاسبه داده ها در سمت سرور باعث کاهش ترافیک و افزایش امنیت می شود. مشتری هنوز بخشی از منطق کسب و کار را اجرا می کند.

همانطور که می بینید، چنین سازماندهی سیستم بسیار یادآور سازماندهی اولین سیستم های واحد است، با این تفاوت که مکان کاربر یک ترمینال (با صفحه سبز بدنام) نیست، بلکه کامپیوتر شخصی، که یک رابط کاربری گرافیکی ارائه می دهد، به عنوان مثال، در سال های اخیر، مرورگرهای استاندارد www اغلب به عنوان برنامه های مشتری استفاده می شوند. البته، چنین بازگشتی به سیستم‌های تقریباً واحد قبلاً در سطح فناوری متفاوتی رخ داده است. استفاده از DBMS با تمام مزایای آن اجباری شده است. برنامه ها برای بخش سرور عمدتاً به زبان های تخصصی با استفاده از مکانیسم رویه های ذخیره شده سرور پایگاه داده نوشته می شوند. بنابراین، در سطح یک سازمان منطقی، IS در معماری مشتری-سرور با یک کلاینت نازک به سه لایه تقسیم می شود - یک لایه داده، یک لایه عملکرد تجاری (رویه های ذخیره شده) و یک لایه ارائه. متأسفانه، معمولاً در چنین طرحی برای ساخت IS، نمی توان کل منطق تجاری یک برنامه کاربردی را در زبان های DBMS داخلی که برای این منظور در نظر گرفته نشده است، نوشت. بنابراین، اغلب بخشی از عملکردهای تجاری در بخش مشتری سیستم ها پیاده سازی می شود که ناگزیر از این امر "چاق می شود". تا حدودی به این دلیل و تا حدودی به این دلیل که این IC ها از نظر فیزیکی از دو جزء تشکیل شده اند، این معماری اغلب به عنوان معماری 2.5 لایه مشتری-سرور نامیده می شود.

بر خلاف معماری 2 لایه، معماری 2.5 لایه معمولاً نیازی به کانال های ارتباطی پرسرعت بین بخش های مشتری و سرور سیستم ندارد، زیرا نتایج محاسبات آماده از طریق شبکه منتقل می شود - تقریباً تمام محاسبات در شبکه انجام می شود. سمت سرور. حفاظت از اطلاعات نیز به میزان قابل توجهی بهبود یافته است - به کاربران حق دسترسی به عملکردهای سیستم و عدم دسترسی به داده های آن و غیره داده می شود. با این حال، در کنار مزایای رویکرد واحد، معماری 2.5 نیز تمام معایب خود را اتخاذ می کند، مانند: مقیاس پذیری محدود، وابستگی به پلت فرم نرم افزاریاستفاده محدود از منابع محاسباتی شبکه. علاوه بر این، برنامه‌های بخش سرور سیستم به زبان‌های ساخته شده در DBMS برای توصیف رویه‌های ذخیره‌شده طراحی‌شده برای اعتبارسنجی داده‌ها و ساخت گزارش‌های ساده نوشته می‌شوند، و اصلاً برای نوشتن IS در سطح سازمانی نیستند. همه اینها سرعت سیستم را کاهش می دهد، پیچیدگی ایجاد و اصلاح یک IS را افزایش می دهد و به منفی ترین حالت بر هزینه سخت افزار لازم برای عملکرد آن تأثیر می گذارد.

من فوراً رزرو می کنم که من یک توسعه دهنده تلفن همراه هستم و این مقاله عمدتاً برای توسعه دهندگان در طرف دیگر ابر در نظر گرفته شده است - افراد تلفن همراه قبلاً در مورد همه اینها می دانند. آخرین برنامه وب که من نوشتم سال ها پیش بود و ممکن است در اصطلاحات وب اشتباه کنم، برخی از آخرین روندهای وب سرویس های دات نت، پی اچ پی یا جاوا را نمی دانم، پس خیلی سخت قضاوت نکنید.

مانند هر توسعه‌دهنده فرانت‌اند، تقریباً در هر پروژه‌ای باید با پروتکل‌های کلاینت-سرور سر و کار داشته باشم - بدون آنها نمی‌توانم کار کنم. و خیلی خیلی اوقات شما باید با معماری ضعیف کار کنید.

همچنین، اغلب اوقات توسعه یک پروتکل و معماری بر دوش یک توسعه‌دهنده وب قرار می‌گیرد، که همیشه درست نیست - در بیشتر موارد باید تنها در ارتباط با کسانی که با این معماری سازگار هستند توسعه یابد. متأسفانه، در حالی که در طول سه سال گذشته روی چندین ده پروژه کار می کردم، فقط 3 یا 4 بار درگیر برنامه ریزی این بخش از معماری بودم - در همه موارد دیگر، قبلاً با درجات مختلفی از آمادگی ارائه شده است. مشتری. چقدر دنیا می تواند بهتر باشد!

خطا در پردازش

کد HTTP 200 (OK) نادرست نام کاربری یا رمز عبور اشتباه است. لطفا دوباره تلاش کنید.
آن ها نتیجه پردازش درخواست در خود XML موجود است، کد بازگشتی HTTP 200 است، یعنی. به طور معمول، داده ها در قالب یک RPC معمولی ارائه می شوند. به عنوان مثال، به روشی مشابه، در 90 درصد موارد، مدیریت خطا در پروتکل SOAP پیاده سازی می شود.

در موارد به خصوص نادیده گرفته شده، به ویژه برای کد هندو، false را می توان در مکان های مختلف XML قرار داد، که تجزیه را به طور قابل توجهی پیچیده می کند، منجر به موارد بیش از حد پیچیده می شود، و برنامه نویس بی حوصله را بسیار خوشحال می کند.

اما اجازه دهید در اصل به کاستی های این رویکرد نگاه کنیم.

• ابتدا باید XML را تجزیه کنید. این داده های اضافی منتقل شده از طریق شبکه، زمان اضافی CPU صرف شده برای تجزیه XML، اضافی است رمبرای ذخیره داده های متنی همه اینها در دستگاه های مدرن در منطقه Wi-Fi چندان ترسناک نیست، اما حتی چنین زیاده روی هایی می تواند تفاوتی در مترو بین ایستگاه ها در برنامه ای ایجاد کند که ده ها درخواست را به طور همزمان ارسال می کند (و با این رویکرد، بلوک های خالی برای رسیدگی به خطا باید در هر درخواست، حتی موفق باشید).
• ثانیاً، توسعه‌دهنده وب باید خود متن‌های خطا را اختراع کند. اغلب آنها برای کاربر کاملاً نامفهوم هستند، زیرا دقت جمله بندی آخرین چیزی است که یک توسعه دهنده وب هنگام نوشتن یک سرویس به آن فکر می کند. متن خطا در 90٪ موارد با زبان مادری موافق نیست، و در نهایت، تعداد زیادی از برنامه های تلفن همراه نیاز به بومی سازی دارند. در حالی که متن خطا به احتمال زیاد همیشه فقط به زبان انگلیسی نوشته می شود، بنابراین برای یک برنامه نویس جلویی کاملاً بی فایده است - او نمی تواند آن را بگیرد و چاپ کند.

اما زمان مورد نیاز یک برنامه نویس وب برای اختراع متن پیام تلف می شود و حتی کانال با اطلاعات غیر ضروری بارگذاری می شود.

چگونه یک مشکل را حل کنیم؟

که در پروتکل HTTPسال‌هاست که می‌توان کدهای خطای خود را اضافه کرد، برای این منظور آنها باید به محدوده 512 تا 597 تعلق داشته باشند. من مطمئن هستم که این تعداد خطا برای پوشش همه موارد کافی است. خطاهای احتمالیدر یک برنامه با اندازه متوسط واضح است که این چه مزایایی دارد، اما با این حال اجازه دهید خلاصه کنیم:

1. هیچ اضافه کاری وجود ندارد. فقط کد HTTP در هدر ارسال می شود، به سادگی هیچ بدنه درخواستی وجود ندارد.
2. در سمت سرویس گیرنده، تنها دو شاخه از کد پردازش درخواست وجود دارد - اجرای موفقیت آمیز، یا یک خطا در حین اجرا (هر دو فراخوان قبلاً خارج از جعبه در هر کتابخانه درخواستی اجرا شده اند). هیچ "درخواستی با موفقیت تکمیل شد، اما ممکن است یک خطای منطقی در بدنه پاسخ" وجود داشته باشد.

خطای سرور 5xx

سرور نتوانست درخواست ظاهرا معتبری را برآورده کند.
کدهای وضعیت پاسخ که با رقم "5" شروع می شود مواردی را نشان می دهد که در آن سرور متوجه شده است که با خطا مواجه شده است یا در غیر این صورت قادر به انجام درخواست نیست. به جز زمانی که به درخواست HEAD پاسخ می‌دهد، سرور باید یک موجودیت حاوی توضیحی از وضعیت خطا را شامل شود و مشخص کند که آیا این یک وضعیت موقتی یا دائمی است. به همین ترتیب، عوامل کاربر باید هر موجودیتی را که شامل می شود به کاربر نمایش دهند. این کدهای پاسخ برای هر روش درخواستی قابل اجرا هستند.

آن ها مشتریان باید پیام ارسال شده توسط سرور را به کاربر نشان دهند. بلافاصله مشخص می شود که آمریکایی ها چه نوشته اند. اتفاقاً روس ها احمقانه ترجمه کردند.

اگرچه ما تعمیم نمی دهیم - ایده استفاده از کدهای HTTP چند سال پیش توسط یک آمریکایی به من پیشنهاد شد.

به طور کلی، ایدئولوژی این است - مشتری همیشه بهتر می داند که چگونه یک خطا را گزارش کند. و سرور باید به سریع ترین و مقرون به صرفه ترین روش خطا را به مشتری اطلاع دهد.

اتصال به جلسه یا کوکی.

چنین الزام‌آوری به احتمال زیاد در صورتی اتفاق می‌افتد که ابتدا وب‌سایت ایجاد شده باشد، و تنها پس از آن مشتری تصمیم به ایجاد یک نمای تلفن همراه داشته باشد. اگرچه می توان با متغیرهای جلسه از سمت تلفن همراه کار کرد، اما این عمل خوبی نیست، زیرا اغلب هیچ جعبه ابزار معمولی برای کار با این ابزارها وجود ندارد.

دومین عیب جهانی این است که سافاری (یا هر مرورگری در اندروید) کوکی‌ها و متغیرهای نشست خود را با برنامه به اشتراک نمی‌گذارد که البته از نظر امنیت درست است، اما منجر به یکسری مشکلات و عصا می‌شود.

فرض کنید اپلیکیشن موبایل شما تنها 70 درصد از عملکرد وب سایت را اجرا می کند. 30٪ باقیمانده از عملکرد فقط در وب در دسترس است و برنامه شما فقط حاوی پیوندهایی به صفحات وب مربوطه است.

همچنین ممکن است این صفحات فقط برای کاربران مجاز در دسترس باشد. در نتیجه، کاربری که قبلاً وارد شده است مشتری موبایل، از شما خواسته می شود دوباره وارد شوید - اکنون در یک فرم وب ناخوشایند، و اگر پس از ورود کاربر به بخش مورد نظر سایت هدایت شود، خوش شانس خواهد بود.

نتیجه - اگر در حال طراحی یک پروتکل عمومی هستید، مواردی مانند متغیرهای جلسه و کوکی ها را فراموش کنید. یک راه بسیار بهتر این است که برخی از نشانه های منحصر به فرد به دست آمده در طول مجوز را به طور صریح در بدنه هر درخواست ارسال کنید. و صفحات وب و برنامه های کاربردی وب - برای انطباق با استفاده از یک API واحد. من مطمئن هستم که همه توسعه دهندگان تلفن همراه اغلب دو نسخه از API را دیده اند - یکی برای برنامه های کاربردی وب و دیگری برای موبایل. اما این یک عملکرد تکراری است که همیشه هم در مرحله توسعه و هم در مرحله اشکال‌زدایی گران‌تر است. همیشه بهتر است وب سرویس ها را از همان ابتدا در یک لایه مجزا از سیستم جدا کنید، نه اینکه آنها را در سایر بخش های نزدیک به فناوری های وب جاسازی کنید.

بازگشت HTML

این قبلاً ریشه در طراحی خود سرورهای وب دارد که در ابتدا فقط برای مرورگر طراحی شده بودند. خطاهای 403، 404، و گاهی اوقات خطاهای پیچیده تر، اغلب به عنوان یک صفحه HTML برگردانده می شوند، که اغلب به سادگی ابزاری برای نشان دادن در آن ندارند. اپلیکیشن موبایل. به طور دقیق تر، وجوه وجود دارد، اما وقتی صفحه 404 را می بینید پیدا نشدبا یک Arial Black سیاه و سفید در پس‌زمینه‌ای سفید در داخل یک نمای وب، کاربر تلفن همراه عصبانی می‌شود و برنامه را می‌بندد.

به یاد داشته باشید، سرور باید XML (یا JSON) را برای هر درخواستی به سرویس های وب، و فقط در قالبی که در ابتدا توافق شده است، برگرداند. یک توسعه دهنده تلفن همراه نمی تواند کار ارزشمندی با HTML که از سرور می آید انجام دهد.

از WSDL استفاده کنید

در مورد فناوری های مایکروسافت، وضعیت هنوز هیچ چیز نیست - بیشتر آنها فن آوری های مدرناز WSDL خارج از جعبه پشتیبانی می کند. این را نمی توان در مورد PHP و جاوا گفت - به خصوص توسعه دهندگان PHP علاقه زیادی به ایجاد دستی صفحات معمولی که اساساً خدمات وب هستند، دارند. اما برای ادغام با یک سرویس وب سازگار با WSDL، کافی است یک توسعه‌دهنده موبایل از ابزاری برای تولید کد استفاده کند، در حالی که پاسخ‌های سرویس وب کامپایل شده دستی نیز باید با دست تجزیه شوند.

درست است، در اینجا نیز نکات ظریفی وجود دارد - پیاده‌سازی استاندارد WSDL از MS و Sun (Oracle) هنوز ناسازگاری‌هایی دارند، اما هنوز هم رفع این ناسازگاری‌ها با یک فایل سریع‌تر از نوشتن دستی همه چیز است.

نتیجه

من فقط دردناک ترین اشتباهات طراحی را که توسعه دهندگان موبایل هر روز با آن روبرو هستند، لمس کرده ام. اگر مقاله مورد تقاضا باشد، من قطعاً در مورد ده ها ظرافت مشتری-سرور دیگر خواهم نوشت که بسیار دوست دارم در API سرویس های وب که هر روز با آنها کار می کنید ببینم.

معماری سرویس گیرنده-سرور(معماری مشتری-سرور) مفهوم است شبکه اطلاعات، که در آن بخش عمده ای از منابع آن در سرورهایی متمرکز شده است که به مشتریان خود خدمات ارائه می دهند. معماری مورد بحث دو نوع مؤلفه را تعریف می کند: سرورها و مشتریان.

سرور -یک شی است که فراهم می کند سرویسسایر اشیاء شبکه به درخواست آنها. سرویسیک فرآیند خدمات مشتری است.

شکل معماری مشتری-سرور

سرور بر اساس دستورالعمل های مشتریان کار می کند و اجرای وظایف آنها را مدیریت می کند. پس از اجرای هر کار، سرور نتایج را برای مشتری ارسال کننده کار ارسال می کند.

عملکرد سرویس در معماری سرویس گیرنده-سرور توسط مجموعه ای از برنامه های کاربردی توصیف می شود که مطابق با آنها فرآیندهای برنامه های مختلف انجام می شود.

فرآیندی که فراخوانی می کند عملکرد خدماتاز طریق عملیات خاصی نامیده می شود مشتری. این می تواند یک برنامه یا یک کاربر باشد. مشتریانایستگاه های کاری هستند که از منابع سرور استفاده می کنند و راحت هستند رابط های کاربری. رابط های کاربریاینها رویه هایی برای تعامل کاربر با یک سیستم یا شبکه هستند.

شکل مدل کلاینت-سرور

مشتری آغازگر است و استفاده می کند پست الکترونیکیا سایر خدمات سرور در این فرآیند، مشتری یک سرویس را درخواست می کند، یک جلسه ایجاد می کند، نتایج مورد نظر خود را دریافت می کند و پس از انجام آن گزارش می دهد.

که در شبکه هایی با فایل سرور اختصاصیدر یک مستقل اختصاصی کامپیوتریک سیستم عامل شبکه سرور نصب شده است. این کامپیوترتبدیل می شود سرورنرم افزار ( توسط), نصب شده بر روی ایستگاه کاری، به آن اجازه می دهد تا با سرور ارتباط برقرار کند. رایج ترین سیستم عامل های شبکه عبارتند از:

علاوه بر سیستم عامل شبکه، برنامه های کاربردی شبکه نیز برای استفاده از مزایای شبکه مورد نیاز است.

شبکه های مبتنی بر سرور دارند بهترین عملکردو افزایش قابلیت اطمینان سرور مالک اصلی است منابع شبکه، بهتوسط ایستگاه های کاری دیگر استفاده می شود.

در معماری مدرن مشتری-سرور، چهار گروه از اشیاء متمایز می شوند: سرویس گیرندگان، سرورها، داده ها و خدمات شبکه. کلاینت ها در سیستم های ایستگاه های کاری کاربر قرار دارند. داده ها بیشتر در سرورها ذخیره می شوند. خدمات شبکهسرورها و داده های مشترک هستند. علاوه بر این، سرویس ها رویه های پردازش داده ها را مدیریت می کنند.

شبکه های معماری کلاینت-سرور دارای مزایای زیر هستند:

امکان ایجاد شبکه مقدار زیادایستگاه های کاری؛

ارائه حساب کاربری متمرکز، امنیت و مدیریت دسترسی که مدیریت شبکه را ساده می کند.

دسترسی کارآمد به منابع شبکه؛

کاربر برای ورود به شبکه و دسترسی به تمام منابعی که مشمول حقوق کاربر هستند به یک رمز عبور نیاز دارد.

در کنار مزایای شبکه، معماری سرویس گیرنده-سرور دارای معایبی نیز می باشد:

خرابی سرور می تواند شبکه را غیرقابل استفاده کند، حداقل منابع شبکه را از دست بدهد.

نیاز به پرسنل واجد شرایط برای مدیریت؛

هزینه شبکه بالاتری داشته باشد و تجهیزات شبکه.

سیستم های "مشتری-سرور". قسمت 2

در قسمت سوم نمونه ای از سازه سه لایه در نظر گرفته شده است سرور بایکونور.

همه اینها عملکرد سیستم را افزایش می دهد و زمان انتظار برای نتیجه پرس و جو را کاهش می دهد. هنگامی که کوئری ها توسط سرور اجرا می شوند، درجه امنیت داده ها به طور قابل توجهی افزایش می یابد، زیرا قوانین یکپارچگی داده ها در پایگاه داده روی سرور تعریف شده است و برای همه برنامه هایی که از این پایگاه داده استفاده می کنند یکسان است. بنابراین، امکان تعریف قوانین متضاد برای حفظ یکپارچگی منتفی است. دستگاه تراکنش قدرتمندی که توسط سرورهای SQL پشتیبانی می‌شود به شما امکان می‌دهد تغییرات همزمان داده‌های یکسان توسط کاربران مختلف را حذف کنید و این امکان را فراهم می‌کند که هنگام ایجاد تغییرات در پایگاه داده که در شرایط اضطراری به پایان می‌رسد، به مقادیر اصلی برگردید [[3.2]، 3.3]].

برنج. 3.3.معماری سرویس گیرنده-سرور

• وجود دارد شبکه محلی، متشکل از رایانه های مشتری که هر کدام دارای برنامه مشتریبرای کار با پایگاه داده
• در هر یک از رایانه های مشتری، کاربران توانایی اجرای برنامه را دارند. با استفاده از رابط کاربری ارائه شده توسط برنامه، تماسی را با DBMS واقع در سرور برای واکشی/به‌روزرسانی اطلاعات آغاز می‌کند. برای ارتباط استفاده می شود زبان خاصپرس و جوهای SQL، به عنوان مثال فقط متن درخواست از طریق شبکه از مشتری به سرور منتقل می شود.
• DBMS فراخوانی به داده های واقع در سرور را آغاز می کند، در نتیجه تمام پردازش داده ها بر روی سرور انجام می شود و تنها نتیجه پرس و جو در رایانه مشتری کپی می شود. بنابراین، DBMS نتیجه را به برنامه باز می گرداند.

بیایید نگاهی به نحوه جداسازی توابع بین سرور و کلاینت بیندازیم.

• ویژگی های مشتری برنامه:
  • ارسال درخواست به سرور
  • تفسیر نتایج پرس و جوهای دریافتی از سرور.
  • ارائه نتایج به کاربر به شکلی (رابط کاربری).
• توابع بخش سرور:
  • دریافت درخواست از برنامه های مشتری
  • تفسیر درخواست ها
  • بهینه سازی و اجرای پرس و جو در پایگاه داده.
  • ارسال نتایج به برنامه مشتری
  • اطمینان از سیستم امنیتی و کنترل دسترسی.
  • مدیریت یکپارچگی پایگاه داده
  • اجرای پایداری حالت عملکرد چند کاربره.

DBMS های به اصطلاح "صنعتی" در معماری "مشتری-سرور" کار می کنند. آنها صنعتی نامیده می شوند زیرا DBMS این کلاس است که می تواند عملکرد سیستم های اطلاعاتی در مقیاس یک شرکت متوسط ​​و بزرگ ، سازمان ، بانک را تضمین کند. MS SQL Server , Oracle , Gupta , Informix , Sybase , DB2 , InterBase و تعدادی دیگر به دسته DBMS های صنعتی [ [ 3.2 ] ] تعلق دارند.

به عنوان یک قاعده، سرور SQL توسط یک کارمند منفرد یا گروهی از کارمندان (مدیران سرور SQL) نگهداری می شود. آنها ویژگی های فیزیکی پایگاه های داده را مدیریت می کنند، بهینه سازی، تنظیم و تعریف مجدداجزای مختلف پایگاه داده، ایجاد پایگاه‌های اطلاعاتی جدید، اصلاح پایگاه‌های موجود و غیره، و همچنین صدور امتیازات (مجوزهای دسترسی سطح معین به یک پایگاه داده خاص، سرور SQL) برای کاربران مختلف [3.2].

مزایای اصلی این معماری را در مقایسه با معماری "فایل - سرور" در نظر بگیرید:

• به طور قابل توجهی ترافیک شبکه را کاهش داد.
• پیچیدگی برنامه های کلاینت کاهش می یابد (بیشتر بار روی قسمت سرور می افتد) و در نتیجه الزامات ظرفیت های سخت افزاری رایانه های مشتری کاهش می یابد.
• در دسترس بودن یک ویژه ابزار نرم افزاری- SQL-server - منجر به این واقعیت می شود که بخش قابل توجهی از وظایف طراحی و برنامه نویسی قبلاً حل شده است.
• به طور قابل توجهی یکپارچگی و امنیت پایگاه داده را بهبود می بخشد.

معایب شامل هزینه های مالی بالاتر برای سخت افزار و نرم افزار، و همچنین آن تعداد زیادی ازکامپیوترهای مشتری واقع در جاهای مختلف، مشکلات خاصی را با به روز رسانی به موقع برنامه های مشتری در همه رایانه های مشتری ایجاد می کند. با این حال، معماری مشتری-سرور در عمل به خوبی کار کرده است. در حال حاضرتعداد زیادی پایگاه داده که مطابق با این معماری ساخته شده اند وجود دارد و کار می کند.

3.4. معماری سه لایه (چند لایه) "مشتری-سرور".

سه پیوندی (در برخی موارد چند پیوندی) معماری(N-tier یا چند- معماری سه لایه? اکنون هنگام تغییر منطق کسب و کار، دیگر نیازی به تغییر اپلیکیشن های کلاینت و به روز رسانی آن ها برای تمامی کاربران نیست. علاوه بر این، الزامات تجهیزات کاربر تا حد امکان کاهش می یابد.

بنابراین، در نتیجه، ساختار کار به شرح زیر است:

• پایگاه داده در قالب مجموعه ای از فایل ها بر روی هارد یک کامپیوتر اختصاصی (سرور شبکه) قرار دارد.
• DBMS نیز بر روی سرور شبکه قرار دارد.
• یک سرور برنامه اختصاصی وجود دارد که میزبان نرم افزار تجزیه و تحلیل کسب و کار (منطق تجاری) [ [ 3.1 ] ] است.
• کامپیوترهای کلاینت زیادی وجود دارند که هر کدام دارای یک به اصطلاح "Tin Client" هستند - یک برنامه کلاینت که رابط کاربری را پیاده سازی می کند.
• در هر یک از رایانه های مشتری، کاربران این فرصت را دارند که یک برنامه کاربردی - یک کلاینت نازک را اجرا کنند. با استفاده از رابط کاربری ارائه شده توسط برنامه، تماسی را با نرم افزار هوش تجاری واقع در سرور برنامه آغاز می کند.
• سرور برنامه نیازهای کاربر را تجزیه و تحلیل می کند و درخواست هایی را برای پایگاه داده ایجاد می کند. برای برقراری ارتباط، از یک زبان پرس و جوی SQL استفاده می شود، به عنوان مثال. فقط متن درخواست از طریق شبکه از سرور برنامه به سرور پایگاه داده منتقل می شود.
• DBMS تمام اطلاعات مربوط به ساختار فیزیکی پایگاه داده واقع در سرور را در خود محفوظ می دارد.
• DBMS فراخوانی به داده های واقع در سرور را آغاز می کند که در نتیجه نتیجه پرس و جو در سرور برنامه کپی می شود.
• سرور برنامه نتیجه را به برنامه مشتری (به کاربر) برمی گرداند.
• برنامه با استفاده از رابط کاربری، نتیجه اجرای پرس و جو را نمایش می دهد.