Cерьезные отношения: паттерны проектирования реляционных хранилищ

30 октября 2014 года
Серьёзные отношения:
паттерны проектирования
реляционных СУБД
Максим Зинченко
Oracle/Java разработчик

Кто я? Что я здесь делаю?
 Окончил МИФИ
 В IT работаю 13 лет
 Программирую – 20 лет
 Работаю в CUSTIS 5 лет
 Oracle => Java
2/69

План
 Вводная
 Паттерны?
 Парадигмы
 Паттерны для СУБД: что это?
 Отношения объектов
 Отношения классов
 Перекус
 Практика
Скучная
часть
Веселье
3/69

Паттерны
для проектирования СУБД
4/69

Паттерны?
 Что такое шаблоны проектирования?
 Стандартные решения типовых задач
 Зачем нужны?
 Передача опыта
 Упрощение коммуникаций
5/69

Парадигмы программирования
 Императивная (структурная, ООП, …)
Делай, что сказано!
6/69

 Декларативная
7/69

 Декларативная
 Функциональная
8/69

 Стандартный язык для СУБД – SQL
 SQL состоит из двух основных частей
 Описание структур (DDL)
 Описание запросов (DML)
 Обе части декларативные
9/69

 В приложении часто сочетаются
разные парадигмы
Императивная часть Декларативная часть
10/69

 Использование разных парадигм
 В основном эти части пересекаются
в сущностях и их отношениях
11/69

 Обычно императивной части уделяют больше
внимания
DDD
12/69

План
 Вводная
 Перекус
Мы здесь
13/69

Паттерны проектирования
 В основном проработаны
для императивных языков (особенно ООП)
 Нам не интересны поведенческие,
только структурные
 Почти все они есть в UML
 Такие паттерны можно реализовать
и в декларативной части
14/69

Паттерны проектирования
 Из модели должна следовать реализация
во всех частях программы
 Будем считать паттернами СУБД
адаптацию структурных паттернов,
используемых в модели,
к реляционной структуре
15/69

Паттерны отношений объектов
 Вводная
 Перекус
Мы здесь
16/69

Паттерны отношений объектов
 Отношения объектов разных классов
 Отношения объектов одного класса
17/69

Отношения объектов разных классов
 Отношения между экземплярами
 По UML:
 Ассоциации
 Агрегации
 Композиции
19/69

Схема для примеров
20/69

Ассоциации
 «Союз равных»
 Реализация сильно зависит от кратности
21/69

Один ко многим (1:N)
 Классический вариант – FOREIGN KEY
22/69

Один ко многим (1:N)
 Классический вариант – FOREIGN KEY
 Мягкая ссылка
 Часто делается отключенный FK
23/69

Один к одному (1:1)
 Сводим к 1:N
24/69

Один к одному (1:1)
 Сводим к 1:N
 Единый ключ (PRIMARY KEY)
25/69

Много ко многим (M:N)
 Всегда сводится к двум 1:N
 Например
А нужен ли он?
26/69

Много ко многим (M:N)
 Можно реализовать через NESTED с ключами
27/69

Агрегация
 «Слегка неравные» отношения
 Всё также как с ассоциацией, но:
 дополняем FK on delete set null
 аналогично для мягких ссылок правим код
28/69

Композиция
 «Сильно неравные» отношения
 Всё также как с ассоциацией, но
 дополняем FK on delete cascade
 аналогично для мягких ссылок правим код
29/69

Композиция
 Существует специальный способ реализации:
 вложенная таблица (NESTED)
 Используйте осторожно!
30/69

Отношения внутри одного класса
 Последовательность
 Иерархия
 Граф
 Синглтон
 Перечисление
31/69

Последовательность
 Что такое последовательность (sequence)
объектов?
 По сути это 1:1
{sorted}
32/69

 Сводим к 1:N и уникальности
 Заметили проблемы?
{sorted}
33/69

 Упорядочиваем по полю
34/69

 Упорядочиваем по полю
 Упорядочиваем по полю в контексте
35/69

Иерархия
 Что такое иерархия объектов?
 Глава 1
 Глава 1.1
 Глава 1.2
 Глава 1.2.1
 Глава 1.3
 Глава 2
…
 По сути это 1:N
36/69

Иерархия
 Реализуем как 1:N через FK
37/69

Иерархия
 Реализуем как 1:N через мягкую ссылку
