Foreversoft.ru

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

По архитектуре базы данных делятся на

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 3.1 – Концепция работы СУБД

Многопользовательские СУБД позволяют создавать информационные системы, функционирующие в архитектуре «клиент-сервер». К многопользовательским СУБД относятся Огас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.2 – Иерархическая модель БД

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

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

Рисунок 3.3 – Сетевая модель БД

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

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

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

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

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

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

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

Читать еще:  Установка linux ubuntu рядом с windows 7

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читать еще:  Список ошибок visual studio

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

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

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

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

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

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

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

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

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

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

Классификация БД и СУБД

Цель лекции: Ознакомиться с комплексом основных понятий классификации БД и СУБД . Ознакомиться с функциями и функциональными возможностями СУБД .

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

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

Классификация баз данных

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

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

По технологии обработки данных БД делятся на централизованные БД и распределённые БД.

Централизованная БД хранится в памяти одной вычислительной системы (применяется в локальных сетях ПК).

Централизованные БД могут быть с сетевым доступом.

Архитектуры систем централизованных БД с сетевым доступом подразделяются на файл-сервер и клиент- сервер .

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

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

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

Распределённая БД состоит из нескольких частей, хранимых в различных ЭВМ вычислительной сети (работа с такой БД происходит с помощью СУБД ).

По способу доступа к данным БД разделяются на БД с локальным и удаленным доступом.

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

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

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

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

В качестве технических средств могут выступать супер- или персональные компьютеры с соответствующими периферийными устройствами.

Классификация СУБД

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

Системы управления базами данных следует классифицировать отдельно ( рис. 2.4).

Состав СУБД и работа БД

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

Базовыми внутренними языками программирования являются языки четвертого поколения. В качестве базовых языков могут использоваться C, C++, Pascal , Object Pascal . Язык C++ позволяет строить программы на языке Visual Basic с широким спектром возможностей, более близком и понятном даже пользователю-непрофессионалу, и на непроцедурном ( декларативном) языке структурированных запросов SQL . Следует отметить, что исторически для системы управления базой данных сложились три языка:

  1. язык описания данных (ЯОД), называемый также языком описания схем, — для построения структуры («шапки») таблиц БД;
  2. язык манипулирования данными (ЯМД) — для заполнения БД данными и операций обновления (запись, удаление, модификация);
  3. язык запросов — язык поиска наборов величин в файле в соответствии с заданной совокупностью критериев поиска и выдачи затребованных данных без изменения содержимого файлов и БД (язык преобразования критериев в систему команд).

В настоящее время функции всех трех языков выполняет язык SQL , относящийся к классу языков, базирующихся на исчислении кортежей ( кортеж чаще всего является единицей информации), языки СУБД FoxPro, Visual Basic for Application ( СУБД Access) и т.д.

Вместе с тем сохранились и языки запросов , например язык запросов по примеру Query By Example ( QBE ) класса исчисления доменов . Отметим, что эти языки в качестве «информационной единицы» БД используют отдельную запись . С помощью языков БД создаются приложения, базы данных и интерфейс пользователя, включающий экранные формы , меню , отчеты. При создании БД на базе СУБД FoxPro эти элементы (объекты) фиксируются в отдельных файлах, которые, в свою очередь , сосредоточиваются в одном файле, называемом проектом. После отработки БД проект преобразуется в приложение . В СУБД Access все созданные объекты размещаются в одном файле.

Архитектура базы данных: унификация (на примере ERP)


Есть концепции работы с базой, основанные на ORM, CodeFirst со своими преимуществами и недостатками. Предлагаемая здесь унификация базы основана в первую очередь на подходе Database First.

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

Пример проектирования документов:

  • Общие свойства всех документов размещаем в отдельной таблице.
  • На каждый тип документов с собственными, специфичными полями создается отдельная таблица, которая
    приджойнивается к общей таблице. Для сокращения количества полей-индексов FK к общей таблице делаем PK. При показе списка документов мы отображаем только общие поля из базовой таблицы, а при показе конкретного документа уже используем join, поэтому производительность не страдает.
  • Функционально однотипные поля документов (особенно если они различаются для разных типов документов) выносим в отдельные общие таблицы. Это
    • ссылки на контрагентов (например суд, заявитель жалобы, заинтересованное лицо, третье лицо для документа «Отзыв на жалобу»).
    • ссылки на людей, играющих в документе определенные роли (автор, получатель, исполнитель,
      согласующий, ответственный, делопроизводитель, руководитель).
    • ссылки на другие документы (основание, командировочный документ, ссылка на договор, счет, протокол разногласий, контракт).

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

  • Далее- каждая подсистема ERP (бюджетирование, логистика, СЭД, склады, CRM, ..) имеет свои документы с теми же самыми общими свойствами. Необходимо иметь возможность вывести список всех документов для одной подсистемы и список всех постоянных атрибутов (состояний, типов, папок) документов для одной подсистемы.
    Создаем enum module, характеризующий подсистему

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

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

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