Управление sql. Управление безопасностью SQL сервера средствами Microsoft Access (документация). Соберем все вместе

Управление sql. Управление безопасностью SQL сервера средствами Microsoft Access (документация). Соберем все вместе

29.03.2019
Браузеры
Главная > Документ

Многоуровневый "клиент-сервер"

Многоуровневая архитектура клиент-сервер (Multitier architecture) – разновидность архитектуры клиент-сервер, в которой функция обработки данных вынесена на один или несколько отдельных серверов . Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов. Среди многоуровневой архитектуры клиент-сервер наиболее распространена трехуровневая архитектура (трехзвенная архитектура, three-tier), предполагающая наличие следующих компонентов приложения: клиентское приложение (обычно говорят "тонкий клиент" или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных. Терминал – это интерфейсный (обычно графический) компонент, который представляет первый уровень, собственно приложение для конечного пользователя. На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость Сервер приложений располагается на втором уровне. На втором уровне сосредоточена большая часть бизнес-логики. Вне его остаются фрагменты, экспортируемые на терминалы, а также погруженные в третий уровень хранимые процедуры и триггеры. Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных. В простейшей конфигурации физически сервер приложений может быть совмещен с сервером базы данных на одном компьютере, к которому по сети подключается один или несколько терминалов. В "правильной" (с точки зрения безопасности, надежности, масштабирования) конфигурации сервер базы данных находится на выделенном компьютере (или кластере), к которому по сети подключены один или несколько серверов приложений, к которым, в свою очередь, по сети подключаются терминалы. Плюсами данной архитектуры являются:
    клиентское ПО не нуждается в администрировании; масштабируемость; конфигурируемость – изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней; высокая безопасность; высокая надежность; низкие требования к скорости канала (сети) между терминалами и сервером приложений; низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости.
Минусы:
    растет сложность серверной части и, как следствие, затраты на администрирование и обслуживание; более высокая сложность создания приложений; сложнее в разворачивании и администрировании; высокие требования к производительности серверов приложений и сервера базы данных, а, значит, и высокая стоимость серверного оборудования; высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений.

26. Оптимізація роботи з базою даних в режимі мережі.

Особенности управления одновременным доступом Управление одновременным доступом - это то, чем отличаются различные СУБД. Именно это отличает СУБД от файловой системы и одну СУБД от другой. Для программиста важно, чтобы его приложение базы данных корректно работало в условиях одновременного доступа, и именно это постоянно забывают проверять. Приемы, прекрасно работающие в условиях последовательного доступа, работают гораздо хуже при одновременном их применении несколькими сеансами. Если не знать досконально, как в конкретной СУБД реализованы механизмы управления одновременным доступом, то: будет нарушена целостность данных; приложение будет работать медленнее, чем предусмотрено, даже при небольшом количестве пользователей; будет потеряна возможность масштабирования до большого числа пользователей. Проблемы одновременного доступа выявлять сложнее всего - трудности сопоставимы с отладкой многопотоковой программы. Программа может отлично работать в уп- равляемой, искусственной среде отладчика, но постоянно "слетать" в "реальном мире". Например, в условиях интенсивных обращений может оказаться, что два потока одно- временно изменяют одну и ту же структуру данных. Такого рода ошибки очень сложно выявлять и исправлять. Реализация блокирования СУБД использует блокировки, чтобы в каждый момент времени те или иные дан- ные могли изменяться только одной транзакцией. Говоря проще, блокировки - это механизм обеспечения одновременного доступа. При отсутствии определенной модели бло- кирования, предотвращающей одновременное изменени. Принципы блокирования в СУБД Oracle. Oracle блокирует данные на уровне строк и только при изменении. Эскалация блокировок до уровня блока или таблицы никогда не выполняется. Oracle никогда не блокирует данные с целью считывания. При обычном чтении блокировки на строки не устанавливаются. Сеанс, записывающий данные, не блокирует сеансы, читающие данные. Повторю: операции чтения не блокируются операциями записи. Это принципиально отличается от практически всех остальных СУБД, в которых операции чтения бло кируются операциями записи. Сеанс записи данных блокируется, только если другой сеанс записи уже забло- кировал строку, которую предполагается изменять. Сеанс считывания данных ни- когда не блокирует сеанс записи. Блокируя ресурс, который мы пытаемся зарезервировать, мы гарантируем, что никакой другой сеанс в это же время не изменяет план использования ресурса. Ему придется ждать, пока наша транзакция не будет зафиксирована - после этого он сможет увидеть сделанное в ней резервирование. Возможность перекрытия планов, таким образом, устранена. Разработчик должен понимать, что в многопользовательской среде иногда необходимо использовать те же приемы, что и при многопотоковом программировании. В данном случае конструкция FOR UPDATE работает как семафор. Она обеспечивает последовательный доступ к конкретной строке в таблице ресурсов, гарантируя, что два сеанса одновременно не резервируют ресурс. Этот подход обеспечивает высокую степень параллелизма, поскольку резервируемых ресурсов могут быть тысячи, а мы всего лишь гарантируем, что сеансы изменяют конкретный ресурс поочередно. Это один из немногих случаев, когда необходимо блокирование вручную данных, которые не должны изменяться. Требуется уметь распознавать ситуации, когда это необходимо, и, что не менее важно, когда этого делать не нужно (пример, когда не нужно, приведен далее). Кроме того, такой прием не блокирует чтение ресурса другими сеансами, как это могло бы произойти в других СУБД, благодаря чему обеспечивается высокая масштабируемость. Многовариантность - это механизм, с помощью которого СУБД Oracle обеспечивает: согласованность по чтению для запросов: запросы выдают согласованные резуль таты на момент начала их выполнения; неблокируемые запросы: запросы не блокируются сеансами, в которых изменя ются данные, как это бывает в других СУБД. Это две очень важные концепции СУБД Oracle. Термин многовариантность произошел от того, что фактически СУБД Oracle может одновременно поддерживать множе ство версий данных в базе данных. Понимая сущность многовариантности, всегда можно понять результаты, получаемые из базы данных. Например мы создали тестовую таблицу Т и заполнили ее данными. Мы открыли курсор для этой таблицы. Мы не выбирали данные с помощью этого курсора, просто открыли его. Помните, что при открытии курсора сервер Oracle не "отвечает " на запрос; он никуда не копирует данные при открытии курсора (представьте, сколько времени потре бовало бы открытие курсора для таблицы с миллиардом строк в противном случае). Курсор просто открывается и дает результаты запроса по ходу обращения к данным. Другими словами, он будет читать данные из таблицы при извлечении их через курсор. В том же (или в другом) сеансе мы затем удаляем все данные из таблицы. Более того, мы даже фиксируем (COMMIT) это удаление. Строк больше нет - не так ли? На самом деле их можно извлечь с помощью курсора Фактически, результирующее множе- ство, возвращаемое командой OPEN, было предопределено в момент открытия курсора. Мы не прочитали при открытии курсора ни одного блока данных таблицы, но результат оказался жестко зафиксированным. Мы не сможем узнать этот результат, пока не извлечем данные, но с точки зрения нашего курсора результат этотнеизменен. Дело не в том, что СУБД Oracle скопировала все эти данные в другое место при открытии курсора; данные сохранил оператор delete, поместив их в область данных под названием сегмент отката. Именно в этом и состоит согласованность по чтению, и если не понимать, как работает схема многовариантности в Oracle и каковы ее последствия, вы не только не сможете воспользоваться всеми преимуществами СУБД Oracle, но и не создадите корректных приложений для Oracle, гарантирующих целостность данных. Поэтому если вы привыкли к реализации согласованности и одновременности запросов в других СУБД или просто никогда не сталкивались с такими понятиями (не имеете реального опыта работы с СУБД), то теперь понимаете, насколько важно для вашей работы их понимание. Чтобы максимально использовать потенциальные возможности СУБД Oracle, необходимо понимать эти проблемы и способы их решения именно в Oracle, а не в других СУБД.

30. Сервер додатка. Структура сервера додатка. Реєстрація сервера додатка

Сервер приложений инкапсулирует большую часть бизнес-логики распределенного приложения и обеспеч. доступ клиентов к базе данных. Основной частью сервера приложений является удаленный модуль данных. Во-первых, подобно обычному модулю данных он является платформой для размещения невизуальных компонентов доступа к данным и компонентов-провайдеров. Размещенные на нем компоненты соединений, транзакций и компоненты, инкапсулирующие наборы данных, обеспечивают трехзвенное приложение связью с сервером БД. Это могут быть наборы компонентов для технологий ADO, BDE, InterBase Express, dbExpress. Во вторых, удаленный модуль данных реализует основные ф-и сервера приложений на основе предоставления клиентам интерфейса AppServer или его потомка. Для этого удаленный модуль данных должен содержать необход. число компонентов-провайдеров TDataSetProvider. Эти компоненты передают пакеты данных клиентскому приложению, а точнее компонентам TdientDataSet, а также обеспечивают доступ к методам интерфейса.
В состав Delphi входят удаленные модули данных. Для их создания используйте страницы Multitier, WebSnap и WebServices Репозитория Delphi .
Remote Data Module - удаленный модуль данных, инкапсулирующий сервер Автоматизации. Используется для организации соединений через DCOM, HTTP, сокеты (см. гл. 21).
Transactioiial Data Module - удаленный модуль данных, инкапсулирующий сервер MTS (Microsoft Transaction Server).
SOAP Server Data Module - удаленный модуль данных, инкапсулирующий сервер SOAP (Simple Object Access Protocol).
WebSnap Data Module - удаленный модуль данных, использующий Web-службы и Web-браузер в качестве сервера.
С каждым компонентом, инкапсулирующим набор данных, предназначенным для передачи клиенту, в модуле данных должен быть связан компонент-провайдер.

34. Відмінності SQL від мов високого рівня. Категорії операторів SQL.

SQL, не является процедурным языком, да и, по большому счету, он вообще не относится к языкам программирования.PL/SQL - это процедурный язык пошагового программирования, инкапсулирующий язык SQL. В результате получается хорошо развитый язык программирования третьего поколения (3GL), подобный языку C++, Pascal и т. д. В своей сути PL/SQL блочно ориентирован.PL/SQL имеет строгие правила области видимости переменных, поддерживает параметризованные вызовы процедур и функций и так же унаследовал от языка ADA такое средство, как пакеты (package).PL/SQL предусматривает строгий контроль типов, все ошибки несовместимости типов выявляются на этапе компиляции и выполнения. Так же поддерживается явное и неявное преобразование типов.PL/SQL - поддерживает сложные структуры данных, так же предусмотрена перегрузка подпрограмм, для создания гибкой среды прикладного программирования.Язык PL/SQL - имеет элемент Exception Handler (обработчик исключительных ситуаций) для синхронной обработки ошибок на этапе выполнения кода PL/SQL.Так же строго говоря, язык PL/SQL не является объектно-ориент., хотя имеет некоторые средства для создания и работы с объектами БД на уровне объектно-ориентированных языков программирования.PL/SQL - является машинно независимым языком программирования. Оператор - это символ, указывающий на действие, которое выполняется над одним или несколькими выражениями. Категории операторов, используемые SQL Server: Арифметические операторы,Логические операторы,Оператор присваивания,Оператор разрешения области, Битовые операторы, Операторы наборов, Операторы сравнения, Оператор объединения строк, Составные операторы, Унарные операторы

36) Логические операторы SQL. Эффективное построение запросов

