Загрузка данных

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

---

📚 РАСШИРЕННЫЙ КОНСПЕКТ: Глава 2. Теория логического моделирования

Введение

В основе любой информационной системы лежит база данных (БД) — совокупность структурированных данных. Для работы с ней используется СУБД — система управления базами данных. Основная задача моделирования — упростить реальный мир до понятной структуры (схемы).

---

2.1. Общепринятые аспекты (Понятие информации и данных)

· Информация — сведения об объектах реального мира, которые уменьшают неопределённость.
· Данные — это информация, представленная в формализованном виде, пригодном для обработки (хранения, передачи, автоматизации).
· Логическое моделирование — это процесс перехода от реального мира к формальной модели данных, где определяются сущности, атрибуты и связи.

Три концепции при моделировании:

1. Логическая модель — описывает предметную область на уровне сущностей и связей, без привязки к конкретной СУБД (например, ER-модель).
2. Даталогическая модель — логическая модель, адаптированная под конкретную СУБД (например, реляционная таблица).
3. Физическая модель — описывает, как данные физически размещаются на носителе (файлы, индексы, страницы).

---

2.2. Понятие предметной области

Предметная область — это часть реального мира, которая исследуется для создания БД. Она включает в себя:

· Объекты (сущности) — то, что имеет значение для данной системы.
· Атрибуты — характеристики объектов.
· Связи — отношения между объектами.

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

---

2.3. Сущность, атрибут, связь (Детальный разбор)

Сущность

· Сущность — это реальный или абстрактный объект, который имеет независимое существование и может быть идентифицирован.
· Экземпляр сущности — конкретный представитель (например, «Иванов И.И.» — экземпляр сущности «Студент»).
· Тип сущности — общее описание (например, «Студент»).
· Каждая сущность должна иметь ключ (уникальный идентификатор).

Атрибуты

· Простой атрибут — неделимый (например, «Возраст»).
· Составной атрибут — состоит из нескольких частей (например, «Адрес» = «Город» + «Улица» + «Дом»).
· Однозначные / Многозначные — может ли атрибут иметь несколько значений (например, «Телефон» — многозначный, если у человека их несколько).
· Производные атрибуты — вычисляемые из других (например, «Возраст» из «Даты рождения»).
· Ключевые атрибуты — уникально идентифицируют сущность.

Связи

· Связь — ассоциация между сущностями (например, «Студент» учится на «Факультете»).
· Степень связи (кардинальность):
  · 1:1 — одному экземпляру A соответствует один B (и наоборот). Пример: Страна — Столица.
  · 1:M — одному A соответствует много B, но каждому B — только один A. Пример: Группа — Студенты.
  · M:N — многим A соответствует много B. Пример: Студенты — Дисциплины.
· Степень участия: обязательная (полная) и необязательная (частичная).

---

2.4. Модель «Сущность-Связь» (ER-модель)

Это графическая нотация для представления логической модели.

· Прямоугольник — сущность.
· Ромб — связь.
· Овал — атрибут.
· Линии — соединяют сущности и атрибуты.

Важно: В реляционной БД связь M:N реализуется через промежуточную (ассоциативную) таблицу, которая содержит внешние ключи обеих сущностей.

---

2.5. Типы данных (Домены)

Каждый атрибут имеет свой домен — множество допустимых значений. В СУБД домен реализуется через тип данных.

Классификация типов данных:

1. Символьные:
   · CHAR(n) — фиксированная длина (дополняется пробелами).
   · VARCHAR(n) — переменная длина (экономит место).
   · TEXT — для больших текстов.
2. Числовые:
   · INTEGER / INT — целые числа.
   · DECIMAL(p, s) / NUMERIC — точные дробные (p — всего цифр, s — после запятой).
   · FLOAT / REAL / DOUBLE — приближённые дробные.
3. Дата и время:
   · DATE — дата (ГГГГ-ММ-ДД).
   · TIME — время.
   · TIMESTAMP — дата + время.
4. Логические:
   · BOOLEAN — TRUE / FALSE.
5. Бинарные:
   · BLOB — большие двоичные объекты (картинки, файлы, аудио).

---

2.6. Классификация моделей данных

В теории выделяют три уровня моделей:

