Foreversoft.ru

IT Справочник
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

В многоуровневой архитектуре на клиенте располагается

МИГКУ ИТ-51вс

Метки

Добавить страницу

Централизованная система

Все данные на одном ПК. Таких приложений вагон и маленькая тележка — от всяких наколенных поделок на M$ Access до Mozilla Firefox (он использует файловую СУБД SQLite для хранения некоторых данных)

Архитектура «файл-сервер»

Наиболее простой случай распределённой обработки данных, на сервере располагаются только файлы БД, а клиентское приложение оперирует собственной копией СУБД, самостоятельно работает с данными, получаемыми от сервера.
Использование файл-серверов предполагает, что вся обработка данных выполняется на рабочей станции, а фал-сервер лишь выполняет функции накопителя данных и средств доступа.

Двухуровневая архитектура «клиент-сервер»

Основана на использовании только сервера баз данных, когда клиентская часть содержит уровень представления данных, а на сервере находится база данных вместе с СУБД и прикладными программами.
Сервер баз данных отличается от файл-сервера тем, что в его оперативной памяти, помимо операционной системы, функционирует централизованная СУБД, обеспечивающая совместное использование рабочими станциями базы данных, размещённой во внещней памяти этого сервера.
Сервер баз данных даёт возможность отказаться от пересылки по сети файлов данных и передавать только ту выборку из базы данных, которая удовлетворяет запросу пользователя.

Трёхуровневая архитектура «клиент-сервер»

Позволяет помещать прикладные программы на отдельные серверы приложений, с которыми через API-интерфейс устанавливается связь клиентских рабочих станций (как Deathmatch в Quake). Работа клиентской части приложения сводится к вызову необходимых функций сервера приложения, которые называются «сервисами». Прикладные прогаммы в свою очередь обращаются к серверу баз данных с помощью SQL-запросов.
Плюсы:

  • многократность повторного использования общих функций обработки данных в множестве клиентских приложений при существенной экономии системных ресурсов
  • параллельность в работе сервера приложений и сервера баз данных, причём сервер приложений может быть менее мощным, чем сервер баз данных
  • оптимизация доступа к базе данных через сервер приложений из клиентских мест путём диспетчиризации выполнения запросов в вычислительной сети
  • повышение скорости и надёжности обработки данных в результате дублирования программного обеспечения на нескольких серверах приложений, которые могут заменять друг друга в сети в случае перегрузки или выхода из строя одного из них
  • перенос функций администрирования системы по проверке полномочий доступа пользователей с сервера баз данных на сервер приложений.

Многоуровневая архитектура «клиент-сервер»

Вариант для территориально-распределённых предприятий. Наиболее удачным примером будет предприятие с легионом филиалов со своими копиями БД, адаптированными под региональные и функциональные обстоятельства, и центральным офисом с интегрированной (полной) базой данных для централизованного ведения и администрирования (и анализа, Холмс!) общих данных для всех филиалов.
Возможны следующие режимы репликации данных:

синхронный тиражируемые данные обновляются по мере возникновения необходимости одновременно на серверах баз данных и во всех копиях. Требуемое быстродействие может исчисляться в единицах Мбит по-сравнению с единицами Кбит при асинхронном режиме асинхронный тиражирование происходит в строго определённые моменты времени, например каждый час работы информационной системы.

равноправное в обоих направлениях (да, это невероятно звучит) сверху-вниз («ведущий-ведомый») когда на серверах филиалов содержатся только некоторые подмножества данных центральной базы данных. снизу-вверх при обновлении данных в филиалах в определённые моменты времени обновляется центральная база данных.

IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов.

О модели взаимодействия клиент-сервер простыми словами. Архитектура «клиент-сервер» с примерами

  • 28.07.2016
  • Сервера и протоколы
  • Комментариев нет

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем рубрику Сервера и протоколы. В этой записи мы поговорим о том, как работают приложения и сайты в сети Интернет, да и вообще в любой компьютерной сети. В основе работы приложения лежит так называемая модель взаимодействия клиент-сервер, которая позволяет разделять функционал и вычислительную нагрузку между клиентскими приложениями (заказчиками услуг) и серверными приложениями (поставщиками услуг).

