3. Проектирование базы данных, нормальные формы
HTML-код
- Опубликовано: 4 окт 2017
- Ищешь VPS сервер для своих проектов за пределами РФ? Hostens уже тут))
Для начала идеально подойдет тариф Linux Small
(CPU: 1 x 2.60 GHz / RAM: 2 GB / Storage: 20 GB / Bandwidth: 4 TB / Port speed: 100 Mbps / KVM)
Чтобы максимально сэкономить, используй промокод в корзине hc50off и получишь доп. скидку 50% на VPS сервер. Вместо 64.80$ цена за 3 года будет всего 32.40$.
Оплата возможна не только картой. www.hostens.com/?affid=2336
Ищешь VDS/VPS сервер для своих проектов внутри РФ? FirstVDS тебе подойдет))
Лови скидку 25% на первый месяц аренды firstvds.ru/?from=527897 
Наука
![Megan Thee Stallion - Otaku Hot Girl [Official Audio]](http://i.ytimg.com/vi/USxIYOaIpig/mqdefault.jpg)
И что особенно офигенно, стиль обучения как бы через "наступание на грабли". Мы как бы натыкаясь на неудобства меняем свою БД. Очень здорово.
Ожидал встретить что-нибудь чего я не знаю, но нет тут материал исключительно для совсем новичков.
Должен похвалить автора, разжевывает очень хорошо.
Спасибо за разбор! Очень наглядное представление с помощью цветового выделения.
Хочу внести некоторые поправки и дополнения.
Таблица до разбиения на «Товары» и «Категории» уже соответствовала 2НФ - первичный ключ состоит из одного поля «Артикул» и все неключевые атрибуты полностью функционально зависят от ВСЕГО первичного ключа (нет частичных зависимостей от полей, входящих в первичный ключ).
Разбиение на «Товары» и «Категории» приводит БД к 3НФ, т.к. устраняет транзитивную зависимость между неключевыми атрибутами «Категория» и «Скидка». «Транзитивно» означает, что атрибут «Скидка» исходной таблицы зависит не только от ключевого поля «Артикул», но и от неключевого поля «Категория». Если быть более точным, то «Скидка» от ключевого поля «Артикул» вообще не зависит. «Скидка» = func(«Категория»).
«Тип» не зависит ни от атрибута «Артикул», ни от любого другого неключевого атрибута в таблице. То, что Вы сделали - защиту данных от опечаток и сохранение целостности данных таким образом. Наиболее вероятно, что при внесении информации в БД в такой структуре БД оператор будет выбирать бренд, тип и категорию товара из выпадающих списков (которые подтягиваются из доп. таблиц), а не вносить их вручную.
Альтернативный способ защиты данных - список допустимых значений, устанавливаемых на колонку. Конечно, для такого огромного списка, как бренды - это плохая идея. А вот для категории, которая, очевидно состоит сейчас из двух пунктов - «мужская», «женская», и в дальнейшем может быть дополнена либо еще одной - «детская», или же двумя - «мальчики», «девочки», можно обеспечить целостность с помощью Constrains на поле «Категория».
вы ошибаетесь, тип зависит от брэнда и от категории
На примерах разбирать - это меткое попадание в понимание слушателя
За пять минут узнал больше чем за год обучения в вузе...
Бросайте вуз у вас там все плохо.
Большое Вам спасибо за последовательное объяснение моделей форм.
Очень помогли.
Поднимайте в топ (лайк видео)
Этого контента могло не быть, человек пострался!
Хорошее описание, без страшных терминов, как в википедии. Большое спасибо! Но есть одно "Но".
В выводах определение 2-ой и 3-ей нормальной формы практически совпадают. Во 2-ой форме, если удовлетворяет 1-ой форме и "любое ее поле, не входящее в состав первичного ключа функционально полнотью зависит от первичного ключа". А теперь определение 3-ей формы: удовлетворяет 2-ой форме и "любой ее неключевой атрибут функционально зависит только от первичного ключа". Как видите фактически словосочетание "поле, не входящее в состав первичного ключа" просто заменено на "неключевой атрибут", что и сбивает с толку. Покопавшись в гугле я нашел иное определение 2-ой формы: удовлетворяет 1-ой форме и первичный ключ состоит только из одной колонки. Такое определение, на мой взгляд, больше соответствует повествованию.
во 2 НФ может быть составной первичный ключ (более чем одна колонка), но тогда любой неключевой атрибут должен иметь ПОЛНУЮ функциональную зависимость от первичного ключа (зависеть от всех частей первичного ключа а не только от одной из них)
Спасибо огромное за видео!
Спасли перед зачетом. Лайк-подписка-коммент с меня, и большое спасибо.
Наконец-то нашел стоящее видео
спасибо! все понятно))
спасибо, понятно объяснил
Спасибо 👍👍
хорошо рассказал
класс!
спасибо!
1,25 скорость воспроизведения норм.
Але ж скидка залежить не тільки від ID але і від категорії, що порушує правило 3-ї норм. форми(Будь-яке поле, що залежить від основного ключа та від будь-якого іншого поля, має виноситись в окрему таблицю.)
5:39 сексист
Ты дурачОк?
самые разработчики или архитекторы 0))) ахахаха
мерси
Кажется, автор сам не понимает о чем рассказывает. Говорит про вторую нормальную форму, а в примере - третья.. А то что, называет третьей нормальной формой, вообще отношения не имеет к нормальным формам. В заблуждение вводит. Поправьте, если ошибаюсь я
Не ошибаешься)
Последний пример больше похож на НФБК, когда требуется чтобы был только 1 потенциальный первичный ключ. Если 2, то такие данные надо вынести в отдельную таблицу