Remkomplekty.ru

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

Архитектура базы данных это

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение в базы данных. Базы данных, системы управления базами данных, банки данных. Организация баз данных: иерархическая, сетевая, реляционная и объектная.

База данных – это некоторый набор перманентных (постоянных) данных, используемых прикладными системами какого-либо предприятия [Ошибка! Источник ссылки не найден.].

База данных – это средство для рационального и эффективного хранения информации [Ошибка! Источник ссылки не найден.].

База данных – это самодокументированное собрание интегрированных записей [Ошибка! Источник ссылки не найден.]. База данных является самодокументированной, так как она содержит в дополнение к исходным данным пользователя, описание собственной структуры.

Читать еще:  Что такое архитектура системы

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

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

· пользователь формирует запрос на доступ к данным, применяя определенный язык манипулирования данными (обычно это SQL);

· СУБД получает этот запрос и анализирует его;

· СУБД выполняет необходимые операции в хранимой базе данных;

· СУБД возвращает приложению данные, удовлетворяющие поставленному запросу.

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

По характеру использования СУБД разделяют на:

Персональная СУБД обеспечивает возможность создания локальных БД, работающих на одном компьютере. К персональным СУБД относятся Рагаdох, dBase, FохРго, Ассеss (ранних версий) и др.

Многопользовательские СУБД позволяют создавать информационные системы, функционирующие в архитектуре «клиент-сервер». К многопользовательским СУБД относятся Огас1е, Informiх, SyBase, Мiсгоsoft SQL Server, InterBasе и другие.

В состав языковых средств современных СУБД входят:

· язык описания данных, предназначенный для описания логической структуры данных (DDL Data Definition Language);

· язык манипулирования данными, обеспечивающий выполнение основных операций над данными – ввод, модификацию и выборку (DML Data Manipulation Language);

· язык структурированных запросов (SQL Structured Query Language), обеспечивающий управление структурой БД и манипулирование данными, а также являющийся стандартным средством доступа к удаленным БД;

· язык запросов по образцу (QВЕ – Query Ву Ехаmp1е), обеспечивающий визуальное конструирование запросов к БД.

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

· манипулирование данными (хранение, извлечение и обновление);

· сервис (поддержание целостности, справочные функции, восстановление базы).

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

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

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

В зависимости от организации данных различают следующие основные модели представления данных в БД:

В иерархической модели данные представляются в виде древовидной (иерархической) структуры (рис.3.2).

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

В сетевой модели данные организуются в виде произвольного графа (рис.3.3). Недостатком сетевой модели является жесткость структуры и высокая сложность организации.

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

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

Основные понятия и определения

Современные авторы часто употребляют термины » банк данных » и » база данных » как синонимы, однако в общеотраслевых руководящих материалах по созданию банков данных Государственного комитета по науке и технике (ГКНТ), изданных в 1982 г., эти понятия различаются. Там приводятся следующие определения банка данных, базы данных и СУБД :

Банк данных (БнД) — это система специальным образом организованных данных — баз данных, программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных.

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

Система управления базами данных ( СУБД ) — совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрим их более подробно.

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

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

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

Архитектура БД. Модели данных, используемые на различных этапах проектирования БД.

Основной целью любой СУБД является возможность предложить обычному пользователю базы данных абстрактное представление данных, скрыв от пользователя особенности хранения и управления ими. Поскольку база данных, как правило, разрабатывается как общий ресурс для большого количества пользователей, то каждому пользователю может потребоваться своё, отличное от других пользователей представление о данных, хранимых в БД. Это вызвано следующими причинами:
— каждый пользователь иметь право обращаться к общим данным, используя своё представление о них;
— взаимодействие пользователя с БД не должно зависеть от особенностей её физической организации;
— администратор базы данных (АБД) должен иметь возможность изменять структуру и формат данных, не оказывая влияния на пользовательские представления;
— внутренняя структура БД не должна зависеть от таких изменений физических аспектов хранения информации, как переключение на новое устройство хранения;
— АБД должен иметь возможность изменять концептуальную или глобальную структуру данных без какого—либо влияния на всех пользователей.
Для удовлетворения этих потребностей архитектура большинства современных коммерческих СУБД, существующих на рынке программного обеспечения, в той или иной мере, строится на базе так называемой архитектуры ANSI—SPARC. Название произошло по названию комитета планирования стандартов и норм (Standards Planning and Requirements Committee SPARC) национального института стандартизации (American National Standard Institute— ANSI) США. Комитет признал необходимость использования трехуровневого подхода к организации БД. Этот подход отделяет пользовательские представления базы данных от её физического представления посредством создания независимого уровня, изолирующего программы от особенностей представления данных на низком уровне.
Архитектура БД представлена на рисунке 1.
Внешний уровень – это индивидуальное представление БД с точки зрения отдельного пользователей. Пользователи могут быть разные, с разным уровнем подготовки. Каждый пользователь представляет данные в соответствии с формами различных документов, присущих данной предметной области. При этом одни и те же данные могут иметь различную форму представления — формат (тип), длину. Например, сведения о зарплате – их можно увидеть в виде итоговой суммы в записи ведомости, либо в виде перечня составляющих – различных начислений и удержаний.

