и
IT 12.08.2020

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

16 мин.

Краткое описание

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

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

Что это?

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

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

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

архитектура систем управления базами данных

Особенности профессии

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

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

  • опыт аналитической работы 2-3 года;
  • умение выбирать технологии для хранения данных и их обработки;
  • опыт проектирования БД для предприятия (не менее 5 лет);
  • оптимизация БД, имеющейся в наличии;
  • оптимизация и контроль производительности созданного продукта;
  • работа с СУБД;
  • подбор технических специалистов для реализации проекта;
  • экспертная оценка БД;
  • оптимизация SQL-запросов;
  • анализ и оценка производительности;
  • разработка серверной логики;
  • составление ТЗ для группы разработчиков;
  • обеспечение безопасности;
  • разработка высоконагруженных БД, администрирование;
  • обучение системных администраторов;
  • создание проектной документации для БД;
  • написание триггеров, хранимых процедур и других.

Главные задачи — разработка понятной и красивой БД, которая будет отвечать бизнес-требованиям заказчика, формирование ТЗ для рабочей группы, аналитика. Архитектор БД взаимодействует с техническими и IT-специалистами, с которыми он постоянно обменивается информацией. Мнение этого сотрудника важно, поэтому он вносит проектные предложения, принимает участие в совещаниях.

Плюсы и минусы профессии

Плюсы

  1. Уникальность профессии.
  2. Можно быстро найти работу внутри страны или за рубежом.
  3. Хорошие условия труда (бесплатное питание, социальный пакет, благоустроенный кабинет).
  4. Интересная и высокооплачиваемая работа.
  5. Взаимодействие с другими опытными специалистами, которые передают специалисту свой опыт.
  6. Хорошие карьерные перспективы.

Минусы

  1. Должностные обязанности определены нечетко, что влечет за собой дополнительную нагрузку.
  2. Рабочий день ненормированный.
  3. Много требований к кандидату на вакансию.
  4. Невозможно получить образование в странах СНГ.
  5. Необходимо долго работать, чтобы занять должность архитектора БД.
  6. Мало информации о профессии, минимальное количество обучающих материалов.

Архитектура базы данных. Физическая и логическая независимость

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

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

Трехуровневая модель системы управления базой данных, предложенная ANSI
 Трехуровневая модель системы управления базой данных, предложенная ANSI

  1. Уровень внешних моделей — самый верхний уровень, где каждая модель имеет свое “видение” данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению. Например, система распределения работ использует сведения о квалификации сотрудника, но ее не интересуют сведения об окладе, домашнем адресе и телефоне сотрудника, и наоборот, именно эти сведения используются в подсистеме отдела кадров.
  2. Концептуальный уровень — центральное управляющее звено, здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов реального мира.
  3. Физический уровень — собственно данные, расположенные в файлах или в страничных структурах, расположенных на внешних носителях информации.

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

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

Процесс прохождения пользовательского запроса

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

Схема прохождения запроса к БД
Схема прохождения запроса к БД

  1. Пользователь посылает СУБД запрос на получение данных из БД.
  2. Анализ прав пользователя и внешней модели данных, соответствующей данному пользователю, подтверждает или запрещает доступ данного пользователя к запрошенным данным.
  3. В случае запрета на доступ к данным СУБД сообщает пользователю об этом (стрелка 12) и прекращает дальнейший процесс обработки данных, в противном случае СУБД определяет часть концептуальной модели, которая затрагивается запросом пользователя.
  4. СУБД запрашивают информацию о части концептуальной модели.
  5. СУБД получает информацию о запрошенной части концептуальной модели.
  6. СУБД запрашивает информацию о местоположении данных на физическом уровне (файлы или физические адреса).
  7. В СУБД возвращается информация о местоположении данных в терминах операционной системы.
  8. СУБД вежливо просит операционную систему предоставить необходимые данные, используя средства операционной системы.
  9. Операционная система осуществляет перекачку информации из устройств хранения и пересылает ее в системный буфер.
  10. Операционная система оповещает СУБД об окончании пересылки.
  11. СУБД выбирает из доставленной информации, находящейся в системном буфере, только то, что нужно пользователю, и пересылает эти данные в рабочую область пользователя.

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

Всегда ли запрос проходит полный цикл? Конечно, нет. СУБД обладает достаточно развитым интеллектом, который позволяет ей не повторять бессмысленных действий. И поэтому, например, если этот же пользователь повторно обратится к СУБД с новым запросом, то для него уже не будут проверяться внешняя модель и права доступа, а если дальнейший анализ запроса покажет, что данные могут находиться в системном буфере, то СУБД осуществит только 11 и 12 шаги в обработке запроса.

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

Пользователи банков данных

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

  1. Проектирование.
  2. Реализация.
  3. Эксплуатация.
  4. Модернизация и развитие.
  5. Полная реорганизация.

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

Определим основные категории пользователей и их роль в функционировании банка данных:

  • Конечные пользователи.Это основная категория пользователей, в интересах которых и создается банк данных. В зависимости от особенностей создаваемого банка данных круг его конечных пользователей может существенно различаться. Это могут быть случайные пользователи, обращающиеся к БД время от времени за получением некоторой информации, а могут быть регулярные пользователи. В качестве случайных пользователей могут рассматриваться, например, возможные клиенты вашей фирмы, просматривающие каталог вашей продукции или услуг с обобщенным или подробным описанием того и другого. Регулярными пользователями могут быть ваши сотрудники, работающие со специально разработанными для них программами, которые обеспечивают автоматизацию их деятельности при выполнении своих должностных обязанностей. Например, менеджер, планирующий работу сервисного отдела компьютерной фирмы, имеет в своем распоряжении программу, которая помогает ему планировать и распределять текущие заказы, контролировать ход их выполнения, заказывать на складе необходимые комплектующие для новых заказов. Главный принцип состоит в том, что от конечных пользователей не должно требоваться каких-либо специальных знаний в области вычислительной техники и языковых средств.
  • Администраторы банка данных.Это группа пользователей, которая на начальной стадии разработки банка данных отвечает за его оптимальную организацию с точки зрения одновременной работы множества конечных пользователей, на стадии эксплуатации отвечает за корректность работы данного банка информации в многопользовательском режиме. На стадии развития и реорганизации эта группа пользователей отвечает за возможность корректной реорганизации банка без изменения или прекращения его текущей эксплуатации.
  • Разработчики и администраторы приложений.Это группа пользователей, которая функционирует во время проектирования, создания и реорганизации банка данных. Администраторы приложений координируют работу разработчиков при разработке конкретного приложения или группы приложений, объединенных в функциональную подсистему. Разработчики конкретных приложений работают с той частью информации из базы данных, которая требуется для конкретного приложения.

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

В составе группы администратора БД должны быть:

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

Общие принципы построения архитектурной модели

Построение архитектурной модели — архитектурный процесс — подчиняется определённым принципам. Важнейшие из них:

  • Принцип постепенной детализации. Следует начинать с взгляда на предприятие с большой высоты (перспектива «хозяин» в модели Захмана или архитектура бизнеса в модели TOGAF и др.), а не с подробного описания одной или нескольких нижележащих элементов. Это связано с тем, что, описывая какой-либо из нижележащих элементов общей модели предприятия, мы не получим единого системного взгляда на предприятие, которое призвана дать его архитектурная модель. По мере необходимости детализацию можно углублять, но это должно определяться тем, как будет использоваться архитектурная модель.
  • Принцип согласованности слоёв. В случае, если за основу взято наиболее популярное представление архитектуры предприятия как «слоёного пирога» (четыре уровня в модели TOGAF или «перспективы» в модели Захмана), необходимо добиваться согласованности слоёв. Ведь цель построения архитектурной модели — получить единую и взаимосвязанную картину предприятия. Поэтому не стоит описывать слои по отдельности, поручая эту работу различным подразделениям. Лучше выделить процесс, или, на первых порах — проект  — по описанию архитектуры предприятия, и создать единую команду.
  • Принцип независимости слоёв. Вместе с тем, слои (уровни, «перспективы») должны быть независимы. Возможно выделение любых необходимых слоёв или уровней (например, архитектура интеграции, определяющая принципы взаимодействия и интеграции приложений, данных и бизнес-процессов в распределённой среде компании в модели Frameworx (бывший NGOSS), или архитектура безопасности). Поэтому при их выделении применяют следующие условия:
    • в случае если нижний слой вышел из строя, верхний работать не может;
    • неработоспособность верхнего слоя не влияет на работоспособность нижнего;
    • работоспособность элементов внутри одного слоя может влиять на работоспособность других элементов этого же слоя, а может и не влиять.
  • Принцип полноты. Модель архитектуры предприятия должна описывать предприятие с требуемой полнотой. В то же время, не следует увлекаться большим количеством архитектур и уровней, так как это усложняет модель. Количество архитектур и уровней должно определяться конкретными задачами, для решения которых строится архитектурная модель.
  • Принцип непротиворечивости. Элементы архитектурной модели не должны противоречить друг другу.
  • Принцип отсутствия дублирования. Элементы архитектурной модели не должны дублировать друг друга.
  • Принцип постоянной трансформации текущей архитектуры предприятия. Не следует забывать, что любое предприятие находится в постоянном развитии. А значит, его архитектурная модель полезна только тогда, когда она актуальна и постоянно приводится в соответствие с реальным состоянием предприятия.

С чего начать?

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

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

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

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

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

Инструменты построения архитектурной модели

Традиционно для моделирования архитектуры предприятия использовали методы описания бизнес-процессов. Например, семейство языков моделирования IDEF (Integrated Computer Automated Manufacturing Definition), которое возникло в середине 70-х годов в ВВС США, как решение проблемы повышения производительности и эффективности информационных технологий. Часть стандартов этого семейства может быть использована при построении моделей архитектуры бизнеса, архитектуры данных и прикладной архитектуры.

Язык, использованный в инструментах линейки ARIS (Architecture of Integrated Information Systems) также позволяет описывать бизнес-процессы. Кроме того, в эту линейку входит отдельное решение, которое называется Enterprise Architecture Management (Управление архитектурой предприятия) и предназначено для создания архитектурных моделей предприятия и поддержки их в актуальном состоянии.

BPML (Business Process Modeling Language) — язык моделирования бизнес-процессов был разработан для описания архитектуры Бизнеса. BPML представляет бизнес-процессы как комплекс взаимодействий управляющих потоков, потоков данных и потоков событий и средств моделирования бизнес-правил, ролей их взаимодействий. Существует много программных систем, которые предоставляют возможность описания архитектуры бизнеса на этом языке, в частности, Popkin System Architect.

Язык UML подходит для описания всех слоёв архитектуры предприятия. Эту нотацию поддерживают многие инструментальные средства от ARIS до Microsoft Visio и Rational Rose. 

В 2008 г. консорциум Open Group приобрёл права на развитие языка описания архитектуры предприятия Archimate, который разрабатывался в Нидерландах по заказу голландского правительства, ряда государственных и крупных частных компаний, а также образовательных организаций. Первая версия международного стандарта появилась в 2009 г., стандарт постоянно развивается, с июня 2016 г. актуальна его третья версия. Archimate полностью совместим с TOGAF. Так же, как и в TOGAF, в нем выделяются 4 уровня описания архитектуры предприятия: архитектура бизнеса, архитектура данных, архитектура программных приложения и технологическая архитектура.

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

Основу Archimate составляют три типа элементов:

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

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

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

ЗАКЛЮЧЕНИЕ

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

В среднем каждый из вендоров осуществляет продажи программного обеспечения на сумму от 7 до 15 млн. долларов в год (исключение составляет IDS Scheer: объявленный ею доход за 2002 г. составил 211 млн. долларов, он включает не только продажи ПО, но и консалтинг, обучение, выполнение проектов и т. п.).

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

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

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

Источники

  • https://www.profguide.io/professions/architect_database.html
  • https://FB.ru/article/402559/arhitektura-bazyi-dannyih-ponyatie-opredelenie-urovni
  • https://www.intuit.ru/studies/courses/1001/297/lecture/7401
  • https://zen.yandex.ru/media/id/5cc9e44c9680af00b2c7a2a1/arhitektura-predpriiatiia-i-itarhitektura-5cd8162c901a5900b23c8586
  • http://www.management.com.ua/ims/ims110.html
[свернуть]
Оцените статью
Понравилась статья?
Комментарии (0)
Комментариев нет, будьте первым кто его оставит

Комментарии закрыты.