Remkomplekty.ru

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

Логическая архитектура системы

Архитектура

Пространства имён

Действия на странице

Системная архитектура (Architecture) — имеет множество определений:

  1. Из ISO 42010 (2011): Архитектура (системы) – фундаментальная организация системы, реализованная в ее компонентах, их взаимосвязях друг с другом и с окружающей средой, и руководящие правила проектирования и развития системы;
  2. Из книги Garlan et al. (1996): Архитектура системы это набор структур, необходимых для рассуждений о системе, каковые структуры состоят из элементов, отношений и свойств этих элементов и отношений;
  3. Набор из более чем 150 других определений архитектуры, которые предлагались профессионалами системной и программной инженерии;
  4. Ralf Johnson в статье Who Needs Architect? (2003): “Архитектура — это обо всём важном. Что бы это ни было” (Architecture is about the important stuff. Whatever that is). Если представить архитектуру как набор инженерных решений, принимаемых для определения структуры системы, то “важные решения” — это при изменении которых приходится в существенной мере изменять множество других решений, в существенной мере перепроектировать систему.

Системная архитектура — эта альфа, пожалуй, важнейшая среди подальф определения системы.

Содержание

Архитектурные описания

Архитектура — это основные описания (представления, views) “прозрачного ящика”, которые показывают, из каких основных частей (компонент, модулей, размещений и т.д.) состоит система, и как эти описания “прозрачного ящика” обеспечивают функцию “чёрного ящика”.

Минимальная архитектура состоит из трёх определений (и, соответственно, трёх тематических описаний — наборов рабочих продуктов/моделей):

  • Операционное (практическое) описание (Operational View) — система с точки зрения пользователя или «оператора». Сюда включаются артефакты, относящиеся к этапам практического применения системы, сценариям и потокам работ:
    • описание операций в графическом или числовом виде,
    • описание сценариев и вариантов использования (use cases),
    • диаграммы потоков задач (task flow diagrams),
    • схемы организационной структуры (organization charts),
    • диаграммы информационных потоков (information flow diagrams).
  • Логическое описание (Logical View) — система с точки зрения руководителя или заказчика. Сюда включаются артефакты, определяющие границу между системой и ее окружением, функциональные интерфейсы с внешними системами, основные функции и виды поведения системы, потоки данных, внутренние и внешние наборы данных, внутренние и внешние пользователи и внутренние функциональные интерфейсы:
    • принципиальные схемы, а иногда просто функциональная декомпозиция (data flow chart),
    • диаграммы IDEF0,
    • схемы функциональных потоков (FFBD).
  • Физическое описание (Physical View) — система с точки зрения специалистов по проектированию. Сюда включаются артефакты, которые определяют физическую границу системы, компоненты, их взаимодействие и интерфейсы между ними, внутренние базы данных и структуры данных , информационно-технологическую инфраструктуру системы, стандарты, применяемые при ее разработке:
    • детализированные физические блок-схемы (physical block diagram),
    • топологии баз данных,
    • документы по контролю сопряжений (interface control document, ICD),
    • стандарты.

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

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

Архитектурные инженерные решения

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

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

  1. Общие подходы
    • иерархическое проектирование систем и декомпозиционные подходы;
    • модульное проектирование;
    • проектирование на основе матрицы проектной структуры (DSM, Design Structure Matrix) — метод разбиения системы на модули;
    • проектирование на основе многокритериального принятия решений (см. СППР);
    • морфологический анализ;
    • объектно-ориентированное проектирование;
    • проектирование на основе компонентов.
  2. Формальные подходы к системному проектированию
    • аксиоматическое проектирование;
    • формальные методы проектирования.
  3. Оптимизация
    • многодисциплинарная оптимизация;
    • методы смешанного целочисленного нелинейного программирования;
    • различные методы глобальной оптимизации;
    • нелинейная многоцелевая оптимизация;
    • многоцелевая эволюционная оптимизация, включающая генетические алгоритмы.
  4. Подходы на основе методов искусственного интеллекта
    • специальные экспертные системы и системы на основе баз знаний;
    • проектирование на основе грамматических описаний систем, включая подходы к проектированию составных систем;
    • методы проектирования на основе многоагентных подходов;
    • методы проектирования на основе задач выполнимости (constraint satisfaction problems).
  5. другое.
    • ТРИЗ как метод совмещения логической и физической архитектур;
    • огромное число методов, практикующихся в рамках одного-двух университетских или промышленных исследовательских центров/лабораторий (реже – центров разработки);
    • архитектурные расчёты, в которых принципиальная схема “живая” и по ней можно вести мультифизические расчёты. Например акаузальный язык мультифизического моделирования Modelica;
    • product lines (например, подход для software product line practice, версия 5);
    • Системная инженерия на основе поиска;
    • http://www.cfin.ru/management/controlling/sys_project.shtml

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

