предисловие
При проектировании таблиц в реляционных базах данных нам часто приходится учитывать, какие бизнес-поля должны быть помещены в какую таблицу, должны ли поля быть разделены и как должны быть связаны таблицы. Существуют ли какие-либо соответствующие нормы или принципы, которыми мы можем руководствоваться при разработке таблиц? Три парадигмы проектирования базы данных; три парадигмы в основном предназначены для решения проблем связи между таблицами и избыточности полей.
Следите за официальной учетной записью, общайтесь друг с другом и ищите в WeChat: Sneak forward
первая нормальная форма
- Столбцы не делятся. Цель первой нормальной формы — обеспечить атомарность каждого столбца, а каждый столбец — это наименьшая единица данных, которая не может быть разделена.
- Рост и вес — это два атрибута, которые нарушают первую нормальную форму и не могут быть разделены на один и тот же столбец.
- Дизайн в первой парадигме
вторая нормальная форма
- Во-первых, удовлетворяется первая нормальная форма, и в таблице нет столбца, не являющегося первичным ключом, который был бы независимым или частично зависимым от первичного ключа, гарантируя, что каждый столбец связан с первичным ключом. Как правило, из-за наличия нескольких первичных ключей или составных первичных ключей необходимо разделить таблицу.
- Есть составной первичный ключ (номер студента, предмет), но зачет предмета зависит только от первичного ключа раздела - предмета, что не соответствует второй парадигме.
- Правильная демонстрация второй нормальной формы
третья нормальная форма
- Вторая нормальная форма выполняется, и столбцы в таблице не имеют транзитивных зависимостей от столбцов, не являющихся первичными ключами, и каждый столбец напрямую связан со столбцом первичного ключа, а не косвенно
- В таблице баллов увлечения зависят от учащихся, а учащиеся зависят от идентификатора первичного ключа.При наличии транзитивной зависимости личная информация учащихся должна быть извлечена в виде таблицы.
- в соответствии со спецификацией третьей нормальной формы