ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 01.12.2023
Просмотров: 480
Скачиваний: 3
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Что такое транзакции? Расскажите про принципы ACID
Транзакция – это воздействие на базу данных, переводящее ее из одного целостного состояния в другое и выражаемое в изменении данных, хранящихся в базе данных.
ACID-принципы транзакций:
•
Атомарность (atomicity) гарантирует, что транзакция будет полностью выполнена или потерпит неудачу, где транзакция представляет одну логическую операцию данных.
Это означает, что при сбое одной части любой транзакции происходит сбой всей транзакции и состояние базы данных остается неизменным.
•
Согласованность (consistency). Транзакция, достигающая своего завершения и фиксирующая свои результаты, сохраняет согласованность базы данных.
•
Изолированность (isolation). Во время выполнения транзакции параллельные транзакции не должны оказывать влияние на ее результат.
•
Долговечность (durability). Независимо от проблем (к примеру, потеря питания, сбой или ошибки любого рода) изменения, сделанные успешно завершенной транзакцией,
должны остаться сохраненными после возвращения системы в работу.
Расскажите про уровни изолированности транзакций
«Грязное» чтение (Dirty Read): транзакция A производит запись. Между тем транзакция B
считывает ту же самую запись до завершения транзакции A. Позже транзакция A решает откатится, и теперь у нас есть изменения в транзакции B, которые несовместимы. Это грязное чтение. Транзакция B работала на уровне изоляции READ_UNCOMMITTED, поэтому она могла считывать изменения, внесенные транзакцией A до того, как транзакция завершилась.
Неповторяющееся чтение (Non-Repeatable Read): транзакция A считывает некоторые записи. Затем транзакция B записывает эту запись и фиксирует ее. Позже транзакция A
снова считывает эту же запись и может получить разные значения, поскольку транзакция B
вносила изменения в эту запись и фиксировала их. Это неповторяющееся чтение.
Фантомные чтение (Phantom Read): транзакция A читает ряд записей. Между тем транзакция B вставляет новую запись в этот же ряд, что и транзакция A. Позднее транзакция
A снова считывает тот же диапазон и также получит запись, которую только что вставила транзакция B. Это фантомное чтение: транзакция извлекала ряд записей несколько раз из базы данных и получала разные результирующие наборы (содержащие фантомные записи).
Что такое нормализация и денормализация? Расскажите про 3 нормальные
формы
Нормализация – это процесс преобразования отношений базы данных к виду, отвечающему нормальным формам (пошаговый, обратимый процесс приведения данных в более простую и логичную структуру).
Целью является уменьшение потенциальной противоречивости хранимой в базе данных информации.
Денормализация базы данных – это процесс обратный от нормализации. Эта техника добавляет избыточные данные в таблицу, учитывая частые запросы к базе данных, которые объединяют данные из разных таблиц в одну таблицу. Необходимо для повышения производительности и скорости извлечения данных за счет увеличения избыточности данных.
Каждая нормальная форма включает в себя предыдущую. Типы форм:
•
Первая нормальная форма (1NF) – значения всех полей атомарны (неделимы), нет множества значений в одном поле.
Требование первой нормальной формы (1NF) очень простое и оно заключается в том, чтобы таблицы соответствовали реляционной модели данных и соблюдали определённые реляционные принципы.
Таким образом, чтобы база данных находилась в 1 нормальной форме, необходимо чтобы ее таблицы соблюдали следующие реляционные принципы:
◦ В таблице не должно быть дублирующих строк
◦ В каждой ячейке таблицы хранится атомарное значение (одно не составное значение)
◦ В столбце хранятся данные одного типа
◦ Отсутствуют массивы и списки в любом виде
•
Вторая нормальная форма (2NF) – все неключевые поля зависят только от ключа целиком, а не от какой-то его части.
Чтобы база данных находилась во второй нормальной форме (2NF), необходимо чтобы ее таблицы удовлетворяли следующим требованиям:
◦ Таблица должна находиться в первой нормальной форме
◦ Таблица должна иметь ключ
◦ Все неключевые столбцы таблицы должны зависеть от полного ключа (в случае
если он составной)
•
Третья нормальная форма (3NF) – все неключевые поля не зависят друг от друга.
Требование третьей нормальной формы (3NF) заключается в том, чтобы в таблицах отсутствовала транзитивная зависимость.
Транзитивная зависимость – это когда неключевые столбцы зависят от значений других неключевых столбцов.
•
Нормальная форма Бойса-Кодда, усиленная 3 нормальная форма (BCNF) – когда каждая ее нетривиальная и неприводимая слева функциональная зависимость имеет в качестве своего детерминанта некоторый потенциальный ключ.
Требования нормальной формы Бойса-Кодда следующие:
◦ Таблица должна находиться в третьей нормальной форме. Здесь все как обычно,
т.е. как и у всех остальных нормальных форм, первое требование заключается в том, чтобы таблица находилась в предыдущей нормальной форме, в данном случае в третьей нормальной форме;
◦ Ключевые атрибуты составного ключа не должны зависеть от неключевых атрибутов.
•
Четвертая нормальная форма (4NF) – не содержатся независимые группы полей,
между которыми существует отношение «многие-ко-многим».
Требование четвертой нормальной формы (4NF) заключается в том, чтобы в таблицах отсутствовали нетривиальные многозначные зависимости.
В таблицах многозначная зависимость выглядит следующим образом.
Начнем с того, что таблица должна иметь как минимум три столбца, допустим A, B и C, при этом B и C между собой никак не связаны и не зависят друг от друга, но по отдельности зависят от A, и для каждого значения A есть множество значений B, а также множество значений C.
В данном случае многозначная зависимость обозначается вот так:
A —> B
A —> C
•
Пятая нормальная форма (5NF) – каждая нетривиальная зависимость соединения в ней определяется потенциальным ключом (ключами) этого отношения.
•
Доменно-ключевая нормальная форма (DKNF) – каждое наложенное на нее ограничение является логическим следствием ограничений доменов и ограничений ключей, наложенных на данное отношение.
Ограничение домена – это ограничение, предписывающее использование для определенного атрибута значений только из некоторого заданного домена (набора значений).
Ограничение ключа – это ограничение, утверждающее, что некоторый атрибут или комбинация атрибутов представляет собой потенциальный ключ.
Таким образом, требование доменно-ключевой нормальной формы заключается в том,
чтобы каждое наложенное ограничение на таблицу являлось логическим следствием ограничений доменов и ограничений ключей, которые накладываются на данную таблицу.
•
Шестая нормальная форма (6NF) – удовлетворяет всем нетривиальным зависимостям соединения, то есть не может быть подвергнута дальнейшей декомпозиции без потерь. Введена как обобщение пятой нормальной формы для хронологической базы данных.
Хронологическая база данных – это база, которая может хранить не только текущие данные, но и исторические данные, т. е. данные, относящиеся к прошлым периодам времени. Однако такая база может хранить и данные, относящиеся к будущим периодам времени.
Что такое TIMESTAMP?
DATETIME предназначен для хранения целого числа: YYYYMMDDHHMMSS. И это время не зависит от временной зоны настроенной на сервере. Размер 8 байт.
TIMESTAMP хранит значение равное количеству секунд, прошедших с полуночи 1 января
1970 года по усредненному времени Гринвича. Тогда была создана Unix. При получении из базы отображается с учетом часового пояса. Размер 4 байта.
Шардирование БД
При большом количестве данных запросы начинают долго выполняться, и сервер начинает не справляться с нагрузкой. Одно из решений – масштабирование базы данных. Например,
шардинг или репликация.
Шардинг бывает вертикальным (партицирование) и горизонтальным.
У нас есть большая таблица, например, с пользователями. Партицирование – это когда мы одну большую таблицу разделяем на много маленьких по какому-либо принципу.
Единственное отличие горизонтального масштабирования от вертикального в том, что горизонтальное будет разносить данные по разным инстансам в других базах.
Есть таблица news, в которой естьидентификатор, есть категория, в которой эта новость расположена, есть автор новости.
Нужно сделать 2 действия над табличкой
1. Поставить у нашего шарда, например, news_1, то, что она будет наследоваться от news.
Наследованная таблица будет иметь все колонки родителя, а также она может иметь свои колонки, которые мы дополнительно туда добавим. Там не будет ограничений, индексов и триггеров от родителя. Это важно.
2. Поставить ограничения. Это будет проверка, что в эту таблицу будут попадать данные только с нужным признаком.
Т. е. только записи с category_id=1 будут попадать в эту таблицу.
На базовую таблицу надо добавить правило. Когда будем работать с таблицей news, вставка на запись с category_id = 1 должна попасть именно в партицию news_1. Правило называем,
как хотим.
EXPLAIN
Когда выполняете какой-нибудь запрос, оптимизатор запросов MySQL пытается придумать оптимальный план выполнения этого запроса. Можно посмотреть этот план, используя запрос с ключевым словом EXPLAIN перед оператором SELECT.
EXPLAIN SELECT * FROM categories
После EXPLAIN в запросе можно использовать ключевое слово EXTENDED, и MySQL
покажет дополнительную информацию о том, как выполняется запрос. Чтобы увидеть эту информацию, нужно сразу после запроса с EXTENDED выполнить запрос SHOW
WARNINGS.
EXPLAIN EXTENDED SELECT City.Name FROM City
Затем
SHOW WARNINGS
Как сделать запрос из двух баз?
Если в запросе таблица указывается с именем базы данных database1.table1, то таблица выбирается из database1, если просто table1, то из активной базы данных.
Надо, чтобы базы были на одном сервере.
SELECT t1.*, t2.*
FROM database1.table1 AS t1
INNER JOIN database2.table2 AS t2 ON t1.field1 = t2.field1
Что быстрее убирает дубликаты: distinct или group by?
Если нужны уникальные значения – DISTINCT.
Если нужно группировать значения – GROUP BY.
Если задача заключается именно в поиске дубликатов – GROUP BY будет лучше.
Hibernate
Что такое ORM? Что такое JPA? Что такое Hibernate?
ORM (Object Relational Mapping) – это концепция преобразования данных из объектно- ориентированного языка в реляционные БД и наоборот.
JPA (Java Persistence API) – это стандартная для Java спецификация, описывающая принципы ORM. JPA не умеет работать с объектами, а только определяет правила, как должен действовать каждый провайдер (Hibernate, EclipseLink), реализующий стандарт JPA.
JPA определяет правила, по которым должны описываться метаданные отображения и как должны работать провайдеры. Каждый провайдер обязан реализовывать все из JPA,
определяя стандартное получение, сохранение, управление объектами. Можно добавлять свои классы и интерфейсы.
Гибкость – код написанный с использование классов и интерфейсов JPA, позволяет гибко менять одного провайдера на другого, но если использовать классы, аннотации и интерфейсы из конкретного провайдера, то это работать не будет.
JDO входит в JPA, NoSQL.
Hibernate – библиотека, являющаяся реализацией JPA-спецификации, в которой можно использовать не только стандартные API-интерфейсы JPA, но и реализовать свои классы и интерфейсы.
Важные интерфейсы Hibernate:
Session – обеспечивает физическое соединение между приложением и БД. Основная функция – предлагать DML-операции для экземпляров сущностей.
SessionFactory – это фабрика для объектов Session. Обычно создается во время запуска приложения и сохраняется для последующего использования. Является потокобезопасным объектом и используется всеми потоками приложения.
Transaction – однопоточный короткоживущий объект, используемый для атомарных операций. Это абстракция приложения от основных JDBC-транзакций. Session может занимать несколько Transaction в определенных случаях, является необязательным API.
1 ... 14 15 16 17 18 19 20 21 ... 25
Query – интерфейс позволяет выполнять запросы к БД. Запросы написаны на HQL или на
SQL.
Что такое EntityManager? Какие функции он выполняет?
EntityManager – интерфейс JPA, который описывает API для всех основных операций над
Entity, а также для получения данных и других сущностей JPA.
Основные операции:
1. Операции над Entity: persist (добавление Entity), merge (обновление), remove
(удаление), refresh (обновление данных), detach (удаление из управление JPA), lock
(блокирование Entity от изменений в других thread).
2. Получение данных: find (поиск и получение Entity), createQuery, createNamedQuery,
createNativeQuery,
contains,
createNamedStoredProcedureQuery,
createStoredProcedureQuery.
3. Получение других сущностей JPA: getTransaction, getEntityManagerFactory,
getCriteriaBuilder, getMetamodel, getDelegate.
4. Работа с EntityGraph: createEntityGraph, getEntityGraph.
5. Общие операции над EntityManager или всеми Entities: close, clear, isOpen,
getProperties, setProperty.
Объекты EntityManager не являются потокобезопасными. Это означает, что каждый поток должен получить свой экземпляр EntityManager, поработать с ним и закрыть его в конце.
Каким условиям должен удовлетворять класс, чтобы являться Entity?
Entity – это легковесный хранимый объект бизнес логики. Основная программная сущность – это entity-класс, который может использовать дополнительные классы, которые могут использоваться как вспомогательные классы или для сохранения состояния еntity.
Требования к e
ntity-классу
:
•
должен быть помечен аннотацией Entity или описан в XML-файле;
•
должен содержать public или protected конструктор без аргументов (он также может иметь конструкторы с аргументами) – при получении данных из БД и формировании из них объекта сущности Hibernate должен создать этот объект сущности$
•
должен быть классом верхнего уровня (top-level class);
•
не может быть enum или интерфейсом;
•
не может быть финальным классом (final class);
•
не может содержать финальные поля или методы, если они участвуют в маппинге
(persistent final methods or persistent final instance variables);
•
если объект entity-класса будет передаваться по значению как отдельный объект
(detached object), например, через удаленный интерфейс (through a remote interface),
он должен реализовывать интерфейс Serializable;
•
поля entity-класса должны быть напрямую доступны только методам самого entity- класса и не должны быть напрямую доступны другим классам, использующим этот entity. Такие классы должны обращаться только к методам (getter/setter методам или другим методам бизнес-логики в entity-классе);
•
должен содержать первичный ключ, то есть атрибут или группу атрибутов, которые уникально определяют запись этого entity-класса в базе данных.
Может ли абстрактный класс быть Entity?
Может, при этом он сохраняет все свойства Entity, за исключением того, что его нельзя непосредственно инициализировать.
Может ли entity-класс наследоваться от не entity-классов (non-entity
classes)?
Может.
Может ли entity-класс наследоваться от других entity-классов?
Может.
Может ли НЕ entity-класс наследоваться от entity-класса?
Может.
Что такое встраиваемый (embeddable) класс? Какие требования JPA
устанавливает к встраиваемым (embeddable) классам?
Embeddable-класс – это класс, который не используется сам по себе, а является частью одного или нескольких entity-классов. Entity-класс может содержать как одиночные встраиваемые классы, так и коллекции таких классов. Также такие классы могут быть использованы как ключи или значения map. Во время выполнения каждый встраиваемый класс принадлежит только одному объекту entity-класса и не может быть использован для передачи данных между объектами entity-классов (то есть такой класс не является общей структурой данных для разных объектов). В целом, такой класс служит для того, чтобы выносить определение общих атрибутов для нескольких entity.
Такие классы должны удовлетворять тем же правилам, что entity-классы, за исключением того, что они не обязаны содержать первичный ключ и быть отмечены аннотацией Entity.
Embeddable-класс должен быть помечен аннотацией @Embeddable или описан в XML- файле конфигурации JPA. А поле этого класса в Entity аннотацией @Embedded.
Embeddable-класс может содержать другой встраиваемый класс.
Встраиваемый класс может содержать связи с другими Entity или коллекциями Entity, если такой класс не используется как первичный ключ или ключ map'ы.
Что такое Mapped Superclass?
Mapped Superclass – это класс, от которого наследуются Entity, он может содержать анотации JPA, однако сам такой класс не является Entity, ему не обязательно выполнять все требования, установленные для Entity (например, он может не содержать первичного ключа).
Такой класс не может использоваться в операциях EntityManager или Query. Такой класс должен быть отмечен аннотацией MappedSuperclass или описан в xm- файле.
Создание такого класса-предка оправдано тем, что заранее определяется ряд свойств и методов в сущностях. Использование такого подхода позволило сократить количество кода.
Какие три типа стратегий наследования мапинга (Inheritance Mapping
Strategies) описаны в JPA?
Inheritance Mapping Strategies описывает как JPA будет работать с классами-наследниками
Entity:
1. Одна таблица на всю иерархию классов (SINGLE_TABLE) – все entity со всеми наследниками записываются в одну таблицу, для идентификации типа entity определяется специальная колонка «discriminator column». Например, есть entity Animals c классами- потомками Cats и Dogs. При такой стратегии все entity записываются в таблицу Animals, но при этом имеют дополнительную колонку animalType, в которую соответственно пишется значение «cat» или «dog». Минусом является то, что в общей таблице будут созданы все поля, уникальные для каждого из классов-потомков, которые будут пусты для всех других классов-потомков. Например, в таблице animals окажется и скорость лазанья по дереву от cats, и может ли пес приносить тапки от dogs, которые будут всегда иметь null для dog и cat соответственно.
Нельзя делать constraints notNull, но можно использовать триггеры.