Чаще всего разработка архитектуры проходит в такой последовательности:

  1. предложение принципиальной схемы, или функциональной декомпозиции (“логической” схемы);
  2. проведения необходимых мультифизических расчётов;
  3. попытка определить то, как компоненты будут реализованы теми или иными модулями — которые можно купить, или которые придётся разработать;
  4. если предполагаемые принципиальной схемой модули трудно реализовать (их нет на рынке, их трудно спроектировать и изготовить и т.д.), то принципиальная схема меняется и переходят к п.2.
  5. повторяют пп.2-4 до тех пор, пока логическая и физическая архитектуры не окажутся согласованы между собой.

Анализ альтернатив

Субъективность архитектуры — необходимость выбора одного из альтернативных вариантов архитектуры.

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

Системный архитектор или команда системных архитекторов должны предложить сразу несколько разных архитектурных решений (вариантов компонентной структуры/модулей для реализации компонент/разного размещения в пространстве). Лучшие из этих архитектурных решений выбираются при помощи процедуры, известной как trade-off studies [1] . По этой процедуре готовятся таблицы, в которых баллами оцениваются свойства альтернативных вариантов, а затем подсчитывается сумма с учётом каких-то коэффициентов. В реальной жизни решения обычно принимаются содержательным обсуждением, а затем таблицы для trade-off studies оформляются задним числом для отчётности и демонстрации наличия вариантов, учтённых в работе — это как бы “объективация” субъективно принимаемых решений. Если рассматривалась только одна архитектура, то это считается не слишком хорошей работой системного архитектора.

Границы архитектуры

Относительность архитектуры — необходимость разделения архитектурной и неархитектурной частей.

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

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

Границу между архитектурным проектированием (architecting) и непосредственно проектированием системы (designing) можно провести исходя из целей (применения) архитектуры и проекта:

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

Состояния альфы

OMG Essence определяет следующие состояния для альфы «Архитектуры» и контрольные вопросы для проверки каждого состояния:

Логическая архитектура;

Жизненный цикл жестких систем реального времени

Наш подход заключается в разделении архитектурного плана на две фазы:

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

Читать еще:  Типы архитектур клиент сервер

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

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

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

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

Конечные объекты характеризуются как:

Циклические и единичные действия являются обычными в системах реального времени; каждое из них должен содержать поток, который создается во время выполнения. Приоритет потока устанавливается во время планировки в фазе физической архитектуры. Защищенные объекты управляют доступом к данным, которые доступны нескольким потокам (т.е. циклическим и единичным объектам); в частности, они предусматривают взаимное исключение. В однопроцессорных системах это достигается определением верхнего приоритета для каждого защищенного объекта, который равен максимальному количеству потоков, использующих его. Когда поток обращается к защищенному объекту, он начинает работать с верхним приоритетом и, следовательно, получает исключительный доступ к данным, хранимым в защищенном объекте. Защищенные объекты подобны перехватчикам, в которых вызывающий может быть заблокирован, если условия не позволяют ему продолжить. Это используется для задержки единичных объектов, пока не произойдет освобождающее событие. Последним важным типом объектов является пассивный. Он используется для объекта, который или используется только одним объектом, или может использоваться совместно без ошибок.

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

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

