Проектирование БД

• Анализ требований предметной области;

  • Составление USE CASES;

  • Аналитический процесс с участием stakeholders (владельцев, экспертов домена);

  • Концептуальная схема БД;

• Логическое моделирование данных предметной области;

  • Детализирует концептуальную модель БД;

  • Разные источники включают разные компоненты в логическую модель;

  • Полностью описывает все ключи;

  • Полностью определяет типы данных (без привязки к конкретной СУБД);

  • Полностью описывает все логические ограничения (спорно);

  • Нормализация отношений обычно максимум до формы 3НФ;

• Физическое проектирование и нормализация.

  • Выбирается конкретная СУБД;

  • Определяются типы данных;

  • Определяются индексы;

  • Могут определяться представления (views);

  • Определяются ограничения на доступ (security);

ER Diagrams

• Очень много платных инструментов для моделирования;

• MySQL Workbench;

• Oracle SQL Developer Data Modeler;

• pgModeler;

• SQL Power Architect.

Базовые советы по проектированию

• Таблица: объект, событие, абстракция;

• Поле (колонка): свойство объекта;

• Запись (строка): совокупность полей;

• Значения в каждом поле по отдельности не должны содержать невалидных данных;

• Значения в совокупности полей должны быть непротиворечивы.

Плохие практики

• Игнорирование нормализации - избыточность данных;

• Отсутствие стандартов именования в проекте;

• Одна таблица для разных по смыслу данных;

• Поле, содержащее более 1 логической части (full_name);

• Поле, содержащее более 1 значения (массив, когда не надо);

• Вычислимое поле (полная зарплата за время работы);

• Неправильно выбранные первичные ключи (ИНН - плохой PK);

• Избегайте композитных PK (может приводить к деградации производительности);

• В идеале, в таблице кроме суррогатного ключа, должен быть и натуральный.

• Правила иногда можно нарушать. Вычислимое поле дает performance boost? Делаем вычислимое поле...