Что такое базы: База данных (БД) - что это такое: СУБД или система управления данными

Содержание

Что такое База Данных (БД) / Хабр

База данных — это место для хранения данных. Используется в том числе в клиент-серверной архитектуре. Это все интернет-магазины, сайты кинотеатров или авиабилетов… Вы делаете заказ, а система сохраняет ваши данные в базе.

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

Статья рассчитана на начинающих тестировщиков или аналитиков, то есть тех, кто будет работать с базой, но не на супер-глубоком уровне. Она для тех, кто только входит в мир ИТ, и многого не знает. Она объясняет, что это за звено в клиент-серверной архитектуре такое, и зачем оно нужно.

Содержание

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

Что такое база данных

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

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

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

Теперь, если покупатель просит определенную пару, Катьке сложно её найти. Пока коробок было мало, она помнила наизусть, где что лежит. А теперь уже нет, да и все попытки организовать систему провалились. Места мало, да и детки любят с коробками поиграть.

Тогда Катька решила арендовать складское помещение. И вот теперь красота! Не надо теснить своих домашних, дома чисто и свободно! И на складе место есть, появилась система — тут босоножки, тут сапоги…

Чем больше объемы производства, тем больше нужно места. Если в начале пути склад не нужен, всё поместится дома, то потом это будет оправданно.

То же самое и в приложениях. Если приложение маленькое, то все данные можно хранить в памяти. Но учтите, что это память на вашем компьютере, вашем телефоне. И чем больше данных туда пихать, тем медленнее будет работать программа.

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

Как она выглядит

Да примерно как excel-табличка! Есть колонки с заголовками, и информация внутри:

Это называется реляционная база данных — набор таблиц, хранящихся в одном пространстве.

Что за пространство? Ну вот представьте, что вы храните все данные в excel. Можно запихать всю-всю-всю информацию в одну огро-о-о-о-мную таблицу, но это неудобно. Обычно табличек несколько: тут информация по клиентам, там по заказам, а тут по адресам. Эти таблицы удобно хранить в одном месте, поэтому кладем их в отдельную папочку:

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

Пример базы Oracle

Цель та же — выделить отдельное место, чтобы у вас не была одна большая свалка:

Хранение данных в виде табличек — это не единственно возможный вариант. Вот вам для примера запись из таблицы в системе Users. Там используется MongoDB база данных, она не реляционная. Поэтому вместо таблички «словно в excel» каждая запись хранится в виде объекта, вот так:

А еще есть файловые базы — когда у вас вся информация хранится в файликах. Да-да, простых текстовых файликах!

Почитать о разных видах баз данных можно в википедии. Я не буду в этой статье углубляться в эту тему, потому что моя задача — объяснить «что это вообще такое» для ребят, которые базу в глаза не видели. А на работе они скорее всего столкнутся именно с реляционной базой данных, поэтому о ней и речь.

Да, базы бывают разные. Классификацию можно изучить, можно выучить. Но по факту от начинающего тестировщика обычно нужно уметь достать информацию из реляционной БД («обычно» != «всегда», если что).

Как получить информацию из базы

Нужно записать свой запрос в понятном для базы виде — на SQL. SQL (Structured Query Language) — язык общения с базой данных. В нем есть ключевые слова, которые помогут вам сделать выборку:

select — выбери мне такие-то колонки…
from — из такой-то таблицы базы…
where — такую-то информацию…

Например, я хочу получить информацию по клиенту «Назина Ольга». Составляю в уме ТЗ:

Дай мне информацию по клиенту, у которого ФИО = «Назина Ольга»

Переделываю в SQL:

select * from clients where name = 'Назина Ольга';

В дословном переводе:

select -- выбери мне
* -- все колонки (можно выбирать конкретные, а можно сразу все)
from clients -- из таблицы clients
where name = 'Назина Ольга'; -- где поле name имеет значение 'Назина Ольга'

См также:
Комментарии в Oracle/PLSQL — мой перевод остается работающим запросом, потому что я убрала «лишнее» в комментарии

Если бы у меня была не база данных, а простые excel-файлики, то же действие было бы:

Открыть файл с нужными данными (clients)
Поставить фильтр на колонку «ФИО» — «Назина Ольга».

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