· Периодические действия — представляется циклическими объектами.

· Единичные действия — представляется единичными объектами.

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

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

Архитектура ИС, типы архитектур. Классификация ИС

Основным критерием выбора архитектуры и инфраструктуры ИС в услових рыночной экономики является минимизация совокупной стоимости владения системой.

Из этого следуют два основных тезиса:

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

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

Термин «архитектура информационной системы» обычно довольно согласованно понимается специалистами на уровне подсознания, но при этом и определения этого понятия неоднозначны. Имеются два основных класса определений архитектур — «идеологические» и «конструктивные».

Основные идеологические определения архитектуры ИС таковы:

— Архитектура ИС — набор решений, наиболее существенным образом влияющих на совокупную стоимость владения системой;

— Архитектура ИС — набор ключевых решений, неизменных при изменении бизнес-технологии в рамках бизнес-видения.

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

Архитектура ИС – концептуальное описание структуры, определяющее модель, выполняемые функции и взаимосвязь ее компонентов, которое предусматривает наличие 3 компонент:

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

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

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

Управление информационными системами предусматривает выполнение следующих функций:

Управление качеством включает в себя: разработку корпоративных стандартов информационных систем, разработку соглашения об уровне обслуживания (Service Level Agreement — SLA), контроль качества сервисов, проектов.

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

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

Управление развитием информационных систем включает в себя: планирование развития информационных систем, бюджетное планирование, планирование обновления.

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

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

Виды архитектур:

— Файл-сервер – выделенный сервер, оптимизированный для выполнения файловых операций ввода-вывода и предназначенный для хранения файлов любого типа.

— Клиент-сервер – архитектура распределенной вычислительной системы, в которой приложение делится на клиентский и серверный процессы.

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

— Интернет/Интранет – комплексное объединение технологий Интернет/Интранет и многоуровневой архитектуры. Инструментальные средства дополняются развитыми средствами разработки приложений, работающих с базами данных.

Применительно к организации обычно используют понятие корпоративная архитектура (enterprise architecture), при этом выделяются следующие типы архитектур: бизнес-архитектура (Business architecture), ИТ-архитектура (Information Technology Architecture), архитектура данных (Data Architecture), архитектура приложения (Application Architecture) или программная архитектура (Software Architecture), техническая архитектура (Hardware Architecture). Совокупность данных архитектур и является архитектурой ИС (рис. 18.1).

Рис. 18.1. Архитектура информационной системы

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

ИТ-архитектура рассматривается в трех аспектах:

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

— среда, обеспечивающая реализацию бизнес- приложений;

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

Читать еще:  Современную архитектуру эвм предложил

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

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

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

Доменную архитектуру можно рассматривать как метамодель, описывающую множество решений.

Схемы классификации архитектур ИС, основанные на доменном подходе, показаны на рис. 1.2 и 1.3. На верхнем уровне выделяются два типа доменов: домены задач (Problem domains) (рис. 18.2) и домены решений (Solution Domains) (рис. 18.3).

Рис. 18.2. Классификация архитектур ИС, основанная на домене задач

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

Рис. 18.3. Классификация архитектур ИС, основанная на домене решений

В таблице 18.2 приведены требования, предъявляемые к отдельным характеристикам рассматриваемых типов ИС.

Архитектура предприятия: основные определения

Второй постулат заключается в том, что выделяются два понятия:

  • собственно архитектура информационной системы – как объективная реальность, включающая существующие компоненты и их связи;
  • описание архитектуры (architecture description) – отражение объективной или планируемой реальности в какой-либо документированной форме.

Взаимосвязь этих понятий иллюстрируется на рисунке 3.5.

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

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

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

Еще одно формальное определение приведено в стандарте IEEE 1471 Института инженеров-электриков и электронщиков, который предоставляет метамодель для определения архитектуры. Этот стандарт определяет такие абстрактные элементы архитектуры, как представления, системы, среды, обоснования, заинтересованные стороны и т.д. в соответствии со схемой, показанной на рис. 3.6.

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

