Как применить нормализацию на MySQL с помощью PHP

Question

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

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

Answer 1

Хорошо, пара вещей:

1. php не имеет к этому никакого отношения. нормализация о данных моделирования
2. нормализация не сводится к экономии места на диске. Речь идет об организации данных таким образом, чтобы их было легко обслуживать, что, в свою очередь, является способом поддержания целостности данных.
3. нормализация обычно описывается в несколько этапов или «нормальных форм». На практике люди, которые проектируют реляционные базы данных, часто интуитивно понимают это правильно большую часть времени. Но все же хорошо знать о нормальных формах и их характеристиках. В интернете есть много документации по этому вопросу (например, http://en.wikipedia.org/wiki/Database_normalization),, и вам, безусловно, стоит провести собственное исследование, но наиболее важными этапами являются:

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

Пример многозначного столбца: персона (имя, фамилия, номера телефонов) Здесь номера телефонов означают, что в одном столбце может быть больше номеров телефонов

Пример повторяющейся группы: персона (имя, имя, фамилия, имя_детя_детей, имя_детей_детей_дата, имя_детей2, имя_детей_2, имя_детей_детей2 ..., имя_детей_детей, имя_детей_детей) Здесь таблица person содержит несколько пар столбцов (child_first_name, child_birth_date) для хранения дочерних элементов человека.

Обратите внимание, что что-то вроде order (shipping_address, billing_address) не является повторяющейся группой: адреса для выставления счетов и доставки могут быть похожими частями данных, но каждый из них имеет свою особую роль для заказа, и оба они просто представляют разные аспекты Заказ. child1 - child10 - нет - у детей нет определенных ролей, и список детей является переменным (вы никогда не знаете, сколько групп вы должны зарезервировать заранее)

В обоих случаях, многозначные столбцы и повторяющиеся группы, вы в основном имеете структуру "вложенной таблицы" - таблицу в таблице. Говорят, что данные представлены в 1NF (первая нормальная форма), если ничего из этого не происходит.

1NF - это структурная харакеристика: табличная форма данных. Все последующие нормальные формы связаны с устранением избыточности. Избыточность возникает, когда одна и та же информация хранится независимо несколько раз. Избыточность - это плохо: если вы хотите изменить какой-либо факт, вы должны изменить его в нескольких местах. Если вы забыли случайно один из них, у вас есть противоречивые данные - данные противоречат самим себе.

Существует множество процессов, которые могут устранить избыточность, каждый из которых приводит к более высокой нормальной форме, вплоть до 1nf до 6nf. Тем не менее, как правило, большинство баз данных адекватно нормализованы на уровне 3nf (или вариации блеска, называемой нормальной формой Бойса-Кодда, BCNF). Вы должны изучить 2nf и 3nf, но принцип очень прост: таблица адекватно нормализована, если:

1. таблица в 1nf
2. таблица имеет ключ (комбинация столбца или столбца, значения которой являются обязательными, и которая уникально идентифицирует строку - т. Е. Может быть только одна строка, имеющая эту комбинацию значений в столбцах ключа)
3. между неключевыми столбцами нет функциональных зависимостей
4. неключевые столбцы функционально не зависят от части ключа (но полностью функционально зависят от всего ключа).

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

позиция_ заказа (идентификатор заказа, номер товара, идентификатор клиента, код товара, описание товара, сумма)

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

Способ решить эту проблему - создать новую таблицу продуктов с (product_code, product_description), имеющей (product_code) в качестве ключа, а затем вместо того, чтобы хранить все поля продукта в заказе, хранить только ссылку на строку в продукте. таблица в записях order_item (в этом случае order_item должен хранить только product_code, что достаточно для поиска строки в таблице product и поиска product_description)

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

Answer 2

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

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

Например, взять столбец address

это не хорошо

update clients set address = 'new address' where clientid=500;
update orders set address = 'new address' where orderid=300;

хороший подход будет

create a addresses table
//and run a single query
update addresses set address = 'new address' where addressid=100;

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

На этот раз вам достаточно 3-го уровня нормализации.

Answer 3

На StackOverflow уже есть много похожих вопросов, например, Может кто-нибудь привести пример 1NF, 2NF и 3NF на простом английском языке?

Загляните в боковую панель Related справа, чтобы найти их. Это поможет вам начать.

Что касается ваших конкретных вопросов:

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

• Оператор INSERT ссылается только на одну таблицу. A TRIGGER в операторе вставки может добавлять строки в другие таблицы, но нет способа предоставить данные для триггера, кроме тех столбцов в таблице, которая его породила.

  Когда вам нужно вставить зависимые строки после вставки строки в родительскую таблицу, используйте функцию LAST_INSERT_ID(), чтобы получить автоматически сгенерированное значение первичного ключа последнего оператора INSERT в вашем сеансе ,

Answer 4

в phpmyadmin> 4.3.0, в структуре -> структура таблицы, мы получили над таблицей:

«Печать» «Предложить структуру таблицы» «Таблица отслеживания» «Переместить столбцы» «Улучшить структуру таблицы», в «Улучшить структуру таблицы» вы получили мастер, который говорит:

Улучшение структуры таблицы (нормализация):
Выберите до какого шага вы хотите нормализовать
Первый шаг нормализации (1НФ)
Второй шаг нормализации (1НФ + 2НФ)
Третий шаг нормализации (1НФ + 2НФ + 3НФ)

Answer 5

К вопросу 2: Нет, невозможно вставить данные в несколько таблиц одним запросом.
Смотрите синтаксис INSERT .

В дополнение к другим ответам, вы также можете найти здесь в SO для нормализации и найти, например, вопрос: нормализация в MySQL

Answer 6

Нормализация - это набор правил. Чем больше вы будете следовать, тем выше будет уровень нормализации в вашей базе данных. В общем, уровень 3 - это самый высокий уровень, к которому стремятся.

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

Однако, с практической точки зрения, нормализованные данные не всегда являются лучшим дизайном, даже если это теоретически. Если вы на самом деле не знаете тонкости, стремление к нормализованным данным не такая уж плохая идея.