Когда применять принципы нормализации при создании ER-диаграммы

Question

Когда применять принципы нормализации при создании ER-диаграммы

0

Я новичок в базах данных.

В процессе разработки базы данных я знаю, что нормализация - это шаг, который возникает после создания таблиц.

Но следует ли применять некоторые принципы нормирования при создании ER Diagram? Если это возможно, это хорошая практика или лучше нормализовать после создания таблиц?

Tantaros 12 янв. 2018, в 10:55

Источник

3

Если вы создали таблицы, вам необходимо значительно изменить их, чтобы нормализовать их. Нормализация является частью процесса проектирования и должна выполняться до того, как вы начнете что-либо значимое в базе данных.
JohnHC 12 янв. 2018, в 09:40
1

Похоже, вы не отличаете логическое и физическое проектирование модели от реализации - как говорит JohnHC, вы бы делали все это до того, как прикоснулись к реальному серверу базы данных.
Andrew 12 янв. 2018, в 09:48
2

Моя любимая мозоль: люди ошибочно принимают дизайн ER за дизайн базы данных! Вы действительно должны всегда начинать с концептуального дизайна модели, выяснить свои основные вещи и их отношения. Затем перейдите на логический уровень, добавьте ключи и атрибуты и еще много чего. ТОЛЬКО тогда вы должны даже рассмотреть вопрос об открытии инструмента DBA.
Juha K 12 янв. 2018, в 10:15
0

Возможный дубликат Какой нормальной формы гарантирует схема ER?
philipxy 12 янв. 2018, в 10:32
0

Нормализация - это верный способ улучшить дизайн, заменив таблицу меньшими. Это просто часть хорошего дизайна. Следуйте опубликованному процессу информационного моделирования и реляционного проектирования. Моделирование отношений между сущностями Чена накладывает ненужные ограничения на конструкции и одновременно недооценивает их. Объектно-ролевое моделирование и другие члены семейства NIAM & FCO / IM меньше страдают от этого.
philipxy 12 янв. 2018, в 10:41

Показать ещё 3 комментария

Теги:

mysql

database

sql

entity-relationship

database-normalization

1 ответ

Ещё вопросы

Если вы создали таблицы, вам необходимо значительно изменить их, чтобы нормализовать их. Нормализация является частью процесса проектирования и должна выполняться до того, как вы начнете что-либо значимое в базе данных.
Похоже, вы не отличаете логическое и физическое проектирование модели от реализации - как говорит JohnHC, вы бы делали все это до того, как прикоснулись к реальному серверу базы данных.
Моя любимая мозоль: люди ошибочно принимают дизайн ER за дизайн базы данных! Вы действительно должны всегда начинать с концептуального дизайна модели, выяснить свои основные вещи и их отношения. Затем перейдите на логический уровень, добавьте ключи и атрибуты и еще много чего. ТОЛЬКО тогда вы должны даже рассмотреть вопрос об открытии инструмента DBA.
Возможный дубликат Какой нормальной формы гарантирует схема ER?
Нормализация - это верный способ улучшить дизайн, заменив таблицу меньшими. Это просто часть хорошего дизайна. Следуйте опубликованному процессу информационного моделирования и реляционного проектирования. Моделирование отношений между сущностями Чена накладывает ненужные ограничения на конструкции и одновременно недооценивает их. Объектно-ролевое моделирование и другие члены семейства NIAM & FCO / IM меньше страдают от этого.

Ron Ballard · Answer 1 · 2018-01-12T08-31-00.000Z

Как человек, который работал с базами данных на протяжении десятилетий, у меня давно возникла проблема с тем, что вы сначала проектируете базу данных, а затем переходите через этот теоретический процесс нормализации, чтобы исправить это. Это очень затянуто и включает в себя различную тематику (моделирование ER) и дорогие инструменты диаграмм.

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

Также важно понимать систему, которую вы моделируете, и то, что пользователи должны делать с ней. Лучший способ сделать это - работать с ним.

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

Это подразумевается в книгах Ruby on Rails (Сэм Руби и др.) И описано в моей (что вы можете найти в моем профиле, если вам интересно). Бесплатный ресурс https://www.w3schools.com/sql/default.asp очень хорош, но я думаю, что процесс создания хорошей базы данных там не очень доступен.

Да, я рад, что это работает для вас, но я лично не мог жить с таким процессом (прямо из бизнеса нужно create table )! Кроме того, что касается «дорогих инструментов для построения диаграмм», мой самый успешный опыт связан с публикацией на доске;)
Я согласен с этим ответом. Иногда я набрасываю диаграмму, но на самом деле они показывают таблицы (поэтому, если мне нужна таблица моста, она уже есть в моей диаграмме). Я также нахожу странным процесс запуска с ненормализованной базы данных. Я не согласен с тем, что w3schools хорош.
Спасибо @ Thorsten Kettner. Я тоже набрасываю диаграммы, но они маленькие и временные - просто для общения. Я мог бы сказать намного больше (и я имею в нескольких проектах и в моей книге). Знания, умение и дисциплина необходимы, безусловно, но большой предварительный дизайн тратит время и деньги.