Логические операторы AND, OR и NOT. Операторы AND и OR используются для объединения условий поиска в предложениях WHERE. Оператор NOT обращает значение условия поиска. Оператор AND соединяет два условия и возвращает TRUE, только если оба условия выполняются. Например, этот запрос возвратит только одну строку, в которой идентификатор клиента (BusinessEntityID) начинается с числа 1, а название магазина начинается с «Bicycle»:SELECT BusinessEntityID, NameFROM AdventureWorks2008R2.Sales.StoreWHERE BusinessEntityID LIKE "1%" AND Name LIKE N"Bicycle%";Оператор OR также соединяет два условия, но возвращает TRUE, если выполняется хотя бы одно из условий. Следующий запрос возвращает 349 строк, в которых либо идентификатор заказчика начинается с 1, либо название магазина начинается с «Bicycle»: SELECT BusinessEntityID, NameFROM AdventureWorks2008R2.Sales.StoreWHERE BusinessEntityID LIKE "1%" OR Name LIKE N"Bicycle%"; Оптимизация: Оптимизация SQL-запросовВсе больше приложений используют базы данных. Все больше данных приходится хранить и обрабатывать. Если приложение медлительное, программисты, пользователи и администраторы в первую очередь ссылаются на низкую производительность сети, плохие аппаратные средства сервера и друг на друга:). И забывают про оптимизацию.И такое будет продолжаться до тех пор, пока приложение не будет подвергнуто жестокому анализу на предмет повышения производительности. Один из способов повысить скорость работы приложения - оптимизация SQL-запросов. Этот способ хорош тем, что не надо лезть в дебри оптимизации SQL-сервера. Проще не допускать появления неэффективных SQL-запросов. Но если такое уже случилось, ищи выходы из сложившихся неприятных ситуаций. Общая оптимизацияКаждая SQL-операция имеет так называемый "коэффициент полезности" – уровень эффективности данной операции. Чем больше балл, тем "полезней" операция, а значит, SQL-запрос выполняется быстрее.Практически любое условие состоит из двух операндов и знака операции между ними. ПримерыЧтобы лучше понять таблицы, рассмотрим пример расчета рейтинга запроса.… WHERE smallint_column = 123455 баллов за поле слева (smallint_column), 2 балла за точный цифровой операнд(smallint_column), 10 баллов за операцию сравнения (=) и 10 баллов за значение справа (12345). Итого получили 27 баллов. Теперь рассмотрим более сложный пример:... WHERE char_column >= varchar_column || "x"5 баллов за поле слева (char_column), 0 баллов за символьный операнд (char_column), 5 баллов за операцию больше или равно (>=), 3 балла за логическое выражение (varchar_column || "x"), 0 баллов за символьный операнд (varchar_column). В итоге получим 13 баллов.Естественно, такие расчеты не обязательно проводить для каждого запроса. Но когда встанет вопрос о скорости условий того или иного запроса, его можно будет выяснить с помощью этих двух таблиц. На скорость запроса также влияет количество выбираемых данных и дополнительные директивы, которые рассмотрим ниже. Также имей в виду, что расчет "коэффициента полезности" не является неким универсальным способом оптимизации. Все зависит от конкретной ситуации.Основной закон при оптимизации запросов - закон преобразования. Неважно, как мы представляем условие, главное чтобы результат остался прежним. И снова рассмотрим пример. Есть запрос: ... WHERE column1 < column2 AND column2 = column3 AND column1 = 5. Используя перестановку, получаешь запрос: …WHERE 5 < column2 AND column2 = column3 AND column1 = 5. Результат запроса будет один и тот же, а продуктивность разной, потому что использование точного значения (5) влияет на производительность.Если ты изучал С или С++, то знаешь, что выражение x=1+1-1-1 во время компиляции станет x=0. Удивительно, что лишь некоторые БД способны выполнять такие операции. При выполнении запроса БД будет выполнять операции сложения и вычитания и тратить твое драгоценное время. Поэтому всегда лучше сразу рассчитывать такие выражения там, где это возможно. Не … WHERE a - 3 = 5, а … WHERE a = 8.Еще одна возможность оптимизировать запрос - придерживаться общей идеи составления условий в SQL. Другими словами, условие должно иметь вид: <колонка> <операция> <выражение>. Например, запрос "... WHERE column1 - 3 = -column2" лучше привести к виду: ... WHERE column1 = -column2 + 3.И эти приемы оптимизации работают практически всегда и везде. Оптимизируем условияТеперь настало время произвести оптимизацию самих условных операторов SQL. Большинство запросов используют директиву SQL WHERE, поэтому, оптимизируя условия, можно добиться значительной производительности запросов. При этом почему-то лишь небольшая часть приложений для БД используют оптимизацию условий. ANDОчевидно, что в серии из нескольких операторов AND условия должны располагаться в порядке возрастания вероятности истинности данного условия. Это делается для того, чтобы при проверке условий БД не проверяла остальную часть условия. Эти рекомендации не относится к БД Oracle, где условия начинают проверяться с конца. Соответственно, их порядок должен быть обратным – по убыванию вероятности истинности. ORСитуация с данным оператором прямо противоположна ситуации с AND. Условия должны располагаться в порядке убывания вероятности истинности. Фирма Microsoft настойчиво рекомендует использовать данный метод при построении запросов, хотя многие даже не знают об этом или, по крайней мере, не обращают на него внимание. Но опять-таки это не относится к БД Oracle, где условия должны располагаться по возрастанию вероятности истинности.Еще одним условием для оптимизации можно считать тот факт, что если одинаковые колонки располагаются рядом, запрос выполняется быстрее. Например, запрос ".. WHERE column1 = 1 OR column2 = 3 OR column1 = 2" будет выполняться медленней, чем запрос "WHERE column1 = 1 OR column1 = 2 OR column2 = 3". Даже если вероятность истинности условия column2 = 3 выше, чем column1 = 2. AND + ORЕще в школе мне рассказывали про распределительный закон. Он гласит, что A AND (B OR C) - то же самое, что и (A AND B) OR (A AND C). Опытным путем было установлено, что запрос вида "...WHERE column1 = 1 AND (column2 = "A" OR column2 = "B")" выполняется несколько быстрее, чем "...WHERE (column1 = 1 AND column2 = "A") OR (column1 = 1 AND column2 = "B")". Некоторые БД сами умеют оптимизировать запросы такого типа, но лучше перестраховаться. NOTЭту операцию всегда следует приводить к более "читабельному" виду (в разумных пределах, конечно). Так, запрос "...WHERE NOT (column1 > 5)" преобразуется в "...WHERE column1 <= 5". Более сложные условия можно преобразовать используя правило де Моргана, которое ты тоже должен был изучить в школе. Согласно этому правилу NOT(A AND B) = (NOT A) OR (NOT B) и NOT(A OR B) = (NOT A) AND (NOT B). Например, условие "...WHERE NOT (column1 > 5 OR column2 = 7)" преобразуется в более простую форму: ...WHERE column1 <= 5 AND column2 <> 7. INМногие наивно полагают, что запрос "... WHERE column1 = 5 OR column1 = 6" равносилен запросу "...WHERE column1 IN (5, 6)". На самом деле это не так. Операция IN работает гораздо быстрее, чем серия OR. Поэтому всегда следует заменять OR на IN, где это возможно, несмотря на то, что некоторые БД сами производят эту оптимизацию. Там, где используется серия последовательных чисел, IN следует поменять на BETWEEN. Например, "...WHERE column1 IN (1, 3, 4, 5)" оптимизируется к виду: …WHERE column1 BETWEEN 1 AND 5 AND column1 <> 2. И этот запрос действительно быстрее. LIKEЭту операцию следует использовать только при крайней необходимости, потому что лучше и быстрее использовать поиск, основанный на full-text индексах. К сожалению, я вынужден направить тебя за информацией о поиске на просторы всемирной паутины. CASEСама эта функция может использоваться для повышения скорости работы запроса, когда в нем есть более одного вызова медленной функции в условии. Например, чтобы избежать повторного вызова slow_function() в запросе "...WHERE slow_function(column1) = 3 OR slow_function(column1) = 5", нужно использовать CASE:... WHERE 1 = CASE slow_function(column1)WHEN 3 THEN 1WHEN 5 THEN 1END СортировкаORDER BY используется для сортировки, которая, как известно, занимает время. Чем больше объем данных, тем больше времени займет сортировка, поэтому нужно обязательно ее оптимизировать. На скорость сортировки в запросах влияет три фактора:
    количество выбранных записей; количество колонок после оператора ORDER BY; длина и тип колонок, указанных после оператора ORDER BY.
