Системой управления базой данных (СУБД) называется совокупность языковых и программных средств, предназначенных для создания на ЭВМ, ведения, поддержки БД и обеспечения доступа пользователей к ней.
СУБД представляет собой специальный пакет программ, с помощью которого реализуется централизованное управление базой данных и обеспечивается доступ к данным.
Для достижения максимально возможной независимости прикладных программ от данных из прикладных программ в СУБД были введены средства манипулирования данными на физическом уровне.
Именно СУБД обеспечивает независимость данных, а прикладная программа поддерживает логику каждой конкретной задачи. Схематично это представлено на рисунке 14.
Рис. 14. Схема взаимодействия СУБД с прикладными программами
Изменения организации данных воспринимаются СУБД и не влияют на прикладную программу. Изменения логики прикладной программы не требуют изменения механизма доступа к физическим данным.
Программные составляющие СУБД включают ядро и сервисные средства. Ядро — это набор программных модулей, необходимый и достаточный для создания и поддержания БД. Сервисные программы предоставляют пользователям ряд дополнительных возможностей по обслуживанию ИС. Назовем некоторые из них: форматирование файлов БД, т.е. подготовка внешней памяти к загрузке данных; копирование БД; ведение системного журнала и др.
1. Введение в базы данных. Базы данных.
Различают 2 класса СУБД:
· системы общего назначения;
СУБД общего назначения не ориентированы на какую-либо конкретную ПО и предлагаются многим пользователям как коммерческое изделие. СУБД общего назначения обладают свойствами настройки на работу с конкретной базой данных в соответствующих условиях. Использование таких СУБД для создания АИС позволяет существенно сокращать сроки разработки и экономить трудовые ресурсы.
Специальные СУБД разрабатывают для конкретного применения. Это требуется в некоторых случаях, когда СУБД общего назначения не позволяют добиться требуемой производительности или удовлетворить заданным ограничениям по объему памяти, предоставляемой для хранения БД. Решение этих проблем может оказаться возможным благодаря знанию специфических особенностей данного применения. Однако, создание специализированной СУБД очень сложное дело и к этому прибегают лишь в крайних случаях.
К функциям СУБД относятся:
· определение структуры БД, инициализация БД и начальная загрузка данных;
· управление ресурсами среды хранения;
· обеспечение логической независимости, т.е. предоставляет определенную свободу логического представления БД без необходимости соответствующей модификации физического представления;
· обеспечение физической независимости данных, т.е. предоставляет свободу организации БД в среде хранения, не вызывая изменений в логическом представлении;
· поддержка логической целостности (непротиворечивости) базы данных (в СУБД для ПЭВМ осуществляется только при вводе данных в БД);
· обеспечение физической целостности БД, т.е. защита и восстановление БД после различного рода сбоев;
1. Базы данных. Введение | Технострим
· управление доступом, т.е. разграничение доступа пользователей к БД, т.к. в ней могут храниться данные, которые должны быть доступны лишь ограниченному кругу пользователей. Может быть ограничена группа пользователей, которой разрешено обновлять те или иные данные. Это достигается введением паролей;
· организация параллельного доступа пользователей к БД.
Сегодня на рынке программного обеспечения можно встретить более 200 СУБД для ПЭВМ.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
Архитектурные шаблоны взаимодействия с базами данных
В первой статье мы рассмотрели шаблоны проектирования, применимые в программировании приложений. Однако сейчас сложно представить серьезное бизнес-приложение без базы данных. Большие объемы данных требуют хранения и обработки. И то насколько оптимально построена связь между уровнем прикладного кода и уровнем БД во многом зависит быстродействие системы в целом.
Поэтому важно правильно построить взаимодействие с СУБД. В этой статье мы рассмотрим шаблоны взаимодействия с базами данных. Правильно выбранный шаблон взаимодействия позволит избежать многих проблем при разработке и получить качественное приложение.
Различные подходы
За долгие годы существования приложений, взаимодействующих с СУБД, утвердились несколько подходов к работе с базами данных. Эти подходы отличаются тем, как осуществляется чтение и обработка данных, представленных в базах, работа со строками и таблицами.
Начнем с рассмотрения Object Relation Mapping – ORM, механизма взаимодействия, который представляет собой вспомогательную прослойку между приложением и базой данных, позволяющую реализовать механизмы представления и взаимодействия между БД и собственно кодом. Суть работы ORM заключается в следующем: мы представляем ряды из таблиц в качестве объектов, свойства которых будут соответствовать именам полей из таблиц, а значения этих свойств – значениям из базы данных. Таким образом мы получаем соответствие одна строка в БД – один объект.
На практике реализация ORM осуществляется с помощью шаблонов DAO, Active Record или DataMapper. Также возможно построение гибридов из нескольких шаблонов.
Познаем DAO
Начнем с рассмотрения шаблона DAO (Data Access Object). Как можно понять из названия, этот шаблон предназначен для доступа к данным. Он предоставляет абстрактный интерфейс для обращений к БД. Основная суть работы данного шаблона заключается в том, чтобы можно было выполнять определенные операции не сильно вдаваясь в детали реализации базы данных.
При использовании шаблона DAO функции для работы c конкретной таблицей хранятся в файле модели. Соответственно, данная модель наследует абстрактный класс, реализующий DAO. Когда будет получен ряд данных в DAO, в результирующем объекте или массиве будут содержаться все поля из БД.
Давайте посмотрим пример кода на Java. Допустим, мы собираемся создать объект Student, действующий как Модель. При этом StudentDao — это интерфейс объекта доступа к данным. А StudentDaoImpl — это конкретный класс, реализующий объектный интерфейс доступа к данным. Dao Pattern Demo, наш демонстрационный класс, который будет использовать StudentDao для демонстрации использования шаблона объекта.
Создаем основной объект.
public class Student < private String name; private int rollNo; Student(String name, int rollNo)< this.name = name; this.rollNo = rollNo; >public String getName() < return name; >public void setName(String name) < this.name = name; >public int getRollNo() < return rollNo; >public void setRollNo(int rollNo) < this.rollNo = rollNo; >>
Создаем интерфейс Java.
import java.util.List; public interface StudentDao < public ListgetAllStudents(); public Student getStudent(int rollNo); public void updateStudent(Student student); public void deleteStudent(Student student); >
Создаем класс для работы с этим интерфейсом.
Далее создадим демонстрационный класс для показа работы DAO.
public class DaoPatternDemo < public static void main(String[] args) < StudentDao studentDao = new StudentDaoImpl(); //print all students for (Student student : studentDao.getAllStudents()) < System.out.println(«Student: [RollNo : » + student.getRollNo() + «, Name : » + student.getName() + » ]»); >//update student Student student =studentDao.getAllStudents().get(0); student.setName(«Michael»); studentDao.updateStudent(student); //get the student studentDao.getStudent(0); System.out.println(«Student: [RollNo : » + student.getRollNo() + «, Name : » + student.getName() + » ]»); > >
И вот что мы получим в результате выполнения:
Student: [RollNo : 0, Name : Robert ]
Student: [RollNo : 1, Name : John ]
Student: Roll No 0, updated in the database
Student: [RollNo : 0, Name : Michael ]
Как видно, в результате работы шаблоны мы получаем массив значений. Для получения такого массива нам не требуются дополнительные классы, так как все методы уже реализованы в StudentDaoImpl.
Active Record
Теперь рассмотрим другой шаблон проектирования Active Record. Данный шаблон также отвечает за представление бизнес-логики и данных. Если у нас имеются объекты, требующие постоянного хранения в базе данных, то с помощью Active Record можно достаточно просто создавать и использовать эти объекты.
Основная идея шаблона Active Record заключается в том, чтобы позволить объекту инкапсулировать данные и операции с базой данных, которые вы можете выполнять с ним. То есть, мы передаем классу некоторый набор значений, который затем внутри этого класса будет преобразован в запрос SQL и выполнен. Такой подход позволяет нам не использовать запросы SQL напрямую. И кроме того, позволяет сделать код более безопасным, так как если нельзя выполнить любой запрос напрямую, то и выполнение SQL инъекций становится более затруднительным или даже невозможным.
Посмотрим простой пример:
В результате будет сформирован SQL запрос следующего вида:
insert into ChessPlayer (birthDate, firstName, lastName, version, id) values (?, ?, ?, ?, ?)
Останется только добавить значения для соответствующих переменных при обращении к данному классу.
Data Mapper
Шаблон Data Mapper — это слой доступа к данным, который предоставляет двунаправленную работу с данными между БД и хранением данных в памяти (например, на время выполнения кода. В его обязанности входит передача данных между объектами и базой данных и изоляция их друг от друга. Если мы получаем средство отображения данных, объекту в памяти совершенно не обязательно знать, существует база данных или нет.
В шаблоне Data Mapper имеется еще один слой или тип сущности такой как entityManager. Именно этот слой будет отвечать за перенос состояния модели в базу данных и обратно.
Посмотрим пример работы с Data Mapper. Пусть у нас есть класс student для определения атрибутов студентов, включая студенческий билет, имя и оценку. У нас есть интерфейс StudentDataMapper, в котором перечислены возможные варианты запросов к данным студентов. И класс StudentDataMapperImpl для выполнения действий с Students Data.
Как видно из кода, в нем приведены основные операции для работы с данными: создание, чтение, запись, обновление и удаление.
public final class App < private static final String STUDENT_STRING = «App.main(), student : «; public static void main(final String. args) < final var mapper = new StudentDataMapperImpl(); var student = new Student(1, «Adam», ‘A’); mapper.insert(student); LOGGER.debug(STUDENT_STRING + student + «, is inserted»); final var studentToBeFound = mapper.find(student.getStudentId()); LOGGER.debug(STUDENT_STRING + studentToBeFound + «, is searched»); student = new Student(student.getStudentId(), «AdamUpdated», ‘A’); mapper.update(student); LOGGER.debug(STUDENT_STRING + student + «, is updated»); LOGGER.debug(STUDENT_STRING + student + «, is going to be deleted»); mapper.delete(student); >99 private App() < >>
В данном случае, нам нужно беспокоиться только о бизнес-логике самого приложения. Нам не надо заботиться о том, как и где данные были сохранены.
Чем отличаются
Поговорим немного о том, чем эти шаблоны проектирования отличаются друг от друга. DAO и Active Record кажутся очень похожими, но на самом деле у них есть различия. DAO отвечает за сохранение отдельной сущности на вашем уровне данных. Active Record — это в определенной степени особый метод выполнения DAO, в котором класс, содержащий значения одной строки из таблицы, также отвечает за запросы, обновления, вставки и удаления в эту таблицу. Шаблон проектирования Active Record означает, что ваш объект имеет взаимно однозначное сопоставление с таблицей в вашей базе данных.
Преимуществом использования DAO является то, что легко определить другой формат работы с данными, например, переход от классической БД к облаку, без изменения базовой реализации, в то время как внешний интерфейс остается тем же, что не влияет на другие классы. Преимущество шаблона ActiveRecord это простота реализации.
Недостатком модели Active Record является нарушение принципа единой ответственности, согласно которому, доменный объект должен иметь только одну зону ответственности, то есть только свою бизнес-логику. И если мы используем этот объект для сохранения данных, у нас добавляется дополнительная зона ответственности. Соответственно, в случае внесения изменений в структуру БД нам придется вносить много изменений в код и заново все тестировать.
У Data Mapper для каждого объекта указана своя зона ответственности и здесь особых проблем при внесении изменений быть не должно. Из недостатков здесь стоит отметить сложность кода из-за того, что под управлением находится большее количество объектов, чем в других моделях.
Заключение
В этой статье мы рассмотрели три основные шаблона для работы с базами данных. В следующей статье речь пойдет о работе с микросервисами.
Приглашаю вас на бесплатный вебинар, в процессе которого мы составим дорожную карту для самостоятельного изучения архитектурных принципов и паттернов проектирования.
Источник: habr.com
Взаимодействие с базами данных
Преимущества работы с Базами данных для пользователей окупают затраты и издержки на его создание. Они заключаются в следующем: повышается производительность работы пользователей, достигается эффективное удовлетворение информационных потребностей; централизованное управление данными освобождает прикладных программистов от организации данных, обеспечивает независимость прикладных программ от данных; организация банка (базы) данных позволяет реализовать другие нерегламентированные запросы, приложения; снижаются затраты не только на создание и хранение данных, но и на поддержание их в актуальном динамичном состоянии; уменьшаются потоки данных, циркулирующих в системе, сокращается избыточность и дублирование.
Концепция баз данных — это не только идея интегрированного хранения данных, но и идея отделения описания данных от программ их обработки, интерфейс между которыми обеспечивается системой управления базами данных (СУБД). В основу ее разработки закладывают следующие принципы: единство структурно-информационной организации массивов; централизацию процессов накопления, хранения и обработки различных видов информации; однократный ввод первичных массивов информации с последующим многоразовым и многоцелевым их использованием; интегрированное использование массивов в различных режимах обработки; оперативность доступа к различным элементам информационных массивов; минимизацию стоимости создания и функционирования.
По организации и технологии обработки данных базы данных подразделяются на централизованные и распределенные.
Централизованную базу данных отличает единый массив данных, управляемый СУБД, которые размещены на центральном компьютере вместе с приложением, принимающим входную информацию с пользовательского терминала и отображающим данные на экране пользователя. Предположим, что пользователь вводит запрос, требующий последовательного просмотра базы данных (например, запрос на расчет потребности материалов на деталь в натуральном и стоимостном выражении). СУБД получает этот запрос, просматривает БД, выбирая с диска нужную запись, вычисляет значение и отображает результат на экране. Приложение и СУБД работают на одном компьютере, и, поскольку система обслуживает много различных пользователей, каждый из них ощущает снижение быстродействия по мере увеличения нагрузки на систему.
Распределенная база данных состоит из нескольких, возможно пересекающихся или даже дублирующих друг друга частей, хранимых в различных компьютерах вычислительной сети. Работа с такой БД осуществляется с помощью системы управления распределенной базой данных (СУРБД).
По способу доступа к данным БД разделяются на БД с локальным доступом и БД с удаленным (сетевым) доступом.
Системы централизованных БД с сетевым доступом предполагают различные архитектуры подобных систем: файл-сервер и клиент-сервер.
Появление персональных компьютеров и локальных вычислительных сетей привело к разработке архитектуры «файл-сервер». При такой архитектуре приложение, выполняемое на ПК, может получить прозрачный доступ к файл-серверу, на котором хранятся совместно используемые файлы. Когда приложению, работающему на ПК, требуется получить данные из совместно используемого файла, сетевое программное обеспечение автоматически считывает требуемый блок данных с сервера. Наиболее популярные БД для ПК, включая Microsoft Access, Paradox и dBase, поддерживают архитектуру «файл-сервер», при которой на каждом ПК работает своя копия СУБД.
При выполнении обычных запросов эта архитектура обеспечивает великолепную производительность, поскольку в распоряжении каждой копии СУБД находятся все ресурсы ПК. Однако рассмотрим приведенный выше пример. Поскольку запрос требует последовательного просмотра БД, СУБД постоянно запрашивает все новые блоки данных из БД, которая физически расположена на сервере сети. Очевидно, что в результате СУБД запросит и получит по сети все блоки файла. При выполнении запросов такого типа эта архитектура создает слишком большую нагрузку на сеть и уменьшает производительность работы.
Архитектура «клиент-сервер» предполагает объединение ПК в локальную сеть, в которой имеется выделенный сервер баз данных, содержащий общие БД. Функции СУБД разделены |на две части. Пользовательские программы, такие, как приложения, для формирования интерактивных запросов и генераторы отчетов, работают на клиентском компьютере.
Хранение данных и управление ими обеспечиваются сервером. В этой архитектуре SQL стал стандартным языком, предназначенным для обработки и чтения данных, содержащихся в БД. SQL обеспечивает взаимодействие между пользовательскими программами и ядром БД.
Вернемся к примеру определения потребности материалов на деталь. При архитектуре «клиент-сервер» запрос передается по сети на сервер БД в виде SQL-запроса. Ядро БД на сервере обрабатывает запрос и просматривает БД, которая также расположена на сервере. После вычисления результата ядро БД посылает его обратно по клиентскому приложению, которое отображает его на экране ПК.
Архитектура «клиент-сервер» позволяет сократить трафик и распределить процесс загрузки базы данных. Функции работы с пользователем, такие, как обработка ввода и отображение данных, выполняются на ПК пользователя. Функции работы с данными, такие, как дисковый ввод-вывод и выполнение запросов, выполняются сервером БД. Наиболее важно здесь то, что SQL обеспечивает четко определенный интерфейс между клиентской и серверной системами, эффективно передавая запросы на доступ к БД. Эта архитектура используется в современных СУБД Oracle, Informix, Sybase и др.
Математические теории «алгебра отношений» (relation — отношение) и «реляционное исчисление» легли в основу разработки языка запросов к базе данных (SQL). Наиболее часто используемым пользователями информационной системы элементом языка является «запрос» — описание состава требуемых данных и условий выборки их из базы данных на языке близком к естественному. Информационные системы кроме стандартных функций подготовки информации часто предоставляют для подготовленного пользователя (не программиста) возможность формировать запросы для получения специальной информации. Для выборки данных используется команда SELECT, включающая в себя описание требуемого результата выборки, описание источников информации, начинающееся с ключевого слова «FROM» и условия выборки данных после ключевого слова «WHERE». Например:
SELECT поле1, поле2, поле3 FROM таблица1 WHERE поле1= «ЗначениеПоля».
Источник: studopedia.org