Модель взаимодействия клиент-сервер. Архитектура «клиент-сервер».

Итак, небольшая аннотация к записи: сначала мы разберемся с концепцией взаимодействия клиент сервер. Затем поговорим о том зачем вообще веб-мастеру нужно понимать модель клиент-сервер. Далее мы посмотрим на архитектуру приложений, которые работают по принципу клиент-сервер и в завершении рассмотрим преимущества и недостатки данной модели.

Концепция взаимодействия клиент-сервер

Миллионы людей каждый день выходят в сеть Интернет, чтобы почитать новости, пообщаться с друзьями, получить полезную информацию, совершить покупку или оплатить счет. Но большая часть рядовых пользователей даже не догадывается о том, как и с помощью чего они всё это делают, да на самом деле большинству людей это и не нужно, главное, чтобы они получали услугу вовремя и качественно.

Здесь мы разберемся с концепцией, которая позволяет нам выполнять все эти действия в сети Интернет. Данная концепция получила название «клиент-сервер». Как понятно из названия, в данной концепции участвуют две стороны: клиент и сервер. Здесь всё как в жизни: клиент – это заказчик той или иной услуги, а сервер – поставщик услуг. Клиент и сервер физически представляют собой программы, например, типичным клиентом является браузер. В качестве сервера можно привести следующие примеры: все HTTP сервера (в частности Apache), MySQL сервер, локальный веб-сервер AMPPS или готовая сборка Denwer (последних два примера – это не проста сервера, а целый набор серверов).

Клиент и сервер взаимодействую друг с другом в сети Интернет или в любой другой компьютерной сети при помощи различных сетевых протоколов, например, IP протокол, HTTP протокол, FTP и другие. Протоколов на самом деле очень много и каждый протокол позволяет оказывать ту или иную услугу. Например, при помощи HTTP протокола браузер отправляет специальное HTTP сообщение, в котором указано какую информацию и в каком виде он хочет получить от сервера, сервер, получив такое сообщение, отсылает браузеру в ответ похожее по структуре сообщение (или несколько сообщений), в котором содержится нужная информация, обычно это HTML документ.

Сообщения, которые посылают клиенты получили названия HTTP запросы. Запросы имеют специальные методы, которые говорят серверу о том, как обрабатывать сообщение. А сообщения, которые посылает сервер получили название HTTP ответы, они содержат помимо полезной информации еще и специальные коды состояния, которые позволяют браузеру узнать то, как сервер понял его запрос.

Сейчас мы схематично описали, как взаимодействуют клиент и сервер на седьмом уровне модели OSI, но, на самом деле это взаимодействие происходит на всех семи уровнях. Когда клиент отправляет запрос, сообщение упаковывается, можно представить, что сообщение заворачивается в семь оберток (хотя их может быть намного больше или же меньше), а когда сообщение получает сервер, он начинает эти обертки разворачивать.

Читать еще:  Архитектурная концепция состав

Также стоит заметить, что в основе взаимодействия клиент-сервер лежит принцип того, что такое взаимодействие начинает клиент, сервер лишь отвечает клиенту и сообщает о том может ли он предоставить услугу клиенту и если может, то на каких условиях. Клиентское программное обеспечение и серверное программное обеспечение обычно установлено на разных машинах, но также они могут работать и на одном компьютере.

Данная концепция взаимодействия была разработана в первую очередь для того, чтобы разделить нагрузку между участниками процесса обмена информацией, а также для того, чтобы разделить программный код поставщика и заказчика. Ниже вы можете увидеть упрощенную схему взаимодействия клиент-сервер.

Простая схема взаимодействия клиент-сервер