Самой ресурсоемкой сортировкой является сортировка строк. Несмотря на то, что текстовые поля имеют фиксированную длину, длина содержимого этих полей может быть различной (в пределах размера поля). Поэтому неудивительно, что сортировка колонки VARCHAR(100) будет медленней, чем сортировка колонки VARCHAR(10) (даже если данные будут одинаковые). А происходит это из-за того, что при сортировке сама база данных выделяет память для своих операций в соответствии с максимальным размером поля независимо от содержимого. Поэтому при объявлении полей всегда следует использовать размер, который нужен, и не выделять лишние байты про запас.На компьютерах с ОС Windows поля типа INTEGER занимают 32 бита, а поля типа SMALLINT – 16 бит. Логично предположить, что сортировка полей типа SMALLINT должна происходить быстрее. На самом деле сортировка INTEGER происходит быстрее, чем SMALLINT. Также сортировка INTEGER происходит быстрее, чем CHAR.Сортировка символов также имеет свои нюансы, описание которых займет не одну статью. Она может быть быстрой и неправильной или медленной, но с меньшим количеством ошибок. Оптимизации сортировки производится для конкретной ситуации, так что универсальных рекомендаций никто дать не может. ГруппированиеОперация GROUP BY используется для определения подмножества в результате запроса, а также для применения к этому подмножеству агрегатных функций. Рассмотрим несколько наиболее эффективных методов оптимизации операции группирования.Первое, что следует помнить, - нужно использовать как можно меньше колонок для группировки. Также следует избегать лишних условий. Например, в запросе SELECT secondary_key_column, primary_key_column, COUNT(*) FROM Table1 GROUP BY secondary_key_column, primary_key_column колонка secondary_key_column совершенно не нужна. Причина простая: secondary_key_column является уникальным полем, оно может не иметь значений NULL, а значит, некоторые данные могут просто потеряться. Но если убрать secondary_key_column из секции GROUP BY, некоторые БД могут выдать ошибку о том, что невозможно указывать это поле, если оно не объявлено в секции GROUP BY. Для решения этой проблемы можно написать запрос в таком виде: SELECT MIN(secondary_key_column), primary_key_column, COUNT(*) FROM Table1 GROUP BY primary_key_column. Этот запрос быстрее и "правильнее" с точки зрения конструирования запросов.В большинстве БД операции WHERE и HAVING не равноценны и выполняются не одинаково. Это значит, что следующие два запроса логически одинаковы, но выполняются с разной скоростью:SELECT column1 FROM Table1 WHERE column2 = 5 GROUP BY column1 HAVING column1 > 6SELECT column1 FROM Table1 WHERE column2 = 5 AND column1 > 6 GROUP BY column1Второй запрос работает быстрее, чем первый. HAVING следует использовать в тех редких случаях, когда условие (в примере column1 > 6) сложно выразить без ущерба производительности.Если требуется группирование, но без использования агрегатных функций (COUNT(), MIN(), MAX и т.д.), разумно использовать DISTINCT. Так, вместо SELECT column1 FROM Table1 GROUP BY column1 лучше использовать SELECT DISTINCT column1 FROM Table1.При использовании MIN() и MAX() учитываем, что эти функции лучше работают по отдельности. Это значит, что их лучше использовать в раздельных запросах или в запросах с использованием UNION.При использовании функции SUM() большей производительности можно добиться используя SUM(x + y), а не SUM(x) + SUM(y). Для вычитания лучше противоположное: SUM(x) – SUM(y) быстрее, чем SUM(x – y). Соединения таблиц (JOINS)Вот где сложно что-то сказать про оптимизацию, так это при использовании JOIN . Дело в том, что скорость выполнения таких операций во многом зависит от организации самой таблицы: использование foreign-key, primary-key, количество вложенных соединений и т.д. Иногда лучшей производительности можно добиться используя вложенные циклы непосредственно в программе. Иногда быстрее работают JOINs. Однозначного совета по тому, как использовать разные способы соединения таблиц, не существует. Все зависит от конкретного случая и архитектуры БД. Подзапросы (SUBQUERIES)Раньше далеко не все БД могли похвастаться поддержкой подзапросов, а сейчас практически любая современная БД это умеет. Даже MySQL, которая несколько лет воплощала подзапросы в жизнь, наконец разжилась их поддержкой. Основная проблема при оптимизации подзапросов - не оптимизация непосредственно самого кода запроса, а выбор правильного способа для реализации запроса. Задачи, для которых используются подзапросы, также могут решаться с помощью вложенных циклов или JOIN’ов. Когда используешь JOIN, даешь возможность БД выбрать механизм, которым будет производиться соединение таблиц. Если же используешь подзапросы, то явно указываешь на использование вложенных циклов. Что выбрать?Ниже аргументы в пользу того или иного способа. Выбирай сам в зависимости от ситуации. Достоинства JOIN:
    Если запрос содержит условие WHERE, встроенный оптимизатор БД будет оптимизировать запрос в целом, в то время как в случае использования подзапросов запросы будут оптимизироваться отдельно. Некоторые БД более эффективно работают с JOINs, нежели с подзапросами (например, Oracle). После JOIN’а информация окажется в общем "списке", что нельзя сказать про подзапросы.