1. Концептуальная (инфологическая) — высокоуровневое описание (ER-модель). Не зависит от СУБД.
2. Логическая (даталогическая) — описание структуры для конкретной СУБД (реляционная модель: таблицы, столбцы, ключи).
3. Физическая — как данные хранятся на диске (файлы, индексы, страницы, кластеры).

---

2.7. Классификация СУБД по модели данных

1. Иерархические СУБД

· Данные представлены в виде дерева (родитель — потомок).
· Плюсы: быстрый доступ по иерархии.
· Минусы: жёсткая структура, сложно менять связи, избыточность.
· Пример: IBM IMS.

2. Сетевые СУБД

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

3. Реляционные СУБД (РСУБД)

· Данные в виде таблиц (отношений).
· Основа — реляционная алгебра и теория множеств.
· Плюсы: простота, гибкость, стандартизация (SQL).
· Минусы: сложность при работе с очень большими объёмами и сложными связями.
· Пример: MySQL, PostgreSQL, Oracle, MS SQL Server.

4. Объектно-ориентированные СУБД (ООСУБД)

· Данные в виде объектов (как в ООП).
· Плюсы: работа со сложными структурами (графика, мультимедиа).
· Минусы: сложность, отсутствие единого стандарта.
· Пример: ObjectStore, Versant.

5. Объектно-реляционные СУБД (ОРСУБД)

· Гибрид реляционных и объектных.
· Поддерживают таблицы + объекты, наследование, пользовательские типы.
· Пример: PostgreSQL, Oracle.

---

2.8. Проектирование БД (Этапы)

1. Системный анализ — сбор требований, интервью с заказчиком, определение границ предметной области.
2. Концептуальное проектирование — построение ER-диаграмм, определение сущностей, атрибутов и связей.
3. Логическое проектирование — перевод ER-модели в таблицы, нормализация, определение ключей.
4. Физическое проектирование — выбор типов данных, индексов, настройка СУБД (размещение на диске).

---

2.9. Нормализация (Подробно)

Цель — убрать дублирование данных и аномалии (вставки, удаления, обновления).

1НФ (Первая нормальная форма)

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

2НФ (Вторая нормальная форма)

· Уже 1НФ.
· Все неключевые атрибуты зависят от полного первичного ключа (если ключ составной — нет частичной зависимости).

3НФ (Третья нормальная форма)

· Уже 2НФ.
· Нет транзитивных зависимостей (неключевые атрибуты не зависят друг от друга).
· Пример: Если есть «Город» и «Страна», то «Страна» должна быть в отдельной таблице, чтобы не зависеть от «Города».

4НФ и 5НФ (кратко)

· 4НФ — борьба с многозначными зависимостями.
· 5НФ — борьба с зависимостями соединения (декомпозиция без потерь).

---

2.10. Целостность данных

· Физическая целостность — защита от сбоев (бэкапы, диски, RAID).
· Логическая целостность — защита от ошибок ввода (типы данных, ограничения, триггеры).
· Ссылочная целостность (Referential Integrity) — правило внешнего ключа:
  · Нельзя удалить родителя, если у него есть дети-записи (или удалять каскадно).
  · Нельзя вставить ребёнка, если нет родителя.
  · Обеспечивается механизмом FOREIGN KEY.

---

2.11. Жизненный цикл БД

1. Анализ требований (что нужно хранить).
2. Проектирование (концептуальное, логическое, физическое).
3. Реализация (создание таблиц, индексов, ограничений).
4. Эксплуатация (наполнение данными, запросы).
5. Модификация (изменение структуры при развитии системы).
6. Утилизация (архивирование или удаление).

---

2.12. Роли и участники

· Администратор БД (DBA) — отвечает за работоспособность, безопасность, резервное копирование, настройку СУБД.
· Разработчик БД — проектирует и создаёт структуру, пишет запросы и код.
· Конечный пользователь — работает с данными через приложения.
· Аналитик — собирает требования, описывает предметную область.

---

Братан, этого хватит, чтобы закидать препода «водой» и показать, что ты реально читал. Если надо ещё больше конкретики по каким-то таблицам (например, расписать все типы данных SQL с размерами или перерисовать ER-диаграммы в Markdown) — скажи, сделаю. Держи краба! ✊