Мы видим, что к одному серверу может обращаться сразу несколько клиентов (действительно, на одном сайте может находиться несколько посетителей). Также стоит заметить, что количество клиентов, которые могут одновременно взаимодействовать с сервером зависит от мощности сервера и от того, что хочет получить клиент от сервера.

Многие сетевые протоколы построены на архитектуре клиент-сервер, поэтому в их основе обычно лежат одинаковые или схожие принципы взаимодействия, а разницу мы видим лишь в деталях, которые обусловлены особенностями и спецификой области, для которой разрабатывался тот или иной сетевой протокол.

Почему веб-мастеру нужно понимать модель взаимодействия клиент-сервер

Давайте теперь ответим на вопрос: «зачем веб-мастеру или веб-разработчику понимать концепцию взаимодействия клиент-сервер?». Ответ, естественно, очевиден. Чтобы что-то делать своими руками нужно понимать, как это работает. Чтобы сделать сайт и, чтобы он правильно работал в сети Интернет или хотя бы просто работал, нам нужно понимать, как работает сеть Интернет.

Мы уже упоминали, что большая часть сетевых протоколов имеют архитектуру клиент-сервер. Например, веб-мастеру или веб-разработчику будут интересны протоколы седьмого и шестого уровня эталонной модели. Сетевым администраторам важно понимать, как происходит взаимодействие на уровнях с пятого по второй. Для инженеров связи наибольший интерес представляют протоколы с четвертого по первый уровень модели OSI.

Поэтому если вы действительно хотите быть профессионалом в сфере web, то сперва вам необходимо понимать, как происходит взаимодействии в сети (именно на седьмом уровне), а уже потом начинать изучать инструменты, которые позволят создавать сайты.

Архитектура «клиент-сервер»

Архитектура клиент-сервер определяет лишь общие принципы взаимодействия между компьютерами, детали взаимодействия определяют различные протоколы. Данная концепция нам говорит, что нужно разделять машины в сети на клиентские, которым всегда что-то надо и на серверные, которые дают то, что надо. При этом взаимодействие всегда начинает клиент, а правила, по которым происходит взаимодействие описывает протокол.

Существует два вида архитектуры взаимодействия клиент-сервер: первый получил название двухзвенная архитектура клиент-серверного взаимодействия, второй – многоуровневая архитектура клиент-сервер (иногда его называют трехуровневая архитектура или трехзвенная архитектура, но это частный случай).

Принцип работы двухуровневой архитектуры взаимодействия клиент-сервер заключается в том, что обработка запроса происходит на одной машине без использования сторонних ресурсов. Двухзвенная архитектура предъявляет жесткие требования к производительности сервера, но в тоже время является очень надежной. Двухуровневую модель взаимодействия клиент-сервер вы можете увидеть на рисунке ниже.

Двухуровневая модель взаимодействия клиент-сервер

Здесь четко видно, что есть клиент (1-ый уровень), который позволяет человеку сделать запрос, и есть сервер, который обрабатывает запрос клиента.

Если говорить про многоуровневую архитектуру взаимодействия клиент-сервер, то в качестве примера можно привести любую современную СУБД (за исключением, наверное, библиотеки SQLite, которая в принципе не использует концепцию клиент-сервер). Суть многоуровневой архитектуры заключается в том, что запрос клиента обрабатывается сразу несколькими серверами. Такой подход позволяет значительно снизить нагрузку на сервер из-за того, что происходит распределение операций, но в то же самое время данный подход не такой надежный, как двухзвенная архитектура. На рисунке ниже вы можете увидеть пример многоуровневой архитектуры клиент-сервер.

Многоуровневая архитектура взаимодействия клиент-сервер

Типичный пример трехуровневой модели клиент-сервер. Если говорить в контексте систем управления базами данных, то первый уровень – это клиент, который позволяет нам писать различные SQL запросы к базе данных. Второй уровень – это движок СУБД, который интерпретирует запросы и реализует взаимодействие между клиентом и файловой системой, а третий уровень – это хранилище данных.