Достоинства SUBQUERIES:
    Подзапросы допускают более свободные условия. Подзапросы могут содержать GROUP BY, HAVING, что намного сложнее реализовать в JOIN’ах. Подзапросы могут использоваться при UPDATE, что невозможно при использовании JOIN’ов. В последнее время оптимизация подзапросов самими БД (их встроенным оптимизатором) заметно улучшилась.
Основное преимущество JOIN’ов в том, что не надо указывать БД то, каким именно способом производить операцию. А основное преимущество подзапросов в том, что цикл подзапроса может иметь несколько итераций (повторений), что, в свою очередь, может существенно увеличить производительность. ЗаключениеВ этой статье показаны самые распространенные способы увеличения производительности SQL-запросов. Тем не менее, чтобы оптимизировать запросы, есть еще очень много разных уловок и трюков. Оптимизация запросов больше похожа на искусство, чем на науку. У каждой базы данных свои встроенные оптимизаторы, которые могут помочь в этом нелегком деле, но всю работу за тебя никто не сделает. Как говорил старенький преподаватель по физике: "Чтобы решать задачи, их нужно решать".Не рекомендуется использовать ORDER BY в связке с такими операциями, как DISTINCT или GROUP BY, потому что данные операторы могут создавать побочные эффекты для сортировки. Как следствие, ты можешь получить неправильно отсортированный набор данных, который может оказаться критическим в некоторых ситуациях. Такое следствие не относится к оптимизации, но забывать о нем не стоит.Прежде чем повышать производительность сети и наращивать аппаратные средства сервера, попробуй сделать оптимизацию. У любой SQL-операции есть "коэффициент полезности". Чем выше коэффициент, тем "полезней" операция: запрос выполняется быстрее. В отличие от компиляторов, не все БД умеют упрощать выражения типа x=1+1-1-1 до x=0. Следовательно, они тратят драгоценное время на выполнение пустых операций. Оптимизируй их заранее. При использовании функции SUM() можно добиться большей производительности с помощью SUM(x + y), а не SUM(x) + SUM(y). Но если функции SUM() требуются для вычитания, используй противоположное: SUM(x) – SUM(y). SUM(x – y) работает медленнее. У каждой БД есть свои встроенные оптимизаторы, но они далеки от совершенства. Поэтому оптимизируй заранее.

38. Фізична організація бази даних в InterBase.