ПП1 – представление 1—го пользователя, ППк – представление к—того пользователя

Рисунок 1 — Трехуровневая архитектура БД

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

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

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

Различают логическую и физическую независимость данных.

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

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

Модели данных

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

Читать еще:  Не открываются несколько документов excel в linux

В современной трактовке термин «модель данных» обозначает инструмент моделирования. Модель базы данных (схема данных) или модель предметной области являются результатами моделирования.

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

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

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

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

Модели данных, как инструменты, делятся на 3 основные категории:

1. Объектные модели данных. В этих моделях используются такие понятия как: классы объектов (типы сущностей), объекты (экземпляры сущностей), свойства классов объектов (атрибуты сущностей), связи между классами объектов. В скобках приведена исторически ранняя терминология, используемая в теории баз данных.
Среди объектных моделей выделяют наиболее общие типы:
— семантические модели. Их назначение – обеспечение возможности выражения семантики (смыла) предметной области. Это, например, модели типа «сущность—связь» (ER—модели — Entity Relationship model), отображающие семантику предметной области в виде ER—диаграмм;
— функциональные модели, дающие представление о функциях автоматизируемого предприятия, о распределении ответственности за их выполнение. Результаты использования функциональных моделей могут быть представлены в виде диаграмм бизнес—функций, диаграмм потоков данных;
—объектно—ориентированные модели. Эти модели расширяет определение класса объектов (сущности) предметной области с целью включения в определение не только свойств, описывающих состояние объекта, но и действий, которые с ним связаны, т.е. его поведение. Это, например, модели, основанные на использовании языка UML (Unified Modeling Language — унифицированного языка моделирования). Описание предметной области получают в виде различных диаграмм — диаграмм вариантов использования, диаграмм деятельности, диаграмм классов.
В настоящее время для проектирования БД, получения концептуальной инфологической модели предметной области, широко используются семантические модели «сущность—связь».
2. Модели на основе физических записей. Такие модели позволяют описывать логическую структуру БД в виде записей, фиксированного формата. Каждый тип записи определяет фиксированное количество полей, каждое из которых имеет фиксированную длину. Существует три основных типа логических моделей данных на основе записей:
— иерархическая (hierarchical data model);
— сетевая (network data model);
— реляционная (relational data model).
3. Физические модели данных. Модель содержит всю информацию, необходимую для реализации конкретной БД в среде выбранной (целевой) СУБД. В физической модели в виде описания содержится информация обо всех объектах БД. В описании объектов БД определяется физический формат данных, реализуются ограничения предметной области, бизнес—логика автоматизируемого предприятия, уровни доступа пользователей. Описание создается на языке определения данных (ЯОД) выбранной (целевой) СУБД. В состав ЯОД входят операторы, позволяющие создать или удалить объект БД, модифицировать его структуру. Физическая модель данных не затрагивает вопросы физического размещения данных на машинных носителях, в настоящее время это максимально реализуется средствами СУБД.
Модели первых двух групп используются для формирования концептуального уровня архитектуры БД, третьей – для описания БД на внутреннем уровне.
Модель данных, полученная в результате проектирования, должна представлять автоматизируемое предприятие в таком виде, который позволит проектировщикам и пользователям БД обмениваться конкретными недвусмысленными мнениями.

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

В таблице 1 представлены модель, которые будем использовать при проектировании базы данных

Таблица 1 — Модели данных

Модель данных, как инструмент, используемый для формирования схемы БД

Архитектура системы баз данных

Главная » Все дисциплины » Информатика » Архитектура системы баз данных

Архитектура системы баз данных. Под архитектурой системы понимают совокупность ее основных функциональных компонентов, а также средств обеспечения их взаимодействия друг с другом пользователями и системным персоналом. Одно из наиболее важных функций систем баз данных, оказавших решающее влияние на формирование сложившегося в наши дни подхода к архитектуре является обеспечение возможностей абстракции данных. Абстракции данных, предоставляемые системой служат средством поддержки независимости способ ведения БД различными группами пользователей (это свойство системы называется независимостью данных). В системах обычно имеют дело с уровнями абстракции и часто эти уровни выстраиваются в некоторую иерархию. Функциональны компонент системы, механизмы которого служат для поддержки некоторого уровня абстракции называется архитектурным уровнем. В результате простейшего анализа в системе можно выделить 2 основных уровня абстракции: логический и физический. Понятно, что введение каждого дополнительного уровня существенно усложняет реализации и эксплуатацию системы и снижает ее производительность, но часто дополнительные уровни необходимы что бы обеспечить:
1. адекватные способы видения системы для различных групп персонала
2. создать инструментарий, удовлетворяющий потребностям пользователей
3. представить систему в привычных для конкретной группы пользователей терминов
4. изменять некоторые характеристики системы, не затрагивая других.

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

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

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

Типичная алгоритм управления в управлениях данной схемы:
1. Пользователь выдает запрос на доступ, используя конкретный подъязык данных.
2. СУБД воспринимает запрос и интерпретирует его
3. СУБД обследует по очереди внешнюю схему, отображение внешне-концепутальное, концепутальную схему, отображение концептуально-внутреннее и определяет структуру хранения
4. СУБД выполняет необходимые операции над хранимой БД

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

Ссылка на основную публикацию
Adblock
detector