Если мы посмотрим на данную архитектуру с позиции сайта. То первый уровень можно считать браузером, с помощью которого посетитель заходит на сайт, второй уровень – это связка Apache + PHP, а третий уровень – это база данных. Если уж говорить совсем просто, то PHP больше ничего и не делает, кроме как, гоняет строки и базы данных на экран и обратно в базу данных.

Преимущества и недостатки архитектуры клиент-сервер

Преимуществом модели взаимодействия клиент-сервер является то, что программный код клиентского приложения и серверного разделен. Если мы говорим про локальные компьютерные сети, то к преимуществам архитектуры клиент-сервер можно отнести пониженные требования к машинам клиентов, так как большая часть вычислительных операций будет производиться на сервере, а также архитектура клиент-сервер довольно гибкая и позволяет администратору сделать локальную сеть более защищенной.

К недостаткам модели взаимодействия клиент-сервер можно отнести то, что стоимость серверного оборудования значительно выше клиентского. Сервер должен обслуживать специально обученный и подготовленный человек. Если в локальной сети ложится сервер, то и клиенты не смогут работать (в качестве частного случая можно привести пример: мощности сервера не всегда хватает, чтобы удовлетворит запросы клиентов, если вы хоть раз работали с биллинговыми системами, то понимаете о чем я: время ожидания ответа от сервера может быть очень большим).

В качестве заключения нам стоит явно акцентировать внимание на том, что архитектура клиент-сервер не делит машины на только клиент или только сервер, а скорее позволяет распределить нагрузку и разделить функционал между клиентской частью и серверной.

Многоуровневая архитектура

В последнее время многоуровневая ( multitier ) архитектура пользуется все большей популярностью, поскольку имеет массу преимуществ перед файл-серверными или клиент-серверными приложениями. Такая архитектура в различных публикациях также называется многозвенной, или распределенной архитектурой. Суть многоуровневой архитектуры в том, что помимо сервера БД и приложений-клиентов дополнительно присутствует еще один или несколько серверов приложений. Сервер приложений является промежуточным уровнем, обеспечивающим организацию взаимодействия клиентов и сервера БД . Сервер приложений также называют брокером данных ( broker — посредник). Чаще всего используют трехуровневую модель. Прежде, чем мы двинемся дальше, давайте разберемся, что же такое уровень. Имеется три основных уровня:

  • Уровень данных. Этот уровень отвечает за хранение данных. Как правило, для этого уровня выделяется отдельный ПК, на котором устанавливают один из SQL -серверов, например, InterBase . Клиентские ПК непосредственно не имеют никакой связи с этим уровнем.
  • Бизнес-уровень. Этот уровень предназначен для получения данных с уровня данных, выполнения окончательной проверки данных, и служит посредником между клиентами и данными. Как правило, сервера приложений находятся именно на этом уровне.
  • Уровень представления данных. Этот уровень известен так же, как уровень графического интерфейса пользователя. На этом уровне полученные данные отображаются в таких компонентах вывода данных, как DBGrid , DBEdit , DBMemo и проч. Разумеется, этот уровень находится на клиентских ПК.
Читать еще:  Как включить подсистему linux в windows 10

Взгляните на рисунок:

На рисунке представлены три уровня архитектуры: так называемый, «тонкий» клиент ( thin-client ), сервер приложений и сервер данных. На ПК сервера БД вместе с данными расположен один из SQL -серверов. Как видите, на клиентском ПК, помимо компонентов доступа к данным, располагается только компонент связи с сервером приложений, а довольно громоздкие механизмы доступа к данным отсутствуют. Из-за этого клиентское приложение и называется «тонким» клиентом. Такой подход не только облегчает распространение приложений, но и позволяет в качестве клиентских ПК использовать дешевые, неприхотливые компьютеры. На сервере приложений вы можете видеть область, обозначенную как » Интерфейс IAppServer «. Этот интерфейс обеспечивается специальным удаленным модулем данных, о котором дальше мы поговорим подробней. Интерфейс IAppServer используют компоненты-провайдеры TDataSetProvider на стороне сервера приложений, и компоненты TClientDataSet на стороне клиента.