Бывают запросы и сложнее — когда надо достать данные не из одной таблицы, а из разных. В базе это будет выглядеть даже лучше, чем в эксельке. В экселе вам нужно открыть 1-2-3 таблицы и смотреть в каждую. Неудобно.

А в базе данных вы внутри запроса SQL указываете, какие колонки из каких таблиц вам нужны. И результат запроса их отрисовывает. Скажем, мы хотим увидеть заказ, который сделал клиент, ФИО клиента, и его номер телефона. И всё это в разных таблицах! А мы написали запрос и увидели то, что нам надо:

id_order	order (таблица order)	fio (таблица client)	phone (таблица contacts)
1	Пицца «Маргарита»	Иванова Мария	+7 (926) 555-33-44
2	Комбо набор 1	Петров Павел	+7 (926) 555-22-33

И пусть в таблице клиентов у нас будет 30 колонок, а в таблице заказов 50, в результате выборки мы видим ровно 4 запрошенные. Удобно, ничего лишнего!

Конечно, написать такой запрос будет немного сложнее обычного селекта. Это уже

select join, почитать о нем можно тут. И я рекомендую вам его изучить, потому что он входит в «базовое знание sql», которое требуется на собеседованиях.

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

Как связать данные между собой

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

last_name	first_name	birthdate	VIP
Иванов	Иван	01.02.1977	true
Петрова	Мария	02.04.1989	false
Сидоров	Павел	03. 02.1991	false
Иванов	Вася	04.04.1987	false
Ромашкина	Алина	16.11.2000	true

В таблице «orders» лежат данные по заказам. Что заказали (пиццу, суши, роллы), когда, насколько довольны доставкой?

order	addr	date	time
Пицца «Маргарита»	ул Ленина, д5	05.05.2020	06:00
Роллы «Филадельфия» и «Канада»	Студеный пр-д, д 10	15.08.2020	10:15
Пицца 35 см, роллы комбо 1	Заревый, д10	08.09.2020	07:13
Пицца с сосиками по краям	Турчанинов, 6	08. 09.2020	08:00
Комбо набор 3, обед №4	Яблочная ул, 20	08.09.2020	08:30

Но как понять, где чей был заказ? Сколько раз заказывал Вася, а сколько Алина?

Тут есть несколько вариантов:

1. Запихать все данные в одну таблицу: тут и заказы, и информация по клиентам… В целом удобно, открыл табличку и сразу видишь — ага, это Васин заказ, а это Машин.

Но есть минусы:

Таблица все растет и растет, в итоге получается просто огромной! А когда данных много, легкость чтения пропадает, придется листать до нужной колонки.
Поиск будет работать медленнее. Чем меньше информации в таблице, тем быстрее поиск. Когда у нас много строк, количество колонок становится существенным.
Много дублей — один человек может сделать хоть сотню заказов. И вся информация по нему будет продублирована сто раз. Неоптимальненько!

Чтобы избежать дублей, таблицы принято разделять:

Но надо при этом их как-то связать между собой, мы ведь всё еще хотим знать, чей конкретно был заказ. Для связи таблиц используется foreign key, внешний ключ.

Нам надо у заказа сделать отметку о клиенте. Значит, таблица «orders» будет ссылаться на таблицу «clients». Ключ можно поставить на любую колонку таблицы (в некоторых базах колонка должна быть уникальной, сначала её нужно такой указать). Какую бы выбрать?

Можно ссылаться на имя. А что, миленько, в таблице заказов будем сразу имя видеть! Но минуточку… А если у нас два клиента Ивана? Или три Маши? Десять Саш… Ну вы поняли =) И как тогда разобраться, где какой клиент? Не подходит!

Можно вешать foreign key на несколько колонок. Например, на фамилию + имя, или фамилию + имя + отчество. Но ведь и ФИО бывают неуникальные! Что тогда? Можно добавить в связку дату рождения. Тогда шанс ошибиться будет минимален, хотя и такие ребята существуют. И чем больше клиентов у вас будет, тем больше шанс встретить дубликат.

А можно не усложнять! Вместо того, чтобы делать внешний ключ на 10 колонок, лучше создать в таблице клиентов primary key, первичный ключ. Первичный ключ отвечает за то, чтобы каждое значение в поле было уникальным, никаких дублей. При попытке добавить в таблицу запись с неуникальным первичным ключом получаешь ошибку:

Здесь ключ — «id_order»

