Project2 #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open

sabahoth01 wants to merge 26 commits into main from project2

Project/11.12.2024_05.55.52_REC.png

Sorry, something went wrong. Reload?

Sorry, we cannot display this file.

Sorry, this file is invalid so it cannot be displayed.

Project/README.md

-Original file line number
+Diff line change
@@ Expand Up @@
     - Инфо логическая модель
     - Дата логическая модель
+    ## 3. Улучшение структуры БД
+    ### Нормальная форма (Database normalization)
+    Под. Описание [wikipedia](https://ru.wikipedia.org/wiki/%D0%9D%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%84%D0%BE%D1%80%D0%BC%D0%B0)
+    Нормализация позволяет оптимально распределять атрибуты по таблицам. Данная методика избавляет от:
+    - атрибутов с несколькими значениями;
+    - повторяющихся атрибутов;
+    - атрибутов, не поддающихся классификации;
+    - атрибутов с избыточной информацией;
+    - атрибутов, созданных из других признаков.
+. Первая нормальная форма (1NF)
+    Таблица находится в 1NF, если она имеет Атомарные значения (нет повторяющихся групп или массивов) и
+    Каждая строка уникально идентифицируется первичным ключом.
+    Мои схемы уже соответствуют 1NF, так как каждый столбец содержит атомарные значения, и первичные ключи определены для всех таблиц.
+. Вторая нормальная форма (2NF)
+    Таблица находится во 2NF, если:
+    Она находится в 1NF.
+    Все неключевые атрибуты полностью функционально зависят от первичного ключа (нет частичной зависимости).
+    Мои схемы уже соответствуют 2NF.
+. Третья нормальная форма (3NF)
+    Таблица находится в 3NF, если:
+    Она находится в 2NF.
+    Нет транзитивной зависимости, что означает, что неключевые атрибуты не должны зависеть от других неключевых атрибутов.
+    Таблица сотрудников: таблица включает ссылку на внешний ключ base_id, что можно считать транзитивной зависимостью.<br/>
+    Вместо того чтобы напрямую хранить base_id, могу создать новую таблицу, которая связывает сотрудников с их базой, и удалить прямую ссылку из таблицы сотрудников.
+    Чтобы решить эту проблему, создаю отдельную таблицу employee_base:
+    ```sql
+    CREATE TABLE employee_base (
+        emp_id INTEGER NOT NULL REFERENCES employee ON DELETE CASCADE,
+        base_id INTEGER NOT NULL REFERENCES base ON DELETE SET NULL,
+        PRIMARY KEY (emp_id, base_id)
+    );
+    ```
+    Это устраняет транзитивную зависимость от base_id в таблице сотрудников и улучшает 3NF.
+. Нормальная форма Бойса-Кодда (BCNF)
+    Таблица находится в BCNF, если:
+    Она находится в 3NF.
+    Для каждой нетривиальной функциональной зависимости детерминант является кандидатом в ключи.
+    Таблица employee_base, описанная выше, поможет обеспечить отсутствие нетривиальных функциональных зависимостей, нарушающих BCNF.
+    После этого, давайте подумаем о том, какие запросы будут наиболее часто используемыми (востребованными) для этой базы данных. В моем случае, я думаю, что нам обычно потребуется:
+    - Извлекать данные о сотрудниках, обновлять их и получать информацию о здоровье сотрудников,
+    - знать о различных миссиях, доходах и клиентах,
+    - а также о состоянии нашего транспорта.
+    Основываясь на этом, давайте используем некоторые полезные методы для повышения производительности этой базы данных:
+    ### Временные структуры и представления, способы валидации запросов
+    - Представления (Views) и Материализованные представления (Materialized Views)
+    <br/>Материализованное представление в базе данных функционирует аналогично обычному представлению, но с одним важным отличием: оно кэширует результат запроса представления,
+    <br/>сохраняя его в виде физической таблицы. Это означает, что в отличие от стандартного представления, при котором базовый запрос выполняется при каждом обращении к нему,
+    <br/>материализованное представление отображает сохраненные данные до тех пор, пока они не будут обновлены. Это может значительно повысить производительность сложных запросов, для которых не требуются данные в реальном времени.
+    ### Индексы (Indexes)
+    Сначала я проверила часто используемые столбцы и создала выборку некоторых индексов, которые, по моему мнению, будут важны для повышения производительности базы данных.
+    Отметим, что я выбрала хэш-индекс для столбцов, основанных на идентификаторах, потому что:
+. Хэш-индексы(hash index) оптимизированы для поиска равенства (например, WHERE id = ?), что характерно для столбцов ID.
+. Хэш-индексы обеспечивают быстрое время поиска при средней временной сложности O(1), что делает их подходящими для первичных ключей и уникальных идентификаторов.
+    <br/>Поскольку столбцы идентификаторов часто используются в точных совпадениях (=), хэш-индексы могут эффективно обрабатывать эти запросы.
+    <br/>С другой стороны:<br/>
+. Индексы B-дерева(b-tree) подходят для запросов диапазона (например, WHERE column > ? или WHERE column BETWEEN ? И ?), что характерно для столбцов без идентификатора.
+. Индексы B-дерева поддерживают эффективную сортировку и упорядочение, что делает их идеальными для столбцов, используемых в предложениях ORDER BY и GROUP BY.
+. Индексы B-дерева могут выполнять поиск как по равенству(=), так и по диапазону(<...>), что делает их хорошим выбором для столбцов с различными шаблонами запросов.
+    <br/>Иногда индексы не всегда работают должным образом. Или мы можем создавать индексы, которые на самом деле не важны для базы данных. Итак, я решила провести некоторые проверки, которые позволили бы удалить неиспользуемые индексы.
+    ```sql
+    SELECT relname , indexrelname , idx_scan , idx_tup_read , idx_tup_fetch
+    FROM pg_stat_user_indexes
+    WHERE schemaname = 'public' and
+      relname in ('campaign');
+    ```
+    ### Общие табличные выражения (CTE) и Временные таблицы (Temporary Tables)
+    CTE и временные таблицы имеют общие цели. Обе они генерируют промежуточные результаты для запроса,
+    <br/>не оставляя постоянных объектов в базе данных; это экономит место для хранения. Но между ними есть важные различия: для CTE повторное использование кода ограничено одним запросом.<br/>С другой стороны, данные, хранящиеся во временной таблице, могут многократно использоваться в различных запросах. Ключевым требованием является то, что эти запросы выполняются в рамках одного и того же подключения к базе данных (сеанса).
+    Я выбрала (CTE) для сводки (по состоянию здоровья сотрудников и доступности транспорта), потому что это упрощает запрос и делает его более читаемым.
+    <br/>Они также позволяют разделить сложную логику на более мелкие и управляемые части.
+    <br/>С другой стороны, я выбрал временную таблицу для определения наличия рабочих мест, поскольку она позволяет хранить промежуточные результаты и манипулировать ими,
+    <br/>которые можно использовать несколько раз в запросе (например, в течение дня, если где-то требуется дополнительный сотрудник) или в нескольких запросах.
+    - EXPLAIN ANALYZE
+    <br/>EXPLAIN: предоставляет вам подробный план запроса, который показывает, как PostgreSQL планирует выполнить ваш SQL-запрос.
+    <br/>Можно запустить EXPLAIN перед запросом SELECT, чтобы увидеть, какие шаги предпримет PostgreSQL для извлечения данных (например, использует ли он индекс, выполняет ли последовательное сканирование, объединяет и т.д.).
+    <br/>EXPLAIN ANALYZE: фактически запускает запрос и показывает реальное время выполнения, помогая вам понять, насколько эффективно выполняется запрос. Он также показывает количество строк, обработанных на каждом шаге.
+    Пример использования до и после один из индексов. Можно заметить что время выполнения запроса время выполнения уменш.<br/>
+    <img alt="EXPLAIN ANALYZE" height="350" src="11.12.2024_05.55.52_REC.png" width="350"/>
+    - VACUUM
+    <br/>PostgreSQL использует систему версионирования (MVCC), поэтому, когда строки обновляются или удаляются,
+    диск не освобождается немедленно. Со временем это может привести к раздуванию таблицы.
+    Запуск VACUUM помогает вернуть пространство и также может улучшить производительность.
+    <br/>VACUUM: Освобождает место и анализирует таблицу для обновления статистики.
+    <br/>VACUUM FULL: Полностью переписывает таблицу, освобождая пространство, но является более затратным и может блокировать таблицу на некоторое время.
+    ## 4. Триггеры и транзакции

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Project2 #6

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Uh oh!

Project2 #6

Are you sure you want to change the base?

Uh oh!

Project2 #6

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Uh oh!