База данных InterBase состоит из последовательно, начиная с 0, пронумерован-ных страниц. Нулевая страница является служебной и содержит информацию, не¬обходимую для соединения с БД. Размер страницы - 1 (по умолчанию), 2, 4 или8 Кбайт. Размер страницы задается при создании БД, но может быть изменен при сохранении и восстановлении базы. Одна страница читается сервером за один логический доступ к БД.Объем буфера ввода-вывода для операций чтения-записи определяется в коли¬честве страниц (по умолчанию - 75). Если БД будет чаще читаться, объем бу¬фера следует увеличить. Если в нее будет чаще осуществляться запись, размер буфера можно уменьшить.В InterBase для записей поддерживается режим множества версий. При измене¬нии записи какой-либо транзакцией создается новая версия записи, куда помимо данных записывается номер транзакции и указатель на предыдущую версию за¬писи. Старая версия помечается как измененная; ее указатель на следующую вер¬сию записи содержит ссылку на вновь созданную версию. Каждая стартующая транзакция работает с последней версией записи, изменения для которой подтвер¬ждены. Таким образом, параллельно работающие с БД транзакции всегда исполь¬зуют разные версии записей, что позволяет снимать блокировки для клиентских приложений, одновременно работающих с одними и теми же данными в БД. При удалении записи она также физически не удаляется с диска, а помечается как уда¬ленная до тех пор, пока не завершатся все активные транзакции, использующие эту запись.InterBase размещает на одной своей странице все версии одной записи ТБД. Пос¬ле удаления записей на странице образуются «дырки». При добавлении новой записи анализируется размер максимальной «дырки», и, если он меньше длины добавляемой записи, происходит сжатие страницы, в процессе которой «дырки» объединяются. Если освободившегося пространства не хватает для размещения новой записи, та записывается с новой страницы. Загрузка страницы считается нормальной в случае, если «дырки» занимают не более 20 % объема страницы.Выделение страниц никак не оптимизировано. На отдельной служебной страни¬це БД хранятся номера всех свободных страниц. При выделении страниц не пред¬принимается никаких действий по выделению последовательно расположенных страниц для хранения записей одной таблицы БД, а выделяется первая страница в списке свободных. Если свободной страницы нет, добавляется новая в конец БД. Только в этом случае размер БД возрастает.Структура записей, поддерживающая режим множества версий, и неоптимальное выделение страниц ведут к высокой фрагментации БД и как следствие - к замед¬лению работы с ней. Поэтому необходимо периодически производить дефрагмен-тацию БД. Дефрагментированная БД характеризуется расположением записей таблиц БД на последовательно расположенных страницах и отсутствием «мусо¬ра». Под мусором понимаются версии записей, с которыми не работает никакая активная транзакция.Для удаления мусора БД сохраняется на дисковом носителе и затем восстанавли¬вается из сделанной резервной копии с помощью утилиты IBConsole (для преды¬дущих версий InterBase - с помощью утилиты InterBase Server Manager). Этот процесс гарантирует удаление всего мусора, так как в момент сохранения истановления БД не должно быть активных подключений к БД со стороны дру¬гих пользователей и потому не может быть активных транзакций. Кроме того, в InterBase предусмотрено автоматическое удаление мусора на фоне активных транзакций. Интервал, через который происходит автоматическое удаление му¬сора, по умолчанию составляет 20 000 транзакций. Это значение может быть из¬менено с помощью утилиты IBConsole (InterBase Server Manager). При автома¬тической очистке удаляются только те версии записей, для которых нет активных транзакций. В результате могут быть удалены не все старые версии.

Основи SQL

1. Створення бази даних (Create Database).

В различных СУБД процедура создания баз данных обычно закрепляется только за администратором баз данных. В однопользовательских системах принимаемая по умолчанию база данных может быть сформирована непосредственно в процессе установки и настройки самой СУБД. Стандарт SQL не определяет, как должны создаваться базы данных, поэтому в каждом из диалектов языка SQL обычно используется свой подход. Процесс создания базы данных в системе SQL-сервера состоит из двух этапов: сначала организуется сама база данных , а затем принадлежащий ей журнал транзакций . Информация размещается в соотв. файлах, имеющих расширения *.mdf (для базы данных ) и *.ldf. (для журнала транзакций ). В файле базы данных записываются сведения об основных объектах (таблицах , индексах , просмотрах и т.д.), а в файле журнала транзакций – о процессе работы с транзакциями (контроль целостности данных, состояния базы данных до и после выполнения транзакций). Создание базы данных в системе SQL-сервер осуществляется командой CREATE DATABASE. (процедура создания базы данных в SQL-сервере требует наличия прав администратора сервера.)<определение_базы_данных> ::= CREATE DATABASE имя_базы_данных [ <определение_файла> [,...n] ] [,<определение_группы> [,...n] ] ] [ LOG ON {<определение_файла>[,...n] } ] [ FOR LOAD | FOR ATTACH ] Параметр ON определяет список файлов на диске для размещения информации, хранящейся в базе данных . Параметр PRIMARY определяет первичный файл . Если он опущен, то первичным является первый файл в списке. Параметр LOG ON определяет список файлов на диске для размещения журнала транзакций . Имя файла для журнала транзакций генерируется на основе имени базы данных , и в конце к нему добавляются символы _log.

Основи SQL.

3. Створення доменів (Create Domain). Створення таблиць (Create Table)

CREATE TABLE table ( [, | ...]);где table - имя создаваемой таблицы, - описание поля, - описание ограничений и/или ключей (квадратные скобки означают необязательность, вертикальная черта | означает "или").Описание поля состоит из наименования поля и типа поля = col {datatype | COMPUTED BY () | domain} [] Здесь col - имя поля;datatype - любой правильный тип SQL-сервера, символьные типы могут иметь CHARACTER SET - набор символов, определяющий язык страны. Для русского языка следует задать набор символов WIN1251;COMPUTED BY () - определение вычисляемого на уровне сервера поля, где - правильное SQL-выражение, возвращающее единственное значение;domain - имя домена (обобщенного типа), определенного в базе данных;DEFAULT - конструкция, определяющая значение поля по умолчанию;NOT NULL - конструкция, указывающая на то, что поле не может быть пустым;COLLATE - предложение, определяющее порядок сортировки для выбранного набора символов.ПримерCREATE TABLE lsn_team (id lsn_dintkey, name lsn_dname UNIQUE, founded lsn_dfounded, PRIMARY KEY(id))Создание доменаИзучая предметную область разработчик базы данных часто сталкивается с тем, что встроенный тип слишком "широк" для хранения атрибута рассматриваемой сущности. Например, нужно вводить возраст, а типы данных INTEGER и SMALLINT предоставляют слишком широкие диапазоныю Сервер предоставляет нам возможность создать свой тип данных, наложив на него необходимые ограничения. Тип данных в SQL называется доменом и для его создания служит команда CREATE DOMAIN : CREATE DOMAIN dage AS INTEGER DEFAULT 0 CHECK(VALUE >= 0 AND VALUE <= 120) Рассмотрим приведенную выше команду. Мы попросили сервер создать домен CREATE DOMAIN с именем dage на основе целочисленного типа AS INTEGER, причем, если пользователь не укажет возраст, то будет использовано значение по умолчанию 0 -- DEFAULT 0, и значение поля должно находиться в пределах от 0 до 120 -- CHECK(VALUE >= 0 AND VALUE <= 120). Мы могли бы указать, что поле будет обязательно для заполнения -- NOT NULL, но в этом нет необходимости, так как NULL значение в любом случае не пройдет проверку CHECK.

Основи SQL

5. Батьківська і підлегла БД. Забезпечення посилальної цілісності

Декларативные ограничения целостности задаются на уровне операторов создания таблиц. При описании таблицы задается имя таблицы, которое является идентификатором в базовом языке СУБД и должно соответствовать требованиям именования объектов в данном языке. Кроме имени таблицы в операторе указывается список элементов таблицы, каждый из которых служит либо для определения столбца, либо для определения ограничения целостности определяемой таблицы. Требуется наличие хотя бы одного определения столбца. То есть таблицу, которая не имеет ни одного столбца, определить нельзя. Количество столбцов в одной таблице не ограничено, но в конкретных СУБД обычно бывают ограничения на количество атрибутов. Так, например, в MS SQL Server 6.5 максимальное количество столбцов в таблице было 250, но уже в MS SQL Server 7.0 оно увеличено до 1024.При задании ограничений уникальности данный столбец определяется как возможный ключ, что предполагает уникальность каждого вводимого значения в данный столбец. И если это ограничение задано, то СУБД будет автоматически осуществлять проверку на отсутствие дубликатов значений данного столбца во всей таблице. Если в разделе ограничений целостности указано ограничение по ссылкам данного столбца, то порождается соответствующее определение ограничения по ссылкам для таблицы: FOREIGN KEY(<имя столбца>) < спецификация ссылки>, что означает, что значения данного столбца должны быть взяты из соответствующего столбца родительской таблицы. Родительской таблицей в данном случае называется таблица, которая связана с данной таблицей связью "один-ко-многим" (1:М). При этом каждая строка родительской таблицы может быть связана с несколькими строками определяемой таблицы. Трансляция операторов SQL проводится в режиме интерпретации, поэтому важно, чтобы сначала была бы описана родительская таблица, а потом уже все подчиненные таблицы, связанные с ней. Иначе транслятор определит ссылку на неопределенный объект. Сначала должны быть описаны все основные таблицы, а потом подчиненные таблицы.