Вот на него и нужно ссылаться! Обычно таким ключом является ID, идентификатор записи. Его можно сделать автоинкрементальным — это значит, что он генерируется сам по алгоритму «прошлое значение + 1».

Например, у нас гостиница для котиков. Это когда хозяева едут в отпуск, а котика оставить не с кем — оставляем в гостинице!
Есть таблица постояльцев:

ID	name	year
1	Барсик	2
2	Пупсик	1

Тут привозят еще одного Барсика. Добавляем его в таблицу:
— Имя Барсик, 5 лет! (мы не указываем ID)
Система добавляет:

ID	name	year
1	Барсик	2
2	Пупсик	1
3	Барсик	5

ID сгенерился автоматически. Последнее значение было 2, значит, новый Барсик получил номер 3. Обратите внимание — Барсиков уже два, но их легко различить, ведь у них разные идентификаторы!
Теперь, если в другой таблице надо будет сослаться на котика, мы будем делать это именно через уникальный идентификатор. Например, у нас есть таблица комнат для постояльцев, куда мы заносим информацию о том, кто там живет:

id_room	square	id_cat (ссылка на id в таблице котиков)
1	5	1
2	10	2
3	10

Мы видим, что в первой комнате живет котик с id = 1, а во второй — с id = 2. В третьей комнате пока никто не живет. Так, благодаря связке таблиц, мы всегда можем понять, что именно за котофей там проживает.

Итак, теперь мы знаем, что идентификатор лучше делать первичным ключом, дабы обеспечить его уникальность. Можно сделать поле автоинкрементальным, чтобы оно заполнялось само. Так и поступим в таблице клиентов:

И в таблице заказов! «id_order» пусть генерится сам и всегда будет уникален. А еще в таблицу заказов мы добавим колонку «id_client» и повесим на нее foreign key, ссылку на «id_client» в таблице клиентов.

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

И наоборот, несколько таблиц могут ссылаться на одну и ту же колонку текущей таблицы. ID клиента мы можем указывать в таблице адресов, телефонов, email адресов, документов, заказов… Ограничений на это нет.

Зачем в базе индексы

Давайте представим, что у нас есть табличка excel. Если она небольшая (пара строк, пара колонок), то найти нужную ячейку не составит труда:

Открыли файлик — открывается моментально (если нет проблем с жестким диском)
Нажали «Ctrl + F», ввели запрос — тут же нашли результат.

Но что, если у нас сотни колонок и миллионы строк в файлике? Тогда начинаются тормоза. Файл открывается долго, в поиск значение ввели и система подвисла, обрабатывая результат…

Всё то же самое и в базе данных. Если табличка маленькая, любой запрос к ней отработает моментально. Если же таблица будет большая и с кучей данных, то результата запроса можно ждать минут по 15. А иногда и пару часов!

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

Индекс — это как алфавитный указатель в библиотеке. Вот представьте, заходите вы в библиотеку и хотите найти «Преступление и наказание» Достоевского. А все книги стоят «от балды», никакого порядка. Чтобы найти нужную, надо обойти все стелажи и просмотреть все полки!

Совсем другое дело, если книги отсортированы по авторам. А внутри автора — по названию. Тогда найти нужную книгу будет легко!

Индекс играет ту же роль для базы данных. Если повесить его на колонку таблицы, поиск по ней пойдет быстрее!

А можно повесить индекс на несколько нужных колонок (автор + название). Тут главное — не забывать порядок поиска в индексе. Если у нас индекс сначала по автору, а потом по названию, он будет бесполезен для поиска по названию, придется все равно пересматривать все книги. Поэтому, если нам часто нужно искать по названию и почти никогда — только по автору, имеет смысл поменять порядок в индексе — сначала название, потом автор.

Что делать, если запрос к БД тормозит

Если мы говорим о тестировщиках (а статья написана в первую очередь для них), то тут есть 2 варианта:

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

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

Это не тема базовой статьи.

А вот что делать во втором случае? Это не задача тестировщика — разбираться в том, почему запрос работает медленно. Этим занимаются DBA (администраторы баз данных) или разработчики.

Зато задача тестировщика — предоставить разработчику всю нужную информацию. Иногда её можно запросить у заказчика и его админов, а иногда нужно достать самому. Обычно для этого нужно:

Получить план запроса
Пересобрать статистику и проверить, продолжает ли тормозить

