БД

 Перехожу к изучению БД.

Читаю лекции https://siblec.ru/informatika-i-vychislitelnaya-tekhnika/bazy-dannykh#3

Конспект:

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

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

Вот другие определения:

Вики: База данных — совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных.

Одна из статей на Хабре База данных — это место для хранения данных.

https://thecode.media/db/: "базы данных — это набор данных, организованных каким-то способом." 

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

Итак: БД — множество элементов значений, объединённых между собой отношениями.

База = склад. 

Данные —  интерпретируемое формализованным способом представление информации, пригодное для коммуникации, интерпретации или обработки.

или проще

Данные — информация, которая обрабатывается, накапливается или выдается компьютером

Информация — сведения, воспринимаемые человеком и (или) спец. устройствами как отражение фактов материального или духовного мира в процессе коммуникации.

Мне пришла в голову аналогия со складом с адресным хранением (с современной системой хранения - по ячейкам).

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

Только всё это происходит виртуально.

Далее конспект.

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

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

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

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

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

Фундаментальные свойства отношений (таблиц)

Отношение (таблица) обладает следующими характеристиками:

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

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

Требования, предъявляемые к первичному ключу:

• уникальность – то есть в таблице не должно существовать двух или более записей с одинаковым значением первичного ключа;
• первичный ключ не должен содержать пустых значений.

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

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

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

Связи между таблицами. Записи в таблице могут зависеть от одной или нескольких записей другой таблицы. Такие отношения между таблицами называются связями. Связь определяется следующим образом: поле или несколько полей одной таблицы, называемое внешним ключом, ссылается на первичный ключ другой таблицы. Рассмотрим пример. Так как каждый заказ должен исходить от определенного клиента, каждая запись таблицы Orders (заказы) должна ссылаться на соответствующую запись таблицы Customers (клиенты). Это и есть связь между таблицами Orders и Customers. В таблице Orders должно быть поле, где хранятся ссылки на те или иные записи таблицы Customers.

Существует три типа связей между таблицами.

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

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

Многие ко многим — несколько записей одной таблицы связаны с несколькими записями другой. Например, один автор может написать несколько книг и несколько авторов — одну книгу. В случае такой связи в общем случае невозможно определить, какая запись одной таблицы соответствует выбранной записи другой таблицы, что делает неосуществимой физическую (на уровне индексов и триггеров) реализацию такой связи между соответствующими таблицами. Поэтому перед переходом к физической модели все связи "многие ко многим" должны быть переопределены (некоторые CASE-средства, если таковые используются при проектировании данных, делают это автоматически).Подобная связь между двумя таблицами реализуется путем создания третьей таблицы и реализации связи типа «один ко многим» каждой из имеющихся таблиц с промежуточной таблицей.

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

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

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

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

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

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

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

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

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

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

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

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

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

Про архитектуру мне не всё понятно, поэтому читаю ещё: https://fb-ru.turbopages.org/fb.ru/s/article/402559/arhitektura-bazyi-dannyih-ponyatie-opredelenie-urovni

И вот ещё почитать https://www.oracle.com/ru/database/what-is-database/

Далее прочитал и посмотрел https://habr.com/ru/company/oleg-bunin/blog/358984/ https://www.youtube.com/watch?v=c4_5rqvmDFU . Не всё понял, но было интересно.