Основи SQL

8. Підзапити. Вкладені підзапити

Подзапрос - очень мощное средство языка SQL. Он позволяет строить сложные иерархии запросов, многократно выполняемые в процессе построения результирующего набора или выполнения одного из операторов изменения данных (DELETE, INSERT, UPDATE). Условно подзапросы иногда подразделяют на три типа, каждый из которых является сужением предыдущего:
    табличный подзапрос, возвращающий набор строк и столбцов; подзапрос строки, возвращающий только одну строку, но, возможно, несколько столбцов (такие подзапросы часто используются во встроенном SQL); скалярный подзапрос, возвращающий значение одного столбца в одной строке.
Вложенный подзапрос - это подзапрос, заключенный в круглые скобки и вложенный в WHERE (HAVING) фразу предложения SELECT или других предложений, использующих WHERE фразу. Вложенный подзапрос может содержать в своей WHERE (HAVING) фразе другой вложенный подзапрос и т.д. Нетрудно догадаться, что вложенный подзапрос создан для того, чтобы при отборе строк таблицы, сформированной основным запросом, можно было использовать данные из других таблиц (например, при отборе блюд для меню использовать данные о наличии продуктов в кладовой пансионата).SELECT * from tbl1 WHERE f2=(SELECT f2 FROM tbl2 WHERE f1=1);Коррелированные подзапросы В операторе SELECT из внутреннего подзапроса можно ссылаться на столбцы внешнего запроса, указанного во фразе SELECT. Такой подзапрос выполняется для каждой строки таблицы, определяя условие ее вхождения в формируемый результирующий набор. Например:SELECT * from tbl1 t1 WHERE f2 IN (SELECT f2 FROM tbl2 t2 WHERE t1.f3=t2.f3); В данном случае для каждой строки таблицы tbl1 будет проверяться условие, что значение поля f2 совпадает со значением строки таблицы tbl2, где значение поля f3 равно значению поля f3 внешней таблицы (tbl1). Это простейший пример коррелированного подзапроса.

  1. Предисловие Системы управления базами данных (субд) – это программные комплексы, предназначенные для работы со специально организованными файлами (массивами данных, долговременно хранимыми во внешней памяти вычислительных систем), которые называются

    Документ

    Системы управления базами данных (СУБД) – это программные комплексы, предназначенные для работы со специально организованными файлами (массивами данных, долговременно хранимыми во внешней памяти вычислительных систем), которые называются базами данных.

  2. Http://www citforum ru/database/osbd/contents shtml Основы современных баз данных

    Реферат

  3. Управления базой данных (субд). Неформально можно определить базу данных как некоторый набор данных, необходимый для работы и организованный тем или иным способом

    Лекция

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

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

Среди многоуровневой архитектуры клиент-сервер наиболее распространена трехуровневая архитектура ( трехзвенная архитектура , three- tier ), предполагающая наличие следующих компонентов приложения: клиентское приложение (обычно говорят "тонкий клиент" или терминал ), подключенное к серверу приложений , который в свою очередь подключен к серверу базы данных [ , ].

рис. 5.4 .


Рис. 5.4. Представление многоуровневой архитектуры "клиент-сервер"

  • Терминал – это интерфейсный (обычно графический) компонент, который представляет первый уровень, собственно приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с базой данных (по требованиям безопасности), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надежности). На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал .
  • Сервер приложений располагается на втором уровне. На втором уровне сосредоточена большая часть бизнес-логики. Вне его остаются фрагменты, экспортируемые на терминалы , а также погруженные в третий уровень хранимые процедуры и триггеры.
  • Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных.

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

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

Плюсами данной архитектуры являются [ , , , ]:

  • клиентское ПО не нуждается в администрировании;
  • масштабируемость;
  • конфигурируемость – изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;
  • высокая безопасность;
  • высокая надежность;
  • низкие требования к скорости канала (сети) между терминалами и сервером приложений ;
  • низкие требования к производительности и техническим характеристикам терминалов , как следствие снижение их стоимости.
  • растет сложность серверной части и, как следствие, затраты на администрирование и обслуживание;
  • более высокая сложность создания приложений;
  • сложнее в разворачивании и администрировании;
  • высокие требования к производительности серверов приложений и сервера базы данных , а, значит, и высокая стоимость серверного оборудования;
  • высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений .
  1. Представление;
  2. Уровень представления;
  3. Уровень логики;
  4. Уровень данных;
  5. Данные.


Рис. 5.5. Пять уровней многозвенной архитектуры "клиент-сервер"

К представлению относится вся информация, непосредственно отображаемая пользователю: сгенерированные html-страницы, таблицы стилей, изображения.

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

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

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

Данные системы обычно хранятся в базе данных.

5.1.6. Архитектура распределенных систем

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

Схематически такую архитектуру можно представить, как показано на рис. 5.6 .


Рис. 5.6.

Более 95 % данных, используемых в управлении предприятием, могут быть размещены на одном персональном компьютере, обеспечив возможность его независимой работы . Поток исправлений и дополнений, создаваемый на этом компьютере, ничтожен по сравнению с объемом данных, используемых при этом. Поэтому если хранить непрерывно используемые данные на самих компьютерах, и организовать обмен между ними исправлениями и дополнениями к хранящимся данным, то суммарный передаваемый трафик резко снизится. Это позволяет понизить требования к каналам связи между компьютерами и чаще использовать асинхронную связь, и благодаря этому создавать надежно функционирующие распределенные информационные системы, использующие для связи отдельных элементов неустойчивую связь типа Интернета, мобильную связь, коммерческие спутниковые каналы. А минимизация трафика между элементами сделает вполне доступной стоимость эксплуатации такой связи. Конечно, реализация такой системы не элементарна, и требует решения ряда проблем, одна из которых своевременная синхронизация данных.

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

Лекция 2

Современные программные приложения и информационные системы достигли такого уровня развития, что термин "архитектура" в применении к ним уже давно не удивляет. Грамотно построить информационную систему, эффективно и надежно функционирующую не проще, чем сконструировать и возвести современное многофункциональное здание.

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

Рассмотрим определение "архитектуры информационной системы", которое дают различные источники:

· Архитектура – это организационная структура системы.

· Архитектура информационной системы – концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы.

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

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

· Архитектура программы или компьютерной системы – это структура системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними.

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

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

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



Под архитектурой программных систем будем понимать совокупность решений относительно:

· организации программной системы;

· выбора структурных элементов, составляющих систему и их интерфейсов;

· поведения этих элементов во взаимодействии с другими элементами;

· объединение этих элементов в подсистемы;

· архитектурного стиля, определяющего логическую и физическую организацию системы: статические и динамические элементы, их интерфейсы и способы их объединения.

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

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

