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

Question

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

0

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

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

user225269 24 янв. 2010, в 00:52

Источник

Теги:

php

mysql

phpmyadmin

normalization

6 ответов

2

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

Посмотрите на боковую панель Соответствующая справа, чтобы собрать их. Это поможет вам начать работу.

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

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

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

Bill Karwin 23 янв. 2010, в 21:25

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 нормализации достаточно для вас.

Pentium10 23 янв. 2010, в 20:38

0

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

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

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

Sérgio 27 март 2017, в 18:07

0

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

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

Felix Kling 23 янв. 2010, в 21:59

0

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

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

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

troelskn 23 янв. 2010, в 20:52

0

Вы получили хороший ответ, но не могли бы вы уточнить, когда не следует использовать нормализацию и когда это будет?
jerebear 23 янв. 2010, в 23:09
0

@jerebear Ну .. Это зависит. В общем, могут быть причины производительности для нормализации данных. Они в основном специфичны для работы конкретной базы данных. Если сомневаетесь, используйте нормализованные данные. Просто имейте в виду, что есть исключения из правил.
troelskn 24 янв. 2010, в 00:16

Ещё вопросы

Вы получили хороший ответ, но не могли бы вы уточнить, когда не следует использовать нормализацию и когда это будет?
@jerebear Ну .. Это зависит. В общем, могут быть причины производительности для нормализации данных. Они в основном специфичны для работы конкретной базы данных. Если сомневаетесь, используйте нормализованные данные. Просто имейте в виду, что есть исключения из правил.

Roland Bouman · Accepted Answer · 2010-01-23T20-55-00.000Z

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

php не имеет к этому никакого отношения. нормализация касается моделирования данных
Нормализация не касается экономии дискового пространства. Речь идет об организации данных, чтобы они были легко поддерживаемыми, что, в свою очередь, способ сохранить целостность данных. Нормализация обычно описывается в несколько этапов или "нормальных форм". На практике люди, которые разрабатывают реляционные базы данных, часто интуитивно "правили" в большинстве случаев. Но все же хорошо знать о нормальных формах и их характеристиках. В Интернете есть много документации по этому вопросу (fe

http://en.wikipedia.org/wiki/Database_normalization), и вы обязательно должны будете провести собственное исследование, но наиболее важными этапами являются:

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

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

Пример повторяющейся группы: person (first_name, last_name, child1_first_name, child1_birth_date, child2_first_name, child2_birth_date..., childN_first_name, childN_birth_date) Здесь таблица person имеет несколько пар столбцов (child_first_name, child_birth_date) для хранения дочерних элементов.

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

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

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

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

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

Функциональная зависимость

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

order_item (order_id, item_number, customer_id, product_code, product_description, amount)

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

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

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