План запроса

Смотрите, когда вы выполняете любой запрос, что делает система:

Строит план выполнения запроса (как ей кажется, оптимальный)
Выполняет его

Посмотреть план можно через ключевые слова. В Oracle это EXPLAIN PLAN:

EXPLAIN PLAN FOR -- построй мне план для...
SELECT last_name FROM employees; -- вот такого запроса!

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

На рис sql developer — графический интерфейс для обращения к базе Oracle

Сверху на картинке идёт запрос. А снизу — план его выполнения. Нас сейчас не сильно волнует, что значит информация из первых колонок (то, как именно запрос обходит базу, в данном случае фулл-скан по таблице), нас интересует последняя колонка, «COST». Это стоимость запроса — 857 ms.

А теперь изменим запрос, сделав выборку по одному конкретному человеку по колонке с индексом:

Оп, цена запроса уже 5 ms. Это, на минуточку, в 170 раз быстрее!

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

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

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

Допустим, поступает жалоба от заказчика — клиент открывает карточку в вебе, а она открывается минуту. Что-то где-то тормозит! Но что и где? Начинаем разбираться. Причины бывают разные:

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

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

Собираете план, сохраняете в файлик и прикладываете в задачу в джире. Или отправляете по почте.

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

Статистика в БД

Именно статистика позволяет базе данных выбрать оптимальный план выполнения запроса. Почему вообще возникают проблемы вида «на тестовой базе один план, на боевой другой»?

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

Найди мне всех клиентов, созданных в этом году,
У которых оператор связи в телефоне — Мегафон

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

Какой вариант будет лучше? Никто не скажет без данных по таблицам. Может, у нас мало клиентов, но кучи телефонов (база перекупщиков), тогда быстрее будет начать с клиентов. А может, у нас миллионы клиентов, но всего пара сотен телефонов, тогда мы начнем с них.

Так вот, в статистике по БД хранится в том числе информация о распределении данных и характеристики хранения таблиц и индексов. И когда вы запускаете запрос, база (а точнее, оптимизатор внутри нее) строит возможные планы выполнения. Для каждого плана рассчитывает примерное время выполнения, а потом выбирает лучшее.

Время же он рассчитывает, ориентируясь на статистику:

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

См также:
Ручной и автоматический сбор статистики оптимизатора в базе данных Oracle
Практические методы оптимизации запросов в Apache Spark — подробнее об оптимизации запросов, в том числе и про индексы

Преимущества реляционных баз данных

Почему используют реляционную базу данных:

Она поддерживают требования ACID (по крайней мере транзакционная БД)
Это единый синтаксис SQL, который используется повсеместно

Требования ACID

ACID — это аббревиатура из требований, которые обеспечивают сохранность ваших данных:

Atomicity — Атомарность
Consistency — Согласованность
Isolation — Изолированность
Durability — Надёжность

Если база данных не поддерживает их, то могут быть печальные последствия из серии «Деньги с одного счета ушли, на другой не пришли? Ну сорян, бывает».

См также:
Требования ACID на простом языке — подробнее об этих требованиях

Единый синтаксис SQL

Я спросила знакомого разработчика:

— Ну и что, что единый синтаксис? В чем его плюшка то?

Ответ прекрасен, так что делюсь с вами:

— Почему в школе все преподают на русском? Почему не каждый свой язык? Одна школа — один, другая — другой. А ещё лучше не школа, а для каждого человека. Почему вавилонскую башню недостроили?

Как разработчик пишет код? Написал, проверил на коленке. Если не работает — думает, почему. Если непонятно, идет гуглить похожие ошибки. А что проще нагуглить? Ошибку распространенной БД, или сделанный на коленке костыль для работы с файлами? Вот то-то и оно…

Что знать для собеседования

Для начала я хочу уточнить, что я сама тестировщик. И мои статьи в первую очередь для тестировщиков ))

Зато тестировщика спрашивают про SQL. Вот вам обсуждение из чатика выпускников, пригодится для повторения материала:

— В вакансии написано: уметь составлять простые SQL запросы. А простые это какие в народном понимании?

— (inner, outer) join, select, insert, update, create, последнее время популярны индексы, group by, having, distinct.

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

Статьи и книги по теме

База данных

Википедия

Какие бывают базы данных

