Рекомендации по дизайну таблиц базы данных

база данных

1. Связь между исходным документом и сущностью

Таблицы разрабатываются с отношениями «один к одному», «один ко многим» и «многие ко многим». В большинстве случаев оформление таблицы представляет собой отношение один к одному: то есть один исходный документ соответствует одному и только одному объекту.

В особых случаях это могут быть отношения «один ко многим» или «многие к одному», то есть один исходный документ соответствует нескольким объектам или несколько исходных документов соответствуют одному объекту. Сущности здесь можно понимать как базовые таблицы.

2. Первичный ключ и внешний ключ

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

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

3. Характер базовой таблицы

Базовая таблица отличается от промежуточной и временной таблиц тем, что имеет следующие четыре характеристики:

(1) Атомарность. Поля в базовой таблице неразложимы.

(2) Примитивность. Записи в базовой таблице — это записи исходных данных (базовые данные).

(3) Дедуктивный. Все выходные данные могут быть получены из данных в базовой таблице и кодовой таблице.

(4) Стабильность. Структура базовой таблицы относительно стабильна, и запись в таблице должна храниться длительное время.

Поняв природу базовых таблиц, вы сможете отличать базовые таблицы от промежуточных и временных таблиц при проектировании базы данных.

4. Стандарты парадигмы

Связь между базовой таблицей и ее полями должна максимально соответствовать третьей нормальной форме. Однако проекты баз данных, удовлетворяющие третьей парадигме, часто не самые лучшие. Чтобы повысить эффективность работы базы данных, часто необходимо снизить стандарт парадигмы: соответствующим образом увеличить избыточность для достижения цели обмена пространства на время.

"

[Пример 2]: Существует базовая таблица для хранения товаров, как показано в Таблице 1. Существование поля «количество» указывает на то, что структура таблицы не удовлетворяет третьей нормальной форме, поскольку «количество» можно получить путем умножения «цены за единицу» на «количество», указывая, что «количество» является избыточным полем. . Однако добавление избыточного поля «количество» может повысить скорость обработки статистики запросов, что является практикой обмена пространства на время.

В Rose 2002 существует два типа указанных столбцов: столбцы данных и вычисляемые столбцы. Такие столбцы, как «Сумма», называются «Рассчитываемыми столбцами», а такие столбцы, как «Цена за единицу» и «Количество», называются «Столбцами данных».

Таблица 1 Структура таблицы товарной таблицы Название продукта Модель продукта Цена за единицу Количество Количество ТВ 29 дюймов 2 500 40 100 000

5. Популярное понимание трех парадигм

Общее понимание трех парадигм очень полезно при проектировании баз данных. При проектировании баз данных, чтобы лучше применять три парадигмы, необходимо понимать три парадигмы общедоступным способом (популярное понимание — это достаточное понимание, а не самое научное и точное понимание):

Первая нормальная форма: 1NF — это атомарное ограничение на атрибуты, которое требует, чтобы атрибуты были атомарными и неразложимыми;

Вторая нормальная форма: 2НФ — уникальное ограничение записи, требующее, чтобы запись имела уникальный идентификатор, то есть уникальность сущности;

Третья нормальная форма: 3NF — это ограничение на избыточность полей, то есть ни одно поле не может быть получено из других полей, и это требует, чтобы поля не имели избыточности.

Никакая избыточная структура базы данных не может этого сделать. Однако база данных без избыточности не обязательно является лучшей базой данных, и иногда для повышения эффективности работы необходимо снизить стандарт парадигмы и должным образом сохранить избыточные данные. Конкретный подход таков: следовать третьей парадигме при проектировании концептуальной модели данных и учитывать работу по снижению стандартов парадигмы при проектировании физической модели данных. Понижение парадигмы — это добавление полей, допускающих избыточность.

6. быть хорошим в выявлении и правильном обращении со многими отношениями на многие