При небольшом количестве клиентов ничто не мешает нам отказаться от использования SQL -сервера, расположив данные на самом сервере приложений, и используя к ним обычный локальный доступ через механизм BDE , ADO и т.п. При этом можно использовать обычные таблицы Paradox или MS Access , например. Такой подход удобней, чем файл -серверная архитектура , поскольку позволяет не только «облегчить» пользовательское приложение , но и обеспечивает безопасность данных . Ведь пользователи не будут иметь прямого доступа к самим данным, обмен информацией будет происходить через посредника, как на рисунке ниже:

Несмотря на кажущуюся сложность архитектуры, организовать такую модель достаточно просто. Delphi для этого предлагает технологию DataSnap (в старых версиях Delphi эта технология называлась MIDAS — Multi-tier Distributed Applications Services — Серверы многозвенных распределенных приложений ). Благодаря этой технологии, вы сможете создать простой сервер приложений буквально за минуту, не введя ни строчки кода.

Преимущества многоуровневых моделей

  • Централизованная бизнес-логика. Как мы уже знаем, бизнес-логикой называют некоторые правила обработки данных. Например, удаляя запись из одной таблицы, требуется удалить связанные с ней записи других таблиц. В обычных файл-серверных или клиент-серверных приложениях, часть бизнес-логики ложилась на клиентское приложение. При необходимости изменения каких-то правил, приходилось переделывать клиентское приложение, затем тратить усилия на его распространение на клиентские ПК. Теперь же эта бизнес-логика хранится на уровне сервера приложений, и при ее изменении клиенты сразу получают возможность работать по новым правилам.
  • Архитектура «тонкого» клиента.Как известно, для получения данных из БД приложения используют один из механизмов доступа к данным — BDE , ADO , ODBC , IBX , dbExpress и т.п. Все это приводит к тому, что на ПК каждого клиента приходится устанавливать и настраивать соответствующие драйверы, а это сильно усложняет процесс распространения приложения. В многозвенной архитектуре механизмы доступа к данным располагаются на сервере приложений. Только там нужно устанавливать эти драйверы (например, BDE ). Клиентские же машины не нуждаются в них, за что и называются «тонкими».
  • Модель «портфеля» (briefcase model).Модель «портфеля» подразумевает возможность отложенной обработки данных. Представьте, что вам в выходные дни требуется проделать какую-то работу с данными. При использовании файл-серверной или клиент-серверной модели, вам для этой работы придется прибыть в офис, иначе вы не сможете получить доступа к данным. В многоуровневой модели вы можете сохранить на переносном ПК все необходимые вам данные в виде локального файла. Дома вы сможете загрузить этот файл, и провести необходимую работу с данными. Затем, прибыв в офис, вы сможете перенести эти изменения в реальную базу данных.
  • Снижение трафика сети. За счет возможности отложенной обработки данных значительно снижается нагрузка на сеть.

Сервер приложений

Сервер приложений нам придется создавать самостоятельно. Давайте познакомимся с созданием такого сервера на практике, попутно разбирая новый материал. Для примера мы создадим сервер приложений, работающий с базой данных ok. mdb , которую мы создавали во второй лекции (надеюсь, вы еще не удалили эту БД ?). Поместим этот файл по адресу