Для того чтобы построить правильную и надежную архитектуру и грамотно спроектировать интеграцию программных систем необходимо четко следовать современным стандартам в этих областях. Без этого велика вероятность создать архитектуру, которая неспособна развиваться и удовлетворять растущим потребностям пользователей ИТ. В качестве законодателей стандартов в этой области выступают такие международные организации как SEI (Software Engineering Institute), WWW (консорциум World Wide Web), OMG (Object Management Group), организация разработчиков Java – JCP (Java Community Process), IEEE (Institute of Electrical and Electronics Engineers) и другие.

Рассмотрим классификацию программных систем по их архитектуре:

· Централизованная архитектура;

· Архитектура "файл-сервер";

· Двухзвенная архитектура "клиент-сервер";

· Многозвенная архитектура "клиент-сервер";

· Архитектура распределенных систем;

· Архитектура Веб-приложений;

· Сервис-ориентированная архитектура.

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

Местоположение БД определяет так называемую архитектуру базы данных , и базы данных разделяются на:

· локальные;

· удаленные.

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

Расположение БД в значительной степени влияет на разработку приложения, обрабатывающего содержащиеся в этой базе данные.

Локальные БД располагаются на том же компьютере, что и работающие с ними приложения. В этом случае информационная система имеет локальную архитектуру (рис.1). Работа с БД происходит, как правило, в однопользовательском режиме. При необходимости можно запустить на компьютере другое приложение, одновременно осуществляющее доступ к этим же данным. Для управления совместным доступом к БД необходимы специальные средства контроля и защиты. Эти средства могут понадобиться, например, в случае, когда приложение пытается изменить запись, которую редактирует другое приложение. Каждая разновидность БД осуществляет подобный контроль своими способами и обычно имеет встроенные средства разграничения доступа.

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

При работе с данными на каждом пользовательском компьютере сети используется локальная копия БД. Эта копия периодически обновляется данными, содержащимися в БД на сервере.

Архитектура «файл-сервер» обычно применяется в сетях с небольшим количеством пользователей, для ее реализации подходят персональные СУБД, например, Рагаdох или dBasе. Достоинствами этой архитектуры являются простота реализации, а также то, что приложение фактически разрабатывается в расчете на одного пользователя и не зависит от того, на каком компьютере в сети оно устанавливается.

Достоинства такой архитектуры:

· многопользовательский режим работы с данными;

· удобство централизованного управления доступом;

· низкая стоимость разработки;

· высокая скорость разработки;

· невысокая стоимость обновления и изменения ПО.

Однако архитектура «файл-сервер» имеет и существенные недостатки.

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

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

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

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

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

Сервер – это сама СУБД. Он поддерживает все основные функции СУБД: определение данных, обработку данных, защиту данных, поддержание целостности данных и т.д.

Клиент – это приложение пользователя. Для получения данных клиент формирует и отсылает запрос удаленному серверу, на котором размещена БД. Запрос формируется на языке SQL, который является стандартным средством доступа к серверу при использовании реляционных моделей данных. После получения запроса удаленный сервер направляет его SQL-серверу (серверу баз данных) – специальной программе, управляющей удаленной БД и обеспечивающей выполнение запроса и выдачу его результатов клиенту.

Таким образом, в архитектуре «клиент-сервер» клиент посылает запрос на предоставление данных и получает только те данные, которые действительно были затребованы. Вся обработка запроса выполняется на удаленном сервере. Такая архитектура обладает следующими достоинствами:

1. Снижение нагрузки на сеть, поскольку теперь в ней циркулирует только нужная информация.

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

3. Уменьшение сложности клиентских приложений за счет отсутствия в них кода, связанного с контролем БД и разграничением доступа к ней.

Недостатками такой архитектуры являются:

· неработоспособность сервера может сделать неработоспособной всю вычислительную сеть;

· администрирование данной системы требует квалифицированного профессионала;

· высокая стоимость оборудования;

· бизнес логика приложений осталась в клиентском ПО.

Для реализации архитектуры «клиент-сервер» обычно используются многопользовательские СУБД, например, Oracle или Мicrosoft SQL Server. Подобные СУБД также называют промышленными, так как они позволяют создать информационную систему организации или предприятия с большим числом пользователей.

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

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

Клиент (слой клиента) - это интерфейсный (обычно графический) компонент комплекса, предоставляемый конечному пользователю. Этот уровень не должен иметь прямых связей с базой данных (по требованиям безопасности и масштабируемости), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надёжности). На этот уровень обычно выносится только простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции с данными (сортировка, группировка, подсчёт значений), уже загруженными на терминал.

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

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

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

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

Для доступа к тем или иным сетевам сервисам используются клиенты, возможности которых характеризуются понятием «толщины». Оно определяет конфигурацию оборудования и программное обеспечение, имеющиеся у клиента. Рассмотрим возможные граничные значения:

«Тонкий» клиент . Этот термин определяет клиента, вычислительных ресурсов которого достаточно лишь для запуска необходимого сетевого приложения через web-интерфейс. Пользовательский интерфейс такого приложения формируется средствами статического HTML (выполнение JavaScript не предусматривается), вся прикладная логика выполняется на сервере.

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

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

Так же под «толстым» клиентом подразумевается и клиентское сетевое приложение, запущенное под управлением локальной ОС. Такое приложение совмещает компонент представления данных (графический пользовательский интерфейс ОС) и прикладной компонент (вычислительные мощности клиентского компьютера).

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

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

Сервер — один или несколько многопользовательских процессоров с единым полем памяти, который в соответствии с потребностями пользователя обеспечивает им функции вычисления, коммуникации и доступа к базам данных. Сервер можно назвать программу, представляющая какие-то услуги другим программам. Примеры серверов - вебсервер Apache, серверы баз данных - MySQL, ORACLE, сетевые файловые системы и принтера Windows.

Клиент — рабочая станция для одного пользователя, обеспечивающая режим регистрации и др. необходимые на его рабочем месте функции вычисления, коммуникацию, доступ к базам данных и др. Клиентом можно назвать это программа, использующая услугу, представляемую программой сервера. Примеры клиентов - MSIE (MS Internet Explorer), клиент ICQ.

Часто люди клиентом или сервером просто называют компьютер, на котором работает какая-то из этих программ.

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

Если проводить аналогию с обществом - банк или магазин - «сервера». Они представляют какие-то услуги своим клиентам. Но банк может в то же время быть клиентом какой-то другой фирмы и т. д…

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