Если между двумя сущностями существует связь «многие ко многим», эту связь следует исключить. Способ устранить это — добавить третью сущность между ними. Таким образом, исходное отношение «один ко многим» теперь является отношением «два ко многим». Атрибуты исходных двух сущностей должны быть разумно распределены между тремя сущностями. Третий объект здесь представляет собой более сложную связь, которая соответствует базовой таблице. Как правило, средства проектирования баз данных не распознают отношения «многие ко многим», но могут обрабатывать отношения «многие ко многим».

"

〖Пример 3〗: В «библиотечно-информационной системе» «книга» является сущностью, и «читатель» также является сущностью. Связь между этими двумя сущностями представляет собой типичную связь «многие ко многим»: книга может быть взята несколькими читателями в разное время, и читатель может взять несколько книг. С этой целью между ними следует добавить третий объект, который называется «заем и возврат книг», и его атрибутами являются: время заимствования и возврата, флаги заимствования и возврата (0 означает заимствование книг, 1 означает возврат книг), Кроме того, он должен иметь два внешних ключа (первичный ключ для «книг», первичный ключ для «читалок»), чтобы его можно было связать с «книгами» и «читателями».

7. Метод значения первичного ключа ПК

ПК — это средство межтабличной связи для программистов, это может быть строка чисел без физического смысла, которая автоматически добавляется программой для ее достижения. Это также может быть физически значимое имя поля или комбинация имен полей. Но первое лучше второго. Когда PK представляет собой комбинацию имен полей, рекомендуется, чтобы количество полей не было слишком большим.Если количество полей слишком велико, индекс не только будет занимать много места, но и будет работать медленно.

8. Правильно распознать резервирование данных

Повторение первичных и внешних ключей в нескольких таблицах не относится к избыточности данных.Эта концепция должна быть ясной.На самом деле, многие люди до сих пор неясны. Повторение неключевых полей является избыточностью данных! И это низкоуровневая избыточность, то есть повторяющаяся избыточность. Расширенная избыточность — это не повторение полей, а их производное.

"

〖Пример 4〗: В товаре есть три поля «цена за единицу, количество и сумма». Цель избыточности — увеличить скорость обработки. Только низкоуровневая избыточность увеличит несогласованность данных, поскольку одни и те же данные могут быть введены несколько раз в разное время, в разное время и в разное время. Поэтому мы выступаем за избыточность высокого уровня (производная избыточность) и против избыточности низкого уровня (повторяющаяся избыточность).

9. Для диаграммы E-R нет стандартного ответа.

Для ER-диаграммы информационной системы нет стандартного ответа, потому что ее дизайн и метод рисования не уникальны, если они охватывают сферу бизнеса и функциональное содержание системных требований, это возможно. Вместо этого измените диаграмму E-R. Хотя у него нет единого стандартного ответа, это не значит, что его можно конструировать по желанию. Критериями хорошего графика ER являются: четкая структура, четкая ассоциация, умеренное количество сущностей, разумное распределение атрибутов и отсутствие низкоуровневой избыточности.

10. Промежуточные таблицы, отчеты и временные таблицы

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

11. Ограничения честности проявляются в трех аспектах

Целостность домена: проверка используется для реализации ограничений.В инструменте проектирования базы данных, когда определен диапазон значений поля, есть кнопка «Проверить», которая определяет значение поля. Ссылочная целостность: реализована с помощью триггеров PK, FK и триггеров уровня таблицы. Целостность, определяемая пользователем: это некоторые бизнес-правила, реализованные с помощью хранимых процедур и триггеров.

12. Способ предотвратить внесение исправлений в структуру базы данных — это «три маленьких принципа».

(1) Чем меньше таблиц в базе данных, тем лучше. Только при небольшом количестве таблиц можно показать, что E--R-диаграмма системы мала и уточнена, удалены избыточные и избыточные сущности, сформирована высокая степень абстракции объективного мира, интегрирована система данных. проводится, а латание предотвращается.