Delphi поддерживает следующие технологии удаленного доступа:

  • DCOM ( Distributed Component Object Model — Распределенная компонентная модель объектов) Модель рассчитана на локальную сеть и позволяет использовать объекты, расположенные на другом ПК. Если клиентское приложение работает под управлением Windows 95 (что маловероятно в настоящее время), то придется также установить поддержку DCOM95 , остальные версии Windows в этом не нуждаются. Поскольку модель является «родной» для ОС Windows , использовать ее довольно просто. Вероятно, наиболее популярная модель на сегодняшний день.
  • Сокеты — позволяют использовать сеть по протоколу TCP/IP . Эта модель, пожалуй, дает наиболее быстрое соединение, однако имеется ряд замечаний. Во-первых, программисту приходится прилагать дополнительные усилия для организации связи и слежением за возможными ошибками. Во-вторых, чтобы можно было загрузить сервер приложений, сначала на компьютере с этим сервером нужно загрузить утилиту SCKTSRVR.EXE. Эта утилита устанавливается вместе с Delphi и по умолчанию находится в папке C:PROGRAM FILESBORLANDDELPHIBIN. При загрузке программы ее ярлык появляется в трее (в правом нижнем углу экрана), и с этого момента клиентские ПК смогут соединяться с этим сервером. Обычно запуск этой утилиты прописывают на сервере в автозагрузке.
  • MTS ( Microsoft Transaction Server — Сервер транзакций Microsoft ) — основана на DCOM и имеет некоторые дополнительные возможности.
  • CORBA ( Common Object Request Broker Architecture — Общедоступная архитектура брокеров при запросе объектов).
  • SOAP ( Simple Object Access Protocol — Простой протокол доступа к объекту.)
Читать еще:  Программный маршрутизатор на linux с веб интерфейсом

