Есть ли в СУБД формальный принцип проектирования для конкретных объектов, такой как Course vs CourseSession?

Question

При проектировании схемы СУБД мне интересно, существует ли формальный принцип конкретных объектов: например, если это таблица Persons, то каждая запись является очень конкретной и уникальной. Каждая запись фактически представляет собой уникальную личность.

А как насчет стола типа Courses (как в школе). Он может иметь описание, количество единиц, предлагаемых только осенью (осень) или весной и т. Д., Которые являются «общими свойствами» курса.

И затем есть фактический CourseSessions, который содержит информацию о time_from и time_to (например, с 10 до 11 утра), будь то понедельник, среда или вторник / четверг, и преподаватель, обучающий его, и также указав назад, используя course_id к таблице курсов.

Таким образом, обе вышеуказанные таблицы необходимы.

Существуют ли принципы построения таблиц для «конкретных» и «абстрактных»?

Обновление: что я имею в виду под «абстрактным» здесь, так это то, что курс является абстрактной идеей ... может быть несколько его примеров ... например, курс физики 10 из 10-11 утра, и еще в 12-1 вечера.

Answer 1

например, если это таблица Persons, то каждая запись является очень конкретной и уникальной. Каждая запись фактически представляет собой уникальную личность.

Это надежда , но не реальность ситуации.

Из-за иммиграционного или юридического статуса смерти возможно наличие двух (или более записей), которые представляют одно и то же лицо. Трудно однозначно идентифицировать людей - во-первых, отчество и фамилии могут совпадать, но на самом деле отражают разных людей. SSN / SIN ненадежны, потому что они могут измениться (иммиграция, юридически умерла). Имя не гарантирует пол, и пол можно изменить.

Существуют ли принципы построения таблиц для "конкретных" и "абстрактных"

Классификация «конкретных» и «абстрактных» является произвольной и подлежит интерпретации. Действительно ли дата начала и окончания делает сессию курса «конкретной»? Потому что я могу бронировать множество вещей в [Программное обеспечение для календаря по выбору] - не значит, что класс действительно имел место, или что окончательные оценки являются законными значениями ...

Дизайн таблиц основан на бизнес-правилах, и логические объекты (которые могут стать таблицами в физической модели) необходимы для поддержки этих правил. Нормализация помогает сделать эти объекты более очевидными.

Answer 2

Реляционная модель данных, основанная на математике, доказывает способ разработки модели данных, в которой определенные операции выполняются без риска.

К сожалению, такая модель данных не подходит для решения проблемы производительности в базе данных. При организации таблиц для определенной бизнес-области необходимо учитывать не только абстрактную модель объектов или нормализацию базы данных, но и планирование производительности вашей системы. Да, утечка абстракции.

Например, есть две стратегии проектирования для древовидной структуры: модель смежности и модель материализованного пути ( Искусство SQL ). Какой из них лучше, зависит от того, какие операции необходимо оптимизировать.

Есть хорошая и классическая статья, которую я рекомендую: Закон Утечки Абстракций

Абстракция имеет свою цену (и она часто выше ожидаемой)
Кит Купер

Искусство SQL , конечно, душа дизайна базы данных на мой взгляд.