3.2. Трехуровневая архитектура субд
Предметная область представляет собой часть реального мира, которая исследуется или используется. Это может быть «Заказ» (см. пример в п. 1.3), «Изготовление изделий на заказ», «Сбыт готовой продукции», «Оформление заказов через Интернет» и др. Из-за сложности предметной области охватить ее аспекты в одноуровневой модели не представляется возможным. Поэтому используются три уровня: концептуальный (понятийный), логический и физический.
Концептуальный уровень отражает предметную область в самом общем виде. Он определяет содержание и структуру предметной области безотносительно к моделям данных (см. раздел 2) и типу используемой СУБД. Этот уровень должен быть понятен пользователю и полностью независим от того, как данные будут храниться в действительности. Изменения в этой модели должны производиться только при изменениях в реальном мире, чтобы эта модель продолжала быть отражением предметной области.
Логический уровень является промежуточным, на котором производится формализация модели. На этом уровне предметная область отображается в виде информационных объектов (сущностей) и связей между ними. Для реляционной модели сущности являются «прообразами» таблиц, а связи отображают отношения между ними. Логическая модель лежит в основе построения БД, в том числе и с использованием CASE-средств.
Физический уровень модели предметной области определяет способ реализации в среде выбранной СУБД. Одной логической модели может соответствовать несколько физических моделей (для разных СУБД). В CASE-средствах осуществляется автоматическое преобразование логической модели в физическую для выбранной конкретной СУБД. На основе физической модели осуществляется проектирование структуры базы данных. С использованием CASE-средств этот процесс происходит автоматически и называется прямым проектированием. CASE-средства позволяют также на основе существующей БД создавать физическую, а затем и логическую модели (обратное проектирование).
Трехуровневая архитектура СУБД
Первые попытки стандартизации общей архитектуры СУБД относятся к 1971 году, когда был предложен двухуровневый подход к архитектуре СУБД на основе использования системного представления, включающего понятие схемы базы данных и пользовательских представлений (подсхем).
В 1978 году комитетом ANSI/SPARC (ANSI, American National Standard Institute – Национальный институт стандартизации США; SPARC, Standard Planning and Requirements Committee – Комитет планирования стандартов и норм) официально зафиксировано различие между логическим и физическим представлением данных. В частности, была предложена обобщенная структура систем с базой данных.
Эта структура получила название трехуровневой архитектуры, включающей внутренний, концептуальный и внешний уровни (рис. 2.1).
Введение трехуровневой архитектуры БД позволило отделить пользовательское представление БД от ее физического представления.
Необходимость такого отделения обусловлена, прежде всего, следующими причинами:
каждый пользователь должен иметь возможность обращаться к одним и тем же данным, используя собственное представление об этих данных, а также изменять его при необходимости, что не должно оказывать влияния на представление о данных других пользователей;
обращение пользователя к БД на должно зависеть от особенностей хранения в ней данных;
администратор БД может при необходимости изменять структуру хранения данных в базе, включая концептуальную структуру БД, причем данные действия не должны влиять на пользовательские представления данных;
внутренняя структура хранения данных не должна зависеть от изменения физических устройств хранения информации.
Приложения ИС и пользовательские представления
Внешний уровень
/> 
Концептуальная схема Концептуальный уровень
Хост-система Внутренний уровень
Данные в базе, хранящиеся на физическом носителе
Рис. 3.2. Трехуровневая архитектура СУБД
Таким образом, в трехуровневой модели СУБД:
Внутренний уровень – это уровень, определяющий физический вид БД, наиболее близкий к физическому хранению. Он связан со способами хранения информации на физических устройствах. К данному уровню имеют отношение дисководы, физические адреса, индексы, указатели и т.д. За работу данного уровня отвечают проектировщики физической БД, которые решают, какие физические устройства будут хранить данные, какие методы доступа к данным будут использоваться и какие меры следует принять для поддержания или повышения быстродействия СУБД. Для пользователей данный уровень закрыт.
Концептуальный уровень – структурный уровень, который дает представление о логической схеме БД. На данном уровне выполняется концептуальное проектирование БД, которое включает анализ информационных потребностей пользователей и определение нужных им элементов данных. Результатом концептуального проектирования является концептуальная схема БД, а также логическое описание всех элементов данных и отношений между ними. Как было сказано выше, концептуальная схема БД не связана напрямую с выбранной моделью данных и СУБД, в то время как логическая схема уже предполагает представление структуры данных в рамках выбранной модели (см. раздел 2).
Внешний уровень – структурный уровень БД, определяющий пользовательские представления данных. Каждый пользователь или группа пользователей получают свое собственное представление данных в БД. Такое пользовательское описание элементов данных и отношений между ними можно напрямую вывести из концептуальной схемы. Совокупность различных пользовательских представлений данных и образует внешний уровень [20, С.9-13].
В разделе 2.1 был показан пример схемы данных (рис. 2.1). Под схемой данных (схемой базы данных) понимается общее описание базы данных. В соответствии с трехуровневой архитектурой различают и три типа схем базы данных.
Внешнему уровню представления БД соответствуют, как правило, несколько внешних схем (подсхем) БД. Каждая из таких схем соответствует представлению данных определенной группы пользователей СУБД.
Концептуальная схема описывает все элементы данных, связи между ними, а также необходимые ограничения для поддержки целостности данных. Для каждой БД имеется только одна концептуальная схема данных.
Внутренняя схема является полным описанием внутренней модели данных и содержит определения хранимых записей, методы представления, описания полей данных, сведения об индексах и пр. Также как и для концептуальная схема, внутренняя схема для каждой БД только одна.
Исходя из различных схем БД в трехуровневой модели, следует, что СУБД должна устанавливать соответствие и следить за непротиворечивостью схем: внешними, концептуальной и внутренней.
Концептуальная схема — центральное связующее звено между каждой внешней схемой и внутренней схемой БД. Концептуальная схема связана с внутренней схемой посредством внутреннего концептуального отображения. Каждая внешняя схема, в свою очередь, связана с концептуальной схемой с помощью внешнего концептуального отображения, которое позволяет отображать пользовательское представление на соответствующую часть концептуальной схемы.
В теории и практике баз данных принято различать понятия «описание базы данных» и «база данных» [20, С.12-13].
Под описанием базы данных понимают схему БД, создаваемую в процессе проектирования БД, изменение которой предполагается в исключительных случаях.
Под базой данных понимается вся информация, содержащаяся в базе, которая может изменяться с течением времени. Совокупность информации, хранящейся в БД в любой определенный момент времени, называется состоянием базы данных. Таким образом, одной и той же схеме БД может соответствовать множество различных состояний БД. Состояние БД также называется детализацией.
Главное назначение трехуровневой архитектуры – обеспечение независимости от данных, т.е. любые изменения на нижних уровнях БД не должны влиять на верхние уровни.
Независимость бывает двух типов:
логическая – полная защищенность внешних схем от изменений, которые вносятся в концептуальную схему;
физическая – защищенность концептуальной схемы от изменений, которые вносятся во внутреннюю схему.
Трёхуровневая архитектура
В компьютерных технологиях трёхуровневая архитектура, синоним трёхзвенная архитектура (англ. three-tier или Multitier architecture) предполагает наличие следующих компонентов приложения: клиентское приложение (обычно говорят «тонкий клиент» или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных.
Содержание
Обзор архитектуры
- Клиент — это интерфейсный (обычно графический) компонент, который представляет первый уровень, собственно приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с базой данных (по требованиям безопасности), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надежности). На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал.
- Сервер приложений располагается на втором уровне. На втором уровне сосредоточена бо́льшая часть бизнес-логики. Вне его остаются фрагменты, экспортируемые на терминалы (см.выше), а также погруженные в третий уровень хранимые процедуры и триггеры.
- Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированнаяСУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных.
В простейшей конфигурации физически сервер приложений может быть совмещён с сервером базы данных на одном компьютере, к которому по сети подключается один или несколько терминалов.
В «правильной» (с точки зрения безопасности, надёжности, масштабирования) конфигурации сервер базы данных находится на выделенном компьютере (или кластере), к которому по сети подключены один или несколько серверов приложений, к которым, в свою очередь, по сети подключаются терминалы.
Достоинства
По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующие достоинства трёхуровневой архитектуры:
Недостатки
Недостатки вытекают из достоинств. По сравнению c клиент-серверной или файл-серверной архитектурой можно выделить следующие недостатки трёхуровневой архитектуры:
Основные архитектурные шаблоны построения ПО
Краткий обзор восьми наиболее востребованных архитектурных шаблонов с иллюстрациями:
Использование шаблона проектирования можно сравнить с присутствием в вашей команде других архитекторов, от которых вы получаете знания, не вкладывая в это слишком много времени. В сфере разработки ПО существует масса всевозможных шаблонов, но в этой статье я решил сосредоточиться на наиболее используемых без привязки к конкретному языку.
Чем архитектурные шаблоны отличаются от шаблонов проектирования?
В названии статьи упоминаются архитектурные шаблоны, так что, думаю, следует прояснить их отличие от шаблонов проектирования, хотя это отличие может оказаться довольно неоднозначным. В первую очередь стоит отметить, что отличаются они типом решаемых с их помощью задач. Архитектурные шаблоны определяют решение для достижения различных качественных характеристик системы и подразумевают работу с несколькими компонентами ПО. В этом их область применения обширнее области шаблонов проектирования, которые предоставляют способ для структуризации классов с целью создания оптимальной внутренней структуры.
▍ Многоуровневый шаблон
Начнём с, пожалуй, наиболее востребованной многоуровневой архитектуры. Разделение системы на отдельные уровни с организацией внутри них компонентов по соответствующим критериям позволяет более слаженно взаимодействовать отдельным разработчикам и командам. В таком подходе уровни способствуют применению полезных практик слабого зацепления и высокой связности.
Строго говоря, в этой модели каждый модуль должен присваиваться только одному уровню, притом, что вышестоящие уровни могут использовать нижестоящие. Такая структура оправдывает себя в плане обслуживаемости, позволяя разным командам параллельно работать над разными модулями. Вот пример подобной схемы:
Многоуровневый шаблон
API взаимодействует с сервисами бизнес-логики, которые, в свою очередь, обращаются к уровню данных. При этом все они могут иметь общий набор библиотек для повторного использования компонентов.
▍ Шаблон «Клиент-сервер»
Тоже очень распространённый шаблон, в котором сервер предлагает один или более сервисов, потребляемых одним или более клиентами. Будучи простой, но в то же время очень мощной, эта модель даёт возможность построения распределённых систем, в которых сервер централизует ресурсы и рабочую нагрузку в одном месте, позволяя множеству потребителей использовать эти данные независимо.
На основе этого механизма работают мобильные приложения, Twitter, Medium, электронная почта, обмен файлами и Web в целом. В таком контексте пользовательские приложения потребляют данные и предоставляют интерфейс для взаимодействия с ними, в результате чего клиент и сервер формируют общую систему. Однако в рамках этого шаблона есть строгое распределение обязанностей и ответственностей.
Шаблон «Клиент-сервер»
▍ Шаблон «Каналы и фильтры»
В случае шаблона «Каналы и фильтры» каждый компонент-фильтр отвечает за одно преобразование данных или операцию с ними. Данные передаются от одного фильтра следующему максимально быстро, и операция над ними выполняется параллельно. Раздельные фильтры даже можно повторно использовать и менять местами для создания новых пайплайнов.
Этот шаблон широко применяется в анализе и преобразовании данных. Наиболее же типичный пример — это использование Unix-функции pipe для комбинирования команд — суть та же.
Шаблон «Каналы и фильтры»
- фильтр: компонент, который считывает данные, преобразует их и возвращает результат;
- канал: связующий компонент, переносящий данные от одного фильтра к другому и гарантирующий их неизменность на этом пути.
▍ Шаблон SOA
В сервис-ориентированной архитектуре (SOA) независимые компоненты реализуются в виде сервисов, что предоставляет специфическую функциональность. Эти сервисы совмещаются в среде выполнения, определяя поведение системы в целом. Чтобы это сработало, потребители сервисов должны иметь возможность обнаруживать и использовать их, не зная деталей реализации.
Построить такую архитектуру можно по-разному.
Традиционные системы SOA в основном опираются на протокол SOAP, который работает путём обмена XML-сообщениями, а более «современные» приложения ориентированы на использование микросервисов, которые связываются легковесными сообщениями, передаваемыми по протоколу вроде HTTP.
Ниже приведён упрощённый пример представления системы SOA. На практике же подобные архитектуры сложны и включают множество компонентов. На схеме мы видим два сервиса, подключённых к общему реестру сервисов. Через этот реестр они при необходимости находят информацию для подключения друг к другу.
Обобщённый пример SOA
Эта архитектура повышает функциональную совместимость и масштабируемость системы, но также привносит сложность в процесс определения и интеграции распределённых систем, поскольку зачастую нелегко управлять изменениями в сообщениях, которые могут повлиять на потребителей разных сервисов.
▍ Шаблон «Издатель-подписчик»
В шаблоне «Издатель-подписчик» издатели и потребители данных существуют независимо и являются друг для друга анонимными. В рамках этого шаблона множество потребителей подписываются на события, публикуемые множеством издателей. Обе стороны взаимодействуют опосредованно через шину событий.
Поскольку все взаимодействия реализуются через шину событий, то к ней должны быть подключены все участники. Причём для успешной работы здесь важен правильный выбор подходящей технологии. Ниже показан пример такой системы, в которой разные типы устройств подключены к шине событий.
Шаблон «Издатель-подписчик»
Эта архитектура повышает переиспользуемость и быстродействие при обмене данными, оптимизируя их создание и потребление на шине событий. Однако сложно рассуждать о производительности таких систем, учитывая асинхронную природу коммуникаций. В конечном счёте шина событий оказывается узким местом в системах как с высоким, так и с низким быстродействием.
▍ Шаблон «Общие данные»
В шаблоне «Общие данные» несколько компонентов обращаются к набору данных через общее хранилище. При этом ни один из компонентов не несёт полной ответственности за сами данные или хранилище, так как они являются общими. Такой шаблон особенно эффективен в случаях, когда множеству компонентов требуется доступ к большим объёмам данных.
Шаблон «Общие данные»
И хотя эта схема имеет собственное название, обычно мы видим её в составе более крупных систем, например, когда в архитектуре SOA разные сервисы обращаются к общей базе данных. В таком случае можно определить типы доступа как чтение и запись, установив разные правила и разрешения, оптимизирующие и защищающие доступ к данным. Сегодня сложность этой архитектуры понижается, к примеру, с помощью облачных сервисов вроде AWS RDS, которые обеспечивают для баз данных работу с репликами, масштабируемость и резервное копирование.
Этот шаблон повышает надёжность за счёт согласованности данных, а также масштабируемость и быстродействие в случае их правильной разбивки. С другой стороны, в случае некорректного управления системой существует единая точка отказа.
▍ Шаблон P2P
Одноранговые архитектурные шаблоны принадлежат к категории симметричных шаблонов «Клиент-сервер». Симметричность в данном контексте означает отсутствие в сети подразделения на клиентов и серверы. В этом шаблоне одна система выступает и как клиент, и как сервер.
Каждая система, также называемая пиром, отправляет запросы другим пирам сети и в то же время получает и обслуживает запросы от других пиров этой сети. Такая схема сильно отличается от традиционной клиент-серверной сети, в которой клиент должен только отправлять запрос и ожидать его обработки сервером.
Одноранговая архитектура
Примеры этой архитектуры можно наблюдать в сетях обмена файлами вроде Gnutella, а также протоколе блокчейна и его реализации Bitcoin.
▍ Шаблон «Брокер сервисов»
Брокерская система включает в себя три основных компонента: брокера, сервер и клиента. Этот шаблон используется для структуризации распределённых систем с раздельными компонентами. На определённом уровне он является расширением клиент-серверного подхода для более сложных сценариев.
Брокер – это компонент, отвечающий за переправку сообщений между клиентом и сервером. Эти сообщения представляют собой запросы к сервисам и ответы на них, а также отчёты о возникших исключениях.
Серверы размещают информацию о своих возможностях (сервисы и характеристики) на брокере, который при получении от клиента определённого запроса перенаправляет этого клиента в подходящий сервис из имеющихся в реестре. Хорошими примерами брокеров сообщений являются Apache ActiveMQ, Apache Kafka, RabbitMQ.
Схематично шаблон выглядит так:
Шаблон «Брокер сервисов»
Использовать этот шаблон рекомендуется, когда связь между клиентом и сервером не является фиксированной ввиду присутствия нескольких подходящих серверов или их периодического изменения. Он также актуален, если выбор сервера зависит от определённого критерия, который достаточно сложен для передачи отдельному компоненту. Что же касается настройки или создания брокера, то это сложная задача, которая обычно выполняется одним из провайдеров вроде упомянутых выше.
▍ Поиск подходящей архитектуры
Список шаблонов можно продолжать и продолжать. В действительности я перечислил лишь те, что считаю наиболее распространёнными. Некоторые шаблоны рождаются в ходе решения новых задач, другие могут подходить для различных систем или команд, а третьи лишь одной организации. Важно объективно оценивать структуру вашей системы, а также обращаться к опыту других людей, знакомых с областью стоящей перед вами задачи. Скорее всего, ваше решение потребует комбинирования нескольких из перечисленных шаблонов, ибо сложность является неизбежным фактором во всех успешных системах ПО.
▍ Бонус: несоответствие архитектуры
Архитектурное несоответствие – это феномен, который очень часто встречается при проектировании архитектуры, в которой предполагается, что компонент будет использоваться способом, противоречащим его базовому назначению. В результате возрастает сложность не только разработки архитектуры, но и её обслуживания, что делает невозможным достижение необходимых критериев качества.
Такая ситуация может сложиться на концептуальном уровне, когда архитектурная схема не сопоставлена с наиболее важными атрибутами создаваемой системы, или когда выбрана неподходящая технология. Например, если ничто не указывает на связь архитектуры с моделью издатель-подписчик, то использование реляционной базы данных в качестве основного механизма обмена сообщениями существенно скажется на итоговом результате.
Изучение шаблонов и выделение необходимого времени на подобающее определение архитектуры может избавить от множества проблем, так что не стоит недооценивать этот этап в начале каждого проекта. Даже выбор необходимых технологий нужно производить лишь тогда, когда определена архитектура, но не наоборот, как это часто бывает.
Кролик Олег — ответы на вопросы. Тест от VK testers
Что бы получить стикеры ВК Кролик Олег от ВК Тестерс нужно правильное ответить на 5 вопросов из 8.
Мы подобрали большинство ответов на тест от сообщества VK Testers.
Полные условия получения VK стикерпака «Кролик Олег» читайте здесь
Итак, ответы на вопросы теста Кролик Олег:
- Что является одним из признаков некачественного ПО — Несоответствие функциональным требованиям
- Какого из перечисленных протоколов НЕ существует? — DCP
- Как расшифровывается UEFI? — Unified Extensible Firmware Interface
- Для чего нужно нагрузочное тестирование? — Для анализа изменения состояния приложения под нагрузкой
- На чьей стороне исполняется JavaScript? — Клиента
- Чем POST отличается от GET? — GET для получения, POST для создания
- Функция, которая вызывает сама себя, называется — Рекурсивной
- Что такое операционная оболочка? — Программа, реализующая или расширяющая пользовательский интерфейс операционной системы
- Что из перечисленного является инструментом для автоматизации действий веб-браузера? — Selenium
- Какая жидкость позволит произвести негативное тестирование кружки? — Уксусная кислота
- Зачем для тестирования используют консоль в браузере? — Для отладки
- Что не используют для измерения объемов памяти? — Киобит
- Что из перечисленного является устойчивым названием одного из элементов пользовательского интерфейса? — TV button
- Как можно посмотреть содержимое icmp-пакетов? — С помощью tcpdump
- Какой из этих тестов негативный? — Забегает в бар и заказывает 0 кружек пива
- Чем отличаются браузеры? — Движком
- Для чего нужен DNS? — Для преобразования доменов в IP-адреса
- От чего зависит отображение сайта в браузере? — Скорости загрузки
- Что полезного можно найти в системных логах? — Сообщения об ошибках
- Какое минимальное количество тестовых конфигураций необходимо, если локалей две: ru и en,
- поддерживаемые браузеры Chrome и Safari, а поддерживаемые версии iOS 9 и 10? — 6
- Чем тестирование отличается от отладки? — Предметно: поиском бага и причины бага
- Что такое UX? — Опыт взаимодействия пользователя с приложением
- Что из этого не является частью тестирования производительности? — Функциональное тестирование
- Что не используют для измерения объемов памяти? — Киобит
- В чем отличие локализации от интернационализации? — Интернационализация — адаптация продукта для использования везде, локализация — в конкретных регионах
- Что подразумевается под чек-листами в тестировании? — Инструмент для пошагового тестирования приложения
- Для чего тестировщику менять ширину канала? — Моделировать проблемы с сетевым подключением
- Что означает буква S в HTTPS ? — Безопасный
- Что или кто называется Linux? — Ядро ОС
- Зачем ВКонтакте API? — Для предоставления сервисов и данных разработчикам приложений
- Что такое тест-кейс? Инструмент тестировщика, предназначенный для документирования и проверки одного или более ожидаемых результатов
- Что такое XSS? — Межсайтовый скриптинг
- Зачем тестировщику консоль в браузере? — Для дополнительной информации
- Какой термин используется для обозначения короткого цикла тестов для подтверждения работоспособности основных функций приложения? — Smoke test
- Для чего нужно нагрузочное тестирование? — Для анализа изменения состояния приложения под нагрузкой
- Какой из протоколов не является защищенным? — FTP
- Как тестовое покрытие влияет на качество продукта? — Не прямо пропорционально
- Чем альфа-тестирование отличается от бета-тестирования? — Кругом лиц
- Зачем для тестирования используют консоль в браузере? — Для запуска тестов
- Что такое FTP? — Протокол для передачи данных по сети, основан на TCP
- Зачем тестировщику VPN? — Для защищенности тестовой среды
- Что такое регрессионное тестирование? — Тестирование, направленное на обнаружение новых багов во всей функциональности продукта
- Какой из этих элементов присутствует в трехуровневой архитектуре программного комплекса? — Сервер базы данных
- Чем тестирование производительности отличается от нагрузочного тестирования? — Нагрузочное — при максимальных нагрузках, производительности — время отклика при различных нагрузках
- Объясните фразу «Я знаю отличную шутку про UDP, но не факт, что она до вас дойдет». — UDP предоставляет ненадёжный сервис
- Расшифруйте аббревиатуру QA.- Quality Assurance
Скоро выйдут новые подарки и бесплатные стикеры! Что бы узнать о них первым: