baza 2

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

АРХИТЕКТУРА БАЗ
ДАННЫХ
Лк. 2
Кузнецова Виктория Борисовна

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

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

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

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

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

Самым важным аспектом трехуровневой архитектуры базы
данных является то, что логическая структура, с которой
взаимодействует пользователь, отделена от физической
структуры баз данных, с которой взаимодействует машина.
Например: 1. Изменения интерфейса для пользователя не
приводит к изменению БД,
Или 2) вероятность нарушения целостности данных=>к 0 – т.к. у
пользователя НЕТ прав доступа к физической среде.
■ Трем основным уровням моделирования системы —
логическому, концептуальному и физическому
соответствуют три последовательных этапа детализации описания
объектов БД и их взаимосвязей.

5. Проектирование БД

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

6. Логическая модель(внешний уровень)

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

7. Логическая модель(внешний уровень)

■ Внешний уровень состоит из нескольких внешних представлений
Баз Данных. Каждый пользователь имеет дело с представлением
«реального мира», выраженным в наиболее удобной для него
форме. Внешнее представление содержит только те сущности,
атрибуты и связи, которые интересны пользователю. Другие
сущности, атрибуты и связи, которые ему неинтересны, также могут
быть представлены в БД, но пользователь может даже не
подозревать об их существовании.
Например, система распределения работ использует сведения о
квалификации сотрудника, но ее не интересуют сведения об окладе,
домашнем адресе и телефоне сотрудника, и наоборот, именно эти
сведения используются в подсистеме отдела кадров.

8. Логическая модель(внешний уровень)

Например, система распределения работ использует сведения о
квалификации сотрудника, но ее не интересуют сведения об окладе,
домашнем адресе и телефоне сотрудника, и наоборот, именно эти
сведения используются в подсистеме отдела кадров.
1 внешняя модель для ОК
2 внешняя модель для Бухгалтерии
3 внешняя модель для менеджмента
1 внешняя модель для студента
2 внешняя модель для преподавателя
3 внешняя модель для деканата, ректората

9. Логическая модель

■ В соответствии с терминологией ANSI/SPARC, представление
отдельного пользователя называется внешним представлением —
это содержимое базы данных, каким его видит определенный
пользователь. Каждое внешнее представление определяется
посредством внешней схемы, которая в основном состоит из
определений записей каждого из типов, присутствующих в этом
внешнем представлении
■ На логическом уровне производится отображение данных концептуальной модели в логическую модель в рамках той структуры
данных, которая поддерживается выбранной СУБД. Логическая модель не зависит от конкретной СУБД и может быть реализована на
любой СУБД реляционного типа.

10. Концептуальный уровень

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

11. Концептуальный уровень

На концептуальном уровне представлены следующие компоненты:
■ Все сущности, их атрибуты и связи;
■ Ограничения, накладываемые на данные ;
■ Семантическая информация о данных (связанная со значением,
смысловая зависимость всех сущностей и атрибутов);
■ Информация о мерах обеспечения безопасности и поддержки
целостности данных (н-р: независимость физического и внешнего уровня)
■ Концептуальный уровень поддерживает каждое внешнее представление,
в том смысле, что любые доступные пользователю данные должны
содержаться (или могут быть вычислены) на этом уровне. Однако этот
уровень не содержит никаких сведений о методах хранения данных. (ТЗ)

12. Внутренний уровень (физический)

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

13. Внутренняя модель (физическая)

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

14. Внутренний уровень

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

15. Независимость при работе с данными

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

16. ТРЕХ УРЕВНЕВАЯ АРХИТЕКТУРА

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

17.

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

18.

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

19. ВЫБИРАЕМ СУБД

Рейтинг систем управления базами данных (СУБД) 2019
Cоздание, ведение и использование баз данных

20. ВЫБИРАЕМ СУБД. ORACLE

Oracle выпустила свою первую реляционную
СУБД в 1979-м году. За годы присутствия
компании на рынке слово «Oracle» стало
синонимом понятий «корпоративная СУБД» и
«надёжная работа с данными». Oracle, как, и
некоторые другие компании, разработки которых
присутствуют в нашем обзоре, входит в список
Fortune
50\500.
Главное
направление
деятельности Oracle – мощное и довольно
сложное решение в области баз данных.
Текущая версия СУБД компании называется
Oracle 18c. Буква «c» означает «cloud». Это
отражает движение Oracle в сторону облачных
технологий, которые позволяют организациям
консолидировать базы данных и управлять ими
как облачными службами. Среди особенностей
СУБД Oracle – многоарендная архитектура,
быстрое развёртывание решений, возможности

21. ВЫБИРАЕМ СУБД. MS SQL SERVER

О Microsoft можно говорить всё, что угодно, но это
– одна из самых прибыльных технологических
компаний в мире. Её настольные операционные
системы
буквально
повсюду,
однако,
не
последнюю роль в успехе Microsoft сыграл SQL
Server. Трудно представить себе сервер, на
котором установлена ОС от Microsoft, без SQL
Server.
Простота
использования
SQL
Server,
его
доступность и тесная интеграция с ОС семейства
Windows, делают его очевидным выбором для
компаний, пользующихся продуктами Microsoft
для корпоративных целей. Microsoft говорит о
свежем выпуске SQL Server 2020 как о платформе
для локальных и облачных баз данных, а так же
для систем бизнес-аналитики. На базе SQL Server

22. ВЫБИРАЕМ СУБД. MS SQL SERVER

Кроме того, Microsoft занимается продвижением SQL Server как
решения, способного помочь организациям в построении критически
важных приложений для оперативной обработки транзакций (OLTP).
Такие решения характеризуются высокой производительностью,
возможностями по обработке данных в памяти и по защите данных
при их хранении и перемещении. На базе SQL Server
можно
создавать хранилища большого объема, системы анализа данных.
Есть различные варианты аренды MS SQL Server. Можно
приобрести лицензию на одного пользователя, можно лицензировать
ядра сервера, без ограничения количества пользователей.
Можно также скачать бесплатный выпуск начального уровня SQL
Server 2016 Express, который оптимально подходит для развертывания
небольших баз данных в рабочих средах и установить его на
недорогой VPS, этого вполне достаточно для создания небольших
серверных приложений для обработки данных, занимающих до 10 ГБ
места на диске.

23. ВЫБИРАЕМ СУБД. POSTGRE SQL

PostgreSQL, наследник Postgres,
разработка которой началась в 1986-м
году, – это бесплатная объектнореляционная
СУБД
с
открытым
исходным
кодом.
Она
находит
применение в весьма интересных
местах, как интернет-казино, системы
автоматизации дата-центров, реестры
доменов. Кроме того, её используют в
высоконагруженных задачах Yahoo! и
Skype. PostgreSQL можно обнаружить в
таком
количестве
скрытых
от
постороннего взгляда систем, что она
вполне может называться «Секретной
корпоративной базой данных».

24. ВЫБИРАЕМ СУБД. POSTGRE SQL

Текущий стабильный релиз PostgreSQL – 10.6. Он
выпущен 2018 г.
PostgreSQL
поддерживает
множество
операционных систем. Среди них – Linux, Windows,
FreeBSD,
Solaris.
PostgreSQL
используется
как
стандартная база данных в ОС от Apple, начиная с Mac
OS X Lion.
Возможности этой СУБД сравнимы с разработками
Oracle и IBM. В частности, она характеризуется полным
соответствием требованиям ACID по надёжности
транзакций,
способна
поддерживать
высокие

25. ВЫБИРАЕМ СУБД. MARIADB ENTERPRISE

MariaDB Enterprise – это
СУБД с полностью открытым
исходным кодом, выпущенным
под лицензиями GPL, LGPL или
BSD. Путь MariaDB начался в
2009-м году. Эта система была
форком MySQL, над которым
работало
сообщество
разработчиков
под
руководством
создателей
MySQL. Они начали новый
проект,
обеспокоенные
политикой
лицензирования
Oracle, которая приобрела
MySQL.

26. ВЫБИРАЕМ СУБД. MARIADB ENTERPRISE

Популярной MariaDB стала за счёт MySQL. В частности, после
того, как MariaDB заняла место MySQL в известных дистрибутивах
Linux. Так, только в 2013 году, разработчики Red Hat Enterprise Linux
отказались от MySQL в пользу MariaDB, то же самое было сделано
в Fedora 19, на MariaDB перешли openSUSE и Slackware Linux. Кроме
того, MariaDB стала использоваться в качестве серверной базы
данных в проекте Wikipedia.
Ещё один важнейший фактор, повлиявший на то, что MariaDB
оказалась впереди MySQL, заключается в наличии расширенного
оптимизатора запросов и других улучшений, касающихся скорости
работы.
Самый свежий релиз MariaDB Enterprise Server – 10.3,
известный так же как MariaDB Enterprise Spring 2018. Этот выпуск
улучшает защиту данных от атак на уровне приложений и сетей и
способствует
разработке
новых,
высокопроизводительных

27. ВЫБИРАЕМ СУБД. MySQL

MySQL
начинала
как
узкоспециализированное решение
для разработчиков, но выросла в
одного из ключевых игроков рынка
корпоративных СУБД.
Сначала, в 2008-м, она была
продана Sun Microsystems, позже, в
2009-м, стала частью империи
Oracle. Уже много лет MySQL – это
нечто гораздо большее, нежели
нишевое решение. На MySQL
работают
сотни
тысяч
коммерческих
веб-сайтов,
она
служит в качестве серверной СУБД
для
огромного
количества

28. ВЫБИРАЕМ СУБД. MySQL

Сегодня MySQL остаётся весьма популярным
вариантом для веб-решений, она продолжает
служить центральным компонентом стека LAMP. В
то же самое время, MySQL, из-за поглощения
Oracle, испытывает ослабление поддержки со
стороны
пользователей
и
независимых
разработчиков.
Падение популярности MySQL позволило
ускорить адаптацию других СУБД с открытым
исходным кодом и её собственных форков,
наподобие Percona или вышеупомянутой MariaDB
с полностью открытым исходным кодом, в которой

29. ВЫБИРАЕМ СУБД. ИТОГИ

ИТОГИ
Нет единственно правильного решения
для всех задач по работе с данными. Не
существует и идеальной корпоративной
СУБД. У каждой из них есть свои плюсы и
минусы, которые, к тому же, очень сильно
зависят от специфики бизнеса.
Лучшее, что можно сделать для того,
чтобы
выбрать
подходящую
СУБД
–
проанализировать всё, что предлагает рынок,
с
учётом
особенностей
конкретной
ВЫБИРАЕМ СУБД.