Базы данных. Виды и типы баз данных. Структура реляционных баз данных. Проектирование баз данных. Сетевые и иерархические базы данных.

SQL

Книги:

Изучаем SQL. Линн Бейли — Обожаю эту линейку книг, серию Head First O`Reilly. И всем рекомендую)) Просто и доступно даже о сложном пишут.

Статьи:

Как изучить основы SQL за 2 дня

Полезные запросы

Тренажеры:

http://www.sql-ex.ru/ — Бесплатный тренажер для практики

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

Задачка по SQL. Найти объединенные данные

Резюме

База данных — это место для хранения данных. Они бывают самых разных видов, даже файловые! Но самые распространенные — реляционные базы данных, где данные хранятся в виде таблиц.

Если посмотреть на информацию о таблице в БД, мы можем увидеть ее ключи и индексы. Что это такое:

1. PK — primary key, первичный ключ. Гарантирует уникальность данных, часто используется для колонки с ID. Если ключ наложен на одну колонку — каждое значение в ячейках этой колонки уникальное. Если на несколько — комбинации строк по колонкам уникальны.

2. FK — foreign key, внешний ключ. Нужен для связки двух таблиц в разных соотношениях (1:1, 1:N, N:N). Этот ключ указываем в «дочерней» таблице, то есть в той, которая ссылается на родительскую (в таблице с данными по лицевому счету отсылка на client_id из таблицы клиентов).

3. Индекс. Нужен для ускорения выборки из таблицы.

Транзакционные базы данных выполняют требования ACID:

Atomicity — Атомарность
Consistency — Согласованность
Isolation — Изолированность
Durability — Надежность

См также:
Что такое транзакция

И за это их выбирают разработчики. Мы получаем не просто хранилище данных. Наши данные защищены от неприятностей типа отключения электричества на середине бизнес-операции (с одного счета деньги списать, на другой записать). А еще по ним можно быстро искать, ведь разработчики баз данных оптимизируют свои приложения для этого.

Поэтому логика приложения — отдельно, база — отдельно. Так и получается клиент-серверная архитектура =)

См также:
Клиент-серверная архитектура в картинках

Чтобы достать данные из базы, надо написать запрос к ней на языке SQL (Structured Query Language). Разработчики пишут SQL-запросы внутри кода приложения. А тестировщики используют SQL для:

Поиска по базе — правильно ли данные сохранились? В нужные таблицы легли? Это select-запросы.
Подготовки тестовых данных — а что, если это значение будет пустое? А что, если у меня будет 2 лицевых счета на одной карточке? Можно готовить данные через графический интерфейс, но намного быстрее отправить несколько запросов в базу. Когда есть к ней доступ и вы знаете SQL =)

План-минимум для изучения: select, join, insert, update, create, delete, group by, having, distinct.

PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале

Так вот, тестировщика на собеседовании не будут спрашивать про базы данных. Разработчика ещё могут спросить, а вас то зачем? Вполне достаточно понимания, что это вообще такое. И про ключи могут спросить — что такое primary или foreign key, зачем они вообще нужны.

Что такое база данных

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

Что такое база данных

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

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

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

Свойства базы данных

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

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

Что такое язык структурированных запросов (SQL)?

SQL (или Structured Query Language) — это язык структурированных запросов, с помощью которого разработчик общается с базой данных. Если вы раньше работали с Excel, то наверняка знаете, что нужные строки или столбцы в ней можно выделить с помощью фильтра. В базе данных такой возможности нет, поэтому при работе с ней используются специальные команды на языке структурированных запросов. Рассмотрим, как это выглядит, на коротком примере.

Предположим, что у вас есть база данных с названием my_clients. В ней нужно найти все данные по пользователю с конкретным адресом почты. Чтобы получить их, надо написать: «select * from my_clients where email = ‘[email protected]’». Разберем этот код:

select * — помогает выбрать все столбцы. Звездочка заменяет слово «все». Если нужно выбрать только конкретные столбцы (например, узнать только имя или только дату рождения), то звездочку заменяют на названия этих столбцов;
from my_clients — ищет данные в таблице с названием my_clients. Можно искать сразу в нескольких таблицах, что значительно упрощает поиск при огромном количестве данных;
where email = ‘[email protected]’ — задает параметры для всех строк, где значение столбца email будет равно [email protected].

В чем разница между базой данных и электронной таблицей?

Как уже говорилось выше, база данных очень похожа на таблицу в Google Документах или Excel. Зачем же вообще переходить с таких таблиц на БД? Тому есть три важные причины:

Скорость чтения данных. Когда работа ведется с небольшими объемами информации, разница в скорости между Excel и базой данных будет незаметна. Но с ростом количества данных Excel будет постепенно отставать от базы данных. В крупных проектах разница будет колоссальна.
Нацеленность на большие объемы. В одной таблице Excel можно уместить максимум миллион строк (если быть точнее, то 1 048 576). Это достаточно большое число, но для крупных проектов такого количества данных не хватит. У баз данных число строк не ограничено.
Независимое редактирование. Сейчас у многих онлайн-документов есть функция совместного редактирования, но она не так удобна, как совместная работа в БД. Несколько авторизованных пользователей могут одновременно вносить изменения в базу данных, и эти изменения будут автоматически синхронизироваться.

Эволюция базы данных

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

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

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

Типы баз данных

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

Форма представления информации

База данных может представлять информацию в разном виде:

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

Тип используемой модели данных

Обычно базы данных — это таблицы, к которым можно обращаться на SQL. Такие БД называют реляционными.

Второй тип — нереляционные базы данных, которые представлены не в виде таблиц. Чаще всего это иерархические структуры, похожие на JSON.

Топология хранения

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

Функциональное назначение

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

Степень доступности

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

Что такое база данных MySQL?

База данных MySQL — это любая база данных, которая работает на реляционной СУБД на основе языка SQL. Проще говоря, если вы создаете и редактируете БД в MySQL, то вы используете базу данных MySQL.

Использование баз данных для повышения производительности бизнеса и улучшения процесса принятия решений

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

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

Задачи для баз данных

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

Значительно возросшие объемы данных. Еще в 2006 году объем данных Google был равен всего лишь 850 терабайт. Сейчас этот же показатель оценивается примерно в 15 эксабайт (10 квинтиллионов байт).
Обеспечение безопасности данных. Утечка персональных данных — бич современной IT-сферы. Даже крупнейшие компании страдают от воровства сведений, которое в итоге ведет к серьезным финансовым потерям.
Удовлетворение растущих потребностей. Каждый день перед IT-сферой встают новые задачи, порой принципиально отличающиеся от предыдущих. Их быстрое решение — одна из задач современных БД.
Управление и обслуживание базы данных и инфраструктуры. Чем сложнее становятся базы данных, тем меньше людей способны их администрировать.
Устранение границ масштабируемости. Идеальная база данных будет работать одинаково быстро и при 10, и при 101000 записей. Администраторам баз данных всегда сложно предугадать, какие мощности потребуются бизнесу, поэтому важно с самого начала делать БД, способную быстро работать с достаточно большими объемами.
Соблюдение требований к размещению данных, суверенитету данных и времени ожидания. Совместная работа — важная часть баз данных, и ее можно реализовать по-разному. Иногда компании нужно, чтобы базы данных работали только в локальной среде. В других случаях им требуется максимальный доступ для большого числа пользователей.

Как автономные технологии улучшают управление базами данных

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

Главное преимущество автономных БД — это автоматизация рутинных процессов: защиты, резервного копирования, обновления. Хорошо настроенная автономная БД нуждается в минимальном внимании администратора.

Будущее обычных и автономных баз данных

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

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

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

Гидроксид натрия | Определение, общее название и использование

Развлечения и поп-культура
География и путешествия
Здоровье и медицина
Образ жизни и социальные вопросы
Литература
Философия и религия
Политика, право и правительство
Наука
Спорт и отдых
Технология
Изобразительное искусство
Всемирная история

Этот день в истории
Викторины
Подкасты
Словарь
Биографии
Резюме
Популярные вопросы
Инфографика
Демистификация
Списки
#WTFact
Товарищи
Галереи изображений
Прожектор
Форум
Один хороший факт

Развлечения и поп-культура
География и путешествия
Здоровье и медицина
Образ жизни и социальные вопросы
Литература
Философия и религия
Политика, право и правительство
Наука
Спорт и отдых
Технология
Изобразительное искусство
Всемирная история

Britannica объясняет
В этих видеороликах Britannica объясняет различные темы и отвечает на часто задаваемые вопросы.
Britannica Classics
Посмотрите эти ретро-видео из архивов Encyclopedia Britannica.
Demystified Videos
В Demystified у Britannica есть все ответы на ваши животрепещущие вопросы.
#WTFact Видео
В #WTFact Britannica делится некоторыми из самых странных фактов, которые мы можем найти.
На этот раз в истории
В этих видеороликах узнайте, что произошло в этом месяце (или любом другом месяце!) в истории.

Студенческий портал
Britannica — это главный ресурс для учащихся по ключевым школьным предметам, таким как история, государственное управление, литература и т. д.
Портал COVID-19
Хотя этот глобальный кризис в области здравоохранения продолжает развиваться, может быть полезно обратиться к прошлым пандемиям, чтобы лучше понять, как реагировать сегодня.
100 женщин
Britannica празднует столетие Девятнадцатой поправки, выделяя суфражисток и политиков, творящих историю.
Спасение Земли
Британника представляет список дел Земли на 21 век. Узнайте об основных экологических проблемах, стоящих перед нашей планетой, и о том, что с ними можно сделать!
SpaceNext50
Britannica представляет SpaceNext50. От полета на Луну до управления космосом — мы изучаем широкий спектр тем, которые питают наше любопытство к космосу!

Содержание

Введение

Краткие факты

Факты и сопутствующий контент

Гидроксид аммония | Формула, использование, свойства и факты

Развлечения и поп-культура
География и путешествия
Здоровье и медицина
Образ жизни и социальные вопросы
Литература
Философия и религия
Политика, право и правительство
Наука
Спорт и отдых
Технология
Изобразительное искусство
Всемирная история

Этот день в истории
Викторины
Подкасты
Словарь
Биографии
Резюме
Популярные вопросы
Инфографика
Демистификация
Списки
#WTFact
Товарищи
Галереи изображений
Прожектор
Форум
Один хороший факт

Развлечения и поп-культура
География и путешествия
Здоровье и медицина
Образ жизни и социальные вопросы
Литература
Философия и религия
Политика, право и правительство
Наука
Спорт и отдых
Технология
Изобразительное искусство
Всемирная история

Britannica объясняет
В этих видеороликах Britannica объясняет различные темы и отвечает на часто задаваемые вопросы.
Britannica Classics
Посмотрите эти ретро-видео из архивов Encyclopedia Britannica.
Demystified Videos
В Demystified у Britannica есть все ответы на ваши животрепещущие вопросы.
#WTFact Видео
В #WTFact Britannica делится некоторыми из самых странных фактов, которые мы можем найти.
На этот раз в истории
В этих видеороликах узнайте, что произошло в этом месяце (или любом другом месяце!) в истории.

Студенческий портал
Britannica — это главный ресурс для учащихся по ключевым школьным предметам, таким как история, правительство, литература и т. д.
Портал COVID-19
Хотя этот глобальный кризис в области здравоохранения продолжает развиваться, может быть полезно обратиться к прошлым пандемиям, чтобы лучше понять, как реагировать сегодня.
100 женщин
Britannica празднует столетие Девятнадцатой поправки, выделяя суфражисток и политиков, творящих историю.

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

Что такое База Данных (БД) / Хабр

Содержание

Что такое база данных

Как она выглядит

Как получить информацию из базы

Как связать данные между собой

Зачем в базе индексы

Что делать, если запрос к БД тормозит

Преимущества реляционных баз данных

Требования ACID

Единый синтаксис SQL

Что знать для собеседования

Статьи и книги по теме

Резюме

Что такое база данных

Что такое база данных

Свойства базы данных

Что такое язык структурированных запросов (SQL)?

В чем разница между базой данных и электронной таблицей?

Эволюция базы данных

Типы баз данных

Форма представления информации

Тип используемой модели данных

Топология хранения

Функциональное назначение

Степень доступности

Популярные системы управления базами данных (СУБД)

MySQL

Oracle

PostgreSQL

MongoDB

Redis

Elasticsearch

SQLite

Neo4j

Что такое база данных MySQL?

Использование баз данных для повышения производительности бизнеса и улучшения процесса принятия решений

Задачи для баз данных

Как автономные технологии улучшают управление базами данных

Будущее обычных и автономных баз данных

Гидроксид натрия | Определение, общее название и использование

Гидроксид аммония | Формула, использование, свойства и факты

Добавить комментарий Отменить ответ