Загрузите Delphi и начните новый проект. Главная форма нам совсем не понадобится, назовите ее fMain , в свойстве Caption напишите » Сервер приложений «, уменьшите ее размер (например, Height =120, W >Main , а проекту в целом — MyNewServer . Основой сервера является удаленный модуль данных, который обеспечивает связь сервера с клиентами, а также является контейнером для размещения компонентов, вроде обычного Data Module. Delphi позволяет использовать следующие удаленные модули:

  • Remote Data Module — используется для серверов DCOM , сокетов и OLEnterprise ;
  • Transactional Data Module — используется для сервера MTS ;
  • CORBA Data Module — для сервера CORBA ;
  • SOAP Data Module — для сервера SOAP ;
  • WebSnap Data Module — использует Web -службы и Web -броузер в качестве сервера.

Помимо одного из этих удаленных модулей данных, в состав сервера приложений также входят компоненты TDataSetProv >приложение . Каждому набору данных ( таблица , запрос ), предназначенному для передачи клиентам, следует предоставить по одному компоненту TDataSetProvider.

Важно! Следует знать, что обмен данными между сервером приложений и «тонкими» клиентами обеспечивается динамической библиотекой Midas.dll, которая должна быть зарегистрирована на компьютере сервера приложений.

Мы будем использовать технологию DCOM , поэтому выберите команду меню File -> New -> Other, чтобы открыть окно депозитария Delphi . Перейдите на вкладку Multitier и выберите Remote Data Module . Откроется окно мастера создания удаленного модуля данных:

В первом поле » Co >MyRDM . Следующие два поля требуют более детального изучения.

Поле Instancing требует выбора способа создания экземпляров сервера, когда клиент пытается получить доступ к данным. Заметим, что Windows автоматически загружает сервер приложений, когда начинает работать клиент. Возможны следующие способы загрузки сервера:

  • Internal — при такой модели сервер COM не сможет создаваться из внешних приложений. Используется редко, в основном, когда нужно управлять доступом с помощью промежуточного уровня прокси.
  • Single Instance — при выборе этой модели для каждого клиентского соединения будет создан свой экземпляр сервера.
  • Multiple Instance — в этой модели все клиентские соединения используют единый экземпляр сервера.

В этом поле оставляем способ по умолчанию Multiple Instance.

Поле Threading Model предлагает выбрать модель потоков, что позволяет распределять соединения по отдельным потокам без необходимости применения дополнительного кода. Допустимы следующие модели:

  • Single (Одиночная) — для клиентов выделяется один поток, все клиенты работают последовательно. Выбор такой модели может оказаться неудачным в многопользовательской среде, и используется редко.
  • Apartment (Раздельная) — для каждого клиента создается собственный поток. В сочетании с Multiple Instance этот способ дает самые высокие результаты и наиболее часто применяется.
  • Free (Свободная) — один экземпляр модуля данных может одновременно отвечать на несколько запросов клиентов, используя разные потоки.
  • Both (Оба) — объединяет модели Free и Apartment .
  • Neutral (Нейтральный) — разные клиенты могут одновременно вызвать удаленный модуль данных из нескольких потоков, при этом модель COM следит, чтобы не было конфликта вызовов. Однако может возникнуть конфликт потоков, который отслеживается только в версии COM+ . При отсутствии этой версии нужно использовать модель Apartment .

В этом поле оставляем модель по умолчанию Apartment.

Тест по теме «Архитектуры удаленных баз данных»

Как организовать дистанционное обучение во время карантина?

Помогает проект «Инфоурок»

Архитектуры удаленных баз данных

Отметьте правильный ответ

Локальная (персональная) архитектура базы данных означает, что БД и СУБД располагаются на

одном и том же локальном компьютере

БД на локальном компьютере, а СУБД — на сервере

СУБД на локальном компьютере, а БД — на сервере

разных локальных компьютерах

Многозвенная архитектура «клиент-сервер» предполагает разбиение приложения-клиента на два звена: » тонкий » клиент, располагающийся на компьютере пользователя, и сервер приложений, находящийся на удаленном сервере

Отметьте правильный ответ

База данных — это:

любой текстовый файл

организованный набор данных

любая информация, представленная в табличной форме

любая электронная таблица

Отметьте правильный ответ

Сервер баз данных — это

компьютер, хранящий все данные базы данных

программное обеспечение, осуществляющее работу с данными

программное обеспечение для подключения клиентского компьютера в сеть

При использовании файл-серверной архитектуры клиентское приложение взаимодействует с промежуточной программой — сервером приложения.

В файл-серверной архитектуре на сервере располагаются

 файлы базы данных

В файл-серверной архитектуре на клиенте располагаются

 файлы базы данных

В двухуровневой архитектуре на клиенте располагаются

 файлы базы данных

В двухуровневой архитектуре на сервере располагаются

В многоуровневой архитектуре на сервере приложений располагаются

В многоуровневой архитектуре на клиенте располагается

В многоуровневой архитектуре имеются

 сервер базы данных

В многоуровневой архитектуре сервер приложений

 реализует функции бизнес-логики

 обеспечивает работу СУБД

 хранит файлы базы данных

 предоставляет пользовательский интерфейс

Бесплатный
Дистанционный конкурс «Стоп коронавирус»

  • Никитина Светлана БорисовнаНаписать 1799 06.06.2016

Номер материала: ДБ-111492

Добавляйте авторские материалы и получите призы от Инфоурок

Еженедельный призовой фонд 100 000 Р

    06.06.2016 7269
    06.06.2016 1850
    06.06.2016 305
    06.06.2016 306
    06.06.2016 992
    06.06.2016 550
    06.06.2016 533

Не нашли то что искали?

Вам будут интересны эти курсы:

Все материалы, размещенные на сайте, созданы авторами сайта либо размещены пользователями сайта и представлены на сайте исключительно для ознакомления. Авторские права на материалы принадлежат их законным авторам. Частичное или полное копирование материалов сайта без письменного разрешения администрации сайта запрещено! Мнение редакции может не совпадать с точкой зрения авторов.

Ответственность за разрешение любых спорных моментов, касающихся самих материалов и их содержания, берут на себя пользователи, разместившие материал на сайте. Однако редакция сайта готова оказать всяческую поддержку в решении любых вопросов связанных с работой и содержанием сайта. Если Вы заметили, что на данном сайте незаконно используются материалы, сообщите об этом администрации сайта через форму обратной связи.

Ссылка на основную публикацию
Adblock
detector