СУБД с персональных ЭВМ (такие, как Clipper, DBase, FoxPro, Paradox, Clarion имеют сетевые версии, которые просто совместно используют файлы баз данных тех же форматов для ПК, осуществляя при этом сетевые блокировки для разграничения доступа к таблицам и записям. При этом вся работа осуществляется на ПК. Сервер используется просто как общий удаленный диск большой емкости. Такой способ работы приводит к риску потери данных при аппаратных сбоях.

По сравнению с такими системами системы, построенные в архитектуре Клиент — Сервер, имеют следующие преимущества:

    позволяют увеличить размер и сложность программ, выполняемых на рабочей станции;

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

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

    в несколько раз уменьшает объем информации, передаваемый по сети.

    В архитектуре «клиент-сервер» сервер базы данных не только обеспечивает доступ к общим данным, но и берет на себя всю обработку этих данных. Клиент посылает на сервер запросы на чтение или изменение данных, которые формулируются на языке SQL. Сервер сам выполняет все необходимые изменения или выборки, контролируя при этом целостность и согласованность данных, и результаты в виде набора записей или кода возврата посылает на компьютер клиента.

    Она позволяет оптимальным образом распределить вычислительную нагрузку между клиентом и сервером, что также влияет на многие характеристики системы: стоимость, производительность, поддержку.

    1.2. История…

    Архитектура и термин «клиент-сервер» впервые использовались в начале 80-тых годов. Первые приложения с архитектурой «клиент-сервер» были базы данных.

    До этого не было ясного разделения - программа обычно всё делала сама - в том числе работала с данными в файловой системе, представлением данных пользователю и др. Со временем рос объем и критичность данных для бизнеса, и это со временем начало породить проблемы (быстродействия, безопасности и другие).

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

    По существу «взрыв» популярности технологии «клиент-сервер» был вызван изобретением фирмой IBM простого языка запросов к реляционным базам данных SQL. Сегодня SQL всеобщий стандарт работы с базами данных. В последнее время этот «взрыв» продолжает изобретение Интернета, в котором буквально каждое взаимодействие происходит по архитектуре «клиент-сервер».

    1.3. Протоколы

    Сервер и клиент в сети между собой «разговаривает» на «языке» (в широком смысле слов), понятном обеим сторонам. Этот «язык» называют протоколом.

    В случае банка, протоколом можно назвать бланки, которые заполняет клиент.

    В нашем же случае, примеры протоколов:

    FTP (File Transfer Protocol)

    HTTP (Hyper Text Transfer Protocol)

    SMTP (Simple Mail Transfer Protocol)

    IP (Internet Protocol)

    MySQL Client/Server Protocol

    Заметим, что протоколы может быть разных уровней. Классификационные системы уровней может быть разные, но одна из самых известных линеек - OSI (Open Systems Interconnection), в котором 7 уровней.

    Например, HTTP - протокол прикладного (седьмого - самого высокого) уровня, а IP - протокол сетевого (третьего) уровня.

    1.4. Распределение функций в архитектуре «клиент-сервер»

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

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

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

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

    Вся логика работы приложения - прикладные задачи, бизнес-правила - в двух-звенной архитектуре распределяются разработчиком между двумя процессами: клиентом и сервером (рис. 1).

    Сначала большая часть функций приложения решалась клиентом, сервер занимался только обработкой SQL-запросов. Такая архитектура получила название «толстый клиент - тонкий сервер».

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

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

    рассмотренные выше модели имеют следующие недостатки.

    1. «Толстый» клиент:

    – сложность администрирования;

    – усложняется обновление ПО, поскольку его замену нужно производить одновременно по всей системе;

    – усложняется распределение полномочий, так как разграничение доступа происходит не по действиям, а по таблицам;

    – перегружается сеть вследствие передачи по ней необработанных данных;

    – слабая защита данных, поскольку сложно правильно распределить полномочия.

    2. «Толстый» сервер:

    – усложняется реализация, так как языки типа PL/SQL не приспособлены для разработки подобного ПО и нет хороших средств отладки;

    – производительность программ, написанных на языках типа PL/SQL, значительно ниже, чем созданных на других языках, что имеет важное значение для сложных систем;

    – программы, написанные на СУБД-языках, обычно работают недостаточно надежно; ошибка в них может привести к выходу из строя всего сервера баз данных;

    – получившиеся таким образом программы полностью непереносимы на другие системы и платформы.

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

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

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


    Рис. 1. Распределение функций между клиентом и сервером

    Появилось специальное программное обеспечение (ПО) промежуточного слоя, которое должно обеспечить совместное функционирование множества компонентов такого многокомпонентного приложения. Такие приложения являются гибкими, масштабируемыми, но сложными в разработке.


    СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

  1. Информатика / Под ред. Н.В. Макаровой.–М.: Финансы и статистика, 1998.

    Евдокимов В.В. и др. Экономическая информатика. СПб.: Питер, 2004.

    Казаков С.И. Основы сетевых технологий – М.: Радио и связь, 2004.

    Когаловский М.Р., Технология баз данных на персональных ЭВМ, – М.: Финансы и статистика, 2003.

    Попов В.В. Основы компьютерных технологий. –М.: Финансы и статистика, 2001.

    Фигурнов В.Э. IBM PC для пользователя. М., 2000.

ОПЕРАЦИОННАЯ СИСТЕМА MS-DOS . ОСНОВНЫЕ ПОНЯТИЯ И КОМАНДЫ ОСНОВНЫЕ ПОНЯТИЯ: БАЗА ДАННЫХ, СУБД, СУЩНОСТЬ, АТРИБУТ, СВЯЗЬ (ОДИН-К-ОДНОМУ, ОДИН-КО-МНОГИМ, МНОГИМ-КО-МНОГИМ), ОТНОШЕНИЕ, ПЕРВИЧНЫЙ КЛЮЧ

Преимущества

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

· Все данные хранятся на сервере, который, как правило, защищён гораздо лучше большинства клиентов. На сервере проще обеспечить контроль полномочий, чтобы разрешать доступ к данным только клиентам с соответствующими правами доступа.

· Позволяет объединить различные клиенты. Использовать ресурсы одного сервера часто могут клиенты с разными аппаратными платформами, операционными системами и т. п.

Недостатки

· Неработоспособность сервера может сделать неработоспособной всю вычислительную сеть.

· Поддержка работы данной системы требует отдельного специалиста - системного администратора.

· Высокая стоимость оборудования.

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

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

Частные случаи многоуровневой архитектуры:

В компьютерных технологиях трёхуровневая архитектура, синоним трёхзвенная архитектура (англ. three-tier или Multitier architecture) предполагает наличие следующих компонентов приложения: клиентское приложение (обычно говорят «тонкий клиент» или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных.

Обзор архитектуры

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

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

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

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

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

Достоинства

По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующие достоинства трёхуровневой архитектуры:

· масштабируемость

· конфигурируемость - изолированность уровней друг от друга позволяет (при правильном развертывании архитектуры) быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней

· высокая безопасность

· высокая надёжность

· низкие требования к скорости канала (сети) между терминалами и сервером приложений

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

Недостатки

Недостатки вытекают из достоинств. По сравнению c клиент-серверной или файл-серверной архитектурой можно выделить следующие недостатки трёхуровневой архитектуры:

· более высокая сложность создания приложений;

· сложнее в разворачивании и администрировании;

· высокие требования к производительности серверов приложений и сервера базы данных, а, значит, и высокая стоимость серверного оборудования;

· высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений.



Статьи по теме
Еще статьи из этой рубрики
Характеристики Galaxy S8 и Galaxy S8 Plus Характеристики Galaxy S8 и Galaxy S8 Plus
Как обрезать SIM-карту под Micro SIM? Как обрезать SIM-карту под Micro SIM?
Тариф «Киевстар Разговоры» с региональными предложениями для звонков внутри сети Киевстар онлайн регион 2 Тариф «Киевстар Разговоры» с региональными предложениями для звонков внутри сети Киевстар онлайн регион 2
Samsung galaxy core 2 год выпуска Samsung galaxy core 2 год выпуска
Условия участия в бонусной программе Условия участия в бонусной программе
AdBlock для всех Браузеров AdBlock для всех Браузеров

© 2024 beasthackerz.ru - Браузеры. Аудио. Жесткий диск. Программы. Локальная сеть. Windows