Однако этот стандарт не определяет структуру собственно архитектуры предприятия. Например, говорится о том, что необходимо иметь различные представления архитектуры , но при этом не указывается, какие это должны быть представления. Подробную информацию об этом стандарте описания архитектуры можно получить по адресу http://www.enterprise-architecture.info/Images/Documents/IEEE%201471-2000.pdf.

Возвращаясь к предмету нашего обсуждения, можно рассмотреть различные аспекты понятия архитектуры ИТ. В частности, можно выделять такие подмножества, как системная архитектура ( архитектура систем – System Architecture ) и программная архитектура ( архитектура программного обеспечения – Software Architecture ). Вспомним, что мы уже отмечали неоднозначность трактовки терминов. На практике, в зависимости от контекста, термин «системная архитектура » может относиться либо к архитектуре ИТ-системы предприятия (в дополнение к бизнес-архитектуре) или даже в еще более узком смысле к технологической инфраструктуре информационной системы, либо – к архитектуре сложного продукта или семейства продуктов, выпускаемых предприятием.

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

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

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

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

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

Архитектура СУБД. Архитектура баз данных. Логическая структура СУБД. Описание данных в базе данных. Базы данных схема данных

  • 08.12.2012
  • Базы данных
  • 2 комментария

Здравствуйте, уважаемые посетители моего скромного блога для начинающих вебразработчиков и web мастеров ZametkiNaPolyah.ru. Продолжаем рубрику Заметки о MySQL, в которой уже были публикации: Нормальные формы и транзитивная зависимость, избыточность данных в базе данных, типы и виды баз данных, настройка MySQL сервера и файл my.ini, MySQL сервер, установка и настройка. Сегодня мы поговорим о логической структуре СУБД и архитектуре баз данных. Как всегда, я постараюсь описать архитектуру СУБД на простом и понятном языке, без всяких сложных и умных слов.

Читать еще:  Проектирование памятников архитектуры

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

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

Число уровней описания зависит от реализации сервера баз данных или от реализации СУБД. Существует одноуровневая система управления базами данных. Двух уровневая СУБД и трехуровневая СУБД. Рассматривать одноуровневые и двухуровневые СУБД нет смысла, поскольку в настоящее время используются в основном трехуровневые системы. Системы с трехуровневым описанием данных имеют три уровня абстракции, на которых можно осуществляется взаимодействие с базой данных. И так, перейдем к делу.

Трехуровневая архитектура баз данных. Три уровня абстракции описания данных.

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

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

Для наглядности можете посмотреть на рисунок, на нем продемонстрирована структура трехуровневой СУБД:

Структура базы данных

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

Базы данных. Схема данных. Независимость уровней от данных.

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

Каждая схема данных имеет свое собственное название и зависит от уровня. На самом высоком или внешнем уровне имеется несколько внешних схем данных или подсхем. На концептуальном уровне описание базы данных происходит при помощи концептуальных схем. Внутренний уровень СУБД описывается при помощи внутренней схемы данных.

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

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

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

Внешний уровень абстракции. Внешняя схема данных. Внешнее представление базы данных.

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

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

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

Концептуальная схема данных. Концептуальное представление базы данных.

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

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

  1. Таблицы и их атрибуты
  2. Связи между таблицами
  3. Ограничения, накладываемые на данные
  4. Семантику данных
  5. В концептуальной схеме данных должны быть учтены аспекты безопасности и целостности данных

Внутренний уровень абстракции. Внешняя схема данных. Внутреннее представление базы данных.

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

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

Любая внутренняя схема данных обязательно хранит в себе:

  • То, как должно быть распределено дисковое пространство для хранения данных и индексы
  • Информацию о сохраненных записях
  • Сведения о уже имеющихся записях
  • Сведения о способах шифрования и сжатия данных

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

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

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

Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector
×
×