38/69

Иерархия
 Особый способ реализации
 Путь к файлу
C:WindowsSystem32cmd.exe
 Нумерация разделов в оглавлении
Глава 1.7.4
39/69

Иерархия
 Особый способ реализации
 Уникальность полного пути
 Возможны ссылки на полный путь
40/69

Иерархия
 Иногда используется для ассоциаций
 Это не совсем целевое назначение,
но иногда допустимо
 Все паттерны для одного класса
ограниченно применимы для разных классов
41/69

Граф
 Что такое граф?
42/69

Граф
43/69

Граф
 Это отношение N:M внутри одного класса
44/69

Граф
 Ориентированный
 Реализуем N:M между узлами
 Не ориентированный
 Храним как ориентированный с правилом
упорядочивания
 Храним по два ребра
45/69

Граф
 Бойтесь графов!
46/69

Циклы
 Циклы могут быть во всех перечисленных
отношениях
 Проверка
Проверка циклов не тривиальна
Нельзя наложить простое условие
на отсутствие циклов (только триггер)
47/69

Синглтон (Одиночка, Singleton)
 Что такое синглтон?
 Что такое хранимый синглтон?
 Необязательный (0–1)
 Запрет создания новых
 Права, триггеры, ограничения
уникальности…
 Обязательный (1–1)
 Запрет удаления
 Права, триггеры, …
48/69

Перечисление (enumeration)
 Что такое перечисление?
 Строго заданный набор объектов
 Можно не хранить в СУБД
 Строковое поле с идентификатором
и ограничением CHECK
 Можно хранить как обычную сущность
 Удобство ссылки на строковый код
49/69

Паттерны отношений классов
 Вводная
 Перекус
Мы здесь
50/69

Отношения классов
 Отношения между классами,
а не экземплярами
 Отношения между объектами
метаинформации
51/69

Отношения классов
 Наследование (обобщение)
 Реализация (интерфейс)
 Зависимость
 Рефлексия (поведенческий)
52/69

Наследование (обобщение)
 Наследования поведения почти нет,
в основном структура
53/69

 А нужно ли на уровне хранения учитывать
наследование?
Не имеет отношений
54/69

Имеет отношения
55/69

 Будут ли в отношениях объектов
участвовать предки?
 Нет = можно не рассматривать классы
как связанные
 Да = придется рассматривать
56/69

 Одна таблица и дискриминатор
Humans
id type sex birthday name degree
1 PROFESSOR M 02/03/76 Иванов И. П. CANDIDATE
2 STUDENT M 01/07/94 Петров С. И.
3 PROFESSOR F 05/12/63 Сидорова А. Е. DOCTOR
4 STUDENT F 17/10/95 Неизвестная А. М.
5 STUDENT M 04/02/95 Криворуков П. Р.
57/69

 Разбиение на таблицы
id type sex birthday name
1 PROFESSOR M 02/03/76 Иванов И.П.
2 STUDENT M 01/07/94 Петров С.И.
3 PROFESSOR F 05/12/63 Сидорова А.Е.
4 STUDENT F 17/10/95 Неизвестная А.М.
5 STUDENT M 04/02/95 Криворуков П.Р.
Humans
Students Professors
id
2
4
5
id degree
1 CANDIDATE
3 DOCTOR
58/69

 Нужен ли здесь дискриминатор?
59/69

 Множественное наследование
60/69

Реализация (интерфейс)
61/69

 Обычно реализуется через представления
CREATE VIEW CODED_ENTITY AS
SELECT id, code FROM …
UNION ALL
SELECT code FROM …
…
62/69

 Обычно реализуется через представления
63/69

 Можно реализовать как множественное
наследование
64/69

Зависимость
 Можно реализовать через триггеры на DDL
или автогенерацию
65/69

Рефлексия
 В стандарте нет
 Практически во всех СУБД доступна
 Есть в стандартных обертках для СУБД
(JDBC…)
66/69

План
 Вводная
 Перекус
Мы здесь
67/69

Спасибо!
Вопросы?
Максим Зинченко
zinchenko@custis.ru
69/69

Cерьезные отношения: паттерны проектирования реляционных хранилищ

More Related Content

Similar to Cерьезные отношения: паттерны проектирования реляционных хранилищ (20)

More from CUSTIS (20)

Cерьезные отношения: паттерны проектирования реляционных хранилищ