(2) Чем меньше полей комбинированного первичного ключа в таблице, тем лучше. Из-за роли первичного ключа один должен строить индекс первичного ключа, а другой должен служить внешним ключом подтаблицы, поэтому количество полей комбинированного первичного ключа меньше, что не только экономит время работы, но также экономит место для хранения индекса;

(3) Чем меньше полей в таблице, тем лучше. Только когда количество полей невелико, это может показать, что в системе нет дублирования данных и мало избыточности данных.Что еще более важно, это побуждает читателей изучать «столбец в строку», что предотвращает поля в подтаблице от переноса в основную таблицу, оставляя много пустых полей в основной таблице.

Так называемый «столбец-в-строку» заключается в том, чтобы вытащить часть содержимого из основной таблицы и создать отдельную подтаблицу. Этот метод очень прост, и некоторые люди просто не привыкают к нему, не перенимают его и не применяют.

Практический принцип проектирования базы данных заключается в том, чтобы найти правильный баланс между избыточностью данных и скоростью обработки. «Три несовершеннолетних» — это общее понятие, всеобъемлющая точка зрения, нельзя выделить определенный принцип.

Этот принцип относительный, а не абсолютный. Принцип «еще три» определенно неверен. Только подумайте: если охвачена одна и та же функция системы, диаграмма E-R из 100 объектов (всего 1000 атрибутов) определенно намного лучше, чем диаграмма ER из 200 объектов (всего 2000 атрибутов). . . .

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

Чем выше степень интеграции, тем сильнее обмен данными, тем меньше явление информационных островов и тем меньше количество сущностей, количество первичных ключей и количество атрибутов на глобальной диаграмме ER всей корпоративной информации. система.

Цель защиты принципа «трех маленьких» состоит в том, чтобы помешать читателям использовать технологию исправлений для непрерывного добавления, удаления и изменения базы данных, чтобы корпоративная база данных превратилась в «мусорную кучу» произвольно созданных таблиц базы данных или « сад» таблиц базы данных. Основные таблицы, кодовые таблицы, промежуточные таблицы и временные таблицы в базе данных неорганизованы и многочисленны, а информационные системы предприятий и учреждений не могут обслуживаться и парализованы.

Любой может использовать принцип «три-многие», который является ошибкой «метода патчей» для проектирования баз данных. Принцип "Три меньше" - это принцип меньшего, но лучшего. Он требует высоких навыков проектирования баз данных и искусства, которые не могут быть достигнуты никем, потому что этот принцип является теоретической основой для исключения использования "методов исправления" для проектирования баз данных.

13. Способы повышения эффективности работы базы данных

При заданных аппаратных и программных условиях системы способ повышения эффективности работы системы баз данных:

(1) В физическом проекте базы данных уменьшите парадигму, увеличить избыточность и использовать меньше триггеров

(2) Когда расчет очень сложный и количество записей очень велико (например, 10 миллионов записей), сложный расчет должен быть сначала выполнен вне базы данных, после расчета и обработки на языке C++ в файловой системе. режим, и, наконец, добавил в таблицу.

(3) Если обнаруживается, что в таблице слишком много записей, например, более 10 миллионов записей, таблица должна быть разбита по горизонтали. Практика горизонтального разделения заключается в разделении записей таблицы на две таблицы по горизонтали на основе определенного значения первичного ключа PK таблицы. Если обнаруживается, что в таблице слишком много полей, например, более 80 полей, то таблица делится по вертикали, а исходная таблица разбивается на две таблицы.

(4) При использовании для программирования языка SQL, ориентированного на данные, постарайтесь внедрить алгоритмы оптимизации.

Короче говоря, для повышения эффективности работы базы данных необходимо от оптимизации уровня системы базы данных, оптимизации уровня проектирования базы данных, оптимизации на уровне программы для достижения, в то время как усилия на этих трех уровнях.