Нормализация до 3НФ, БД из 5 маленьких табличек -> Форум на Исходниках.RU [Powered by Invision Power Board]

Версия для печати
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум на Исходниках.RU > Базы данных: SQL > Нормализация до 3НФ, БД из 5 маленьких табличек

Автор: FasterHarder 09.04.19, 19:59

Всем хай! Сходу к делу!
Нужно спроектировать БД, имитирующую автосалон, где продаются НОВЫЕ ЗАРУБЕЖНЫЕ авто.
Сущности:
Машина: Код, марка, год выпуска, фото, макс.скорость, цена, объем движка, продана?, тип кузова, код продавца
Менеджер: Код, фамилия, имя, отчество, дата рождения, фото, работает?, характеристика управляющего, причина увольнения
Покупатель: Код, фамилия, имя, отчество, дата рождения, фото, фин. баланс, пол, судим?
Роль: управляющий, менеджер, покупатель
Сделка: Код, код менеджера, код покупателя, код машины, дата сделки, отзыв покупателя

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

Примечание: каждое авто привязано ТОЛЬКО к 1-у манагеру, либо не привязана ни к кому (т е еще не выставлена на продажу). Манагер может продавать множество авто одновременно.

Схема БД:

_______________.png (, : 807)

По нормализации:
1НФ: вроде все ок, ключевые поля + атомарность
2НФ: вроде все ок, т к нет ни одной таблицы с составным ключом
3НФ: ВОПРОС №1! Если посмотреть на таблицу "Менеджер", то там есть поле "причина увольнения". Не является ли это транзитивной зависимостью от поля "Работает?"? Если менеджер не уволен, то это поле я планирую держать со значением NULL. Или нужно создавать отдельную таблицу по уволенным сотрудникам, чтобы привести к 3НФ??

ВОПРОС №2! Стоит ли вынести инфо о типах кузовов в отдельную таблицу (справочник)? Их кол-во заранее известно и не меняется.
ВОПРОС №3! Таблица "Роль" стоит особняком. Она нужна для определения типа пользователя в системе. Это нормально?

спс. за внимание!

Автор: Akina 10.04.19, 04:36

Цитата FasterHarder @ 09.04.19, 19:59

там есть поле "причина увольнения". Не является ли это транзитивной зависимостью от поля "Работает?"?

Что ещё за поле "Работает?"? тупо признак? тогда это поле избыточно, и признаком является NULL в значении поля "Причина увольнения".

Цитата FasterHarder @ 09.04.19, 19:59

Стоит ли вынести инфо о типах кузовов в отдельную таблицу (справочник)? Их кол-во заранее известно и не меняется.

Или вынести, или использовать ENUM. И то, и другое соответствует 3НФ.

Цитата FasterHarder @ 09.04.19, 19:59

Таблица "Роль" стоит особняком. Она нужна для определения типа пользователя в системе. Это нормально?

Это таблица-справочник, и я вообще не вижу оснований к тому, чтобы объявлять её сущностью.

Цитата FasterHarder @ 09.04.19, 19:59

Сущности:

Выделение Менеджера и Покупателя в отдельные сущности возможно лишь в случае, если существует некое не имеющее исключение положение, запрещающее менеджеру приобретать автомобиль в этом автосалоне. Если такого запрета нет, то это одна сущность "Человек". Или "Субъект", если автосалон не против продаж автомашин юрлицам и иным объединениям.

Автор: FasterHarder 10.04.19, 08:49

Цитата Akina @ 10.04.19, 04:36

точно!, ведь статус работает/уволен не нужен будет уже...
например, захотел управляющий посмотреть отчет по уволенным манагерам --->

<{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}>

select .... where reasonFired IS NOT NULL

с этим моментом все ясно и 3НФ есть.

Цитата Akina @ 10.04.19, 04:36

Это таблица-справочник, и я вообще не вижу оснований к тому, чтобы объявлять её сущностью.

ну, я полностью с тобой согласен в этом плане. Просто я коряво ведать написал, что это сущность.
но с др.стороны, одно из определений сущности такое (Сущность - это что-то такое, о чем нужно хранить информацию в базе данных). ну, не знаю, тут ведать в терминах тонкости всякие. Но как я понимаю, ведь все равно таблица такая нужна с паролями, как минимум.
как я понял, в плане таблицы (не сущности) "РОЛЬ" все ок.

Цитата Akina @ 10.04.19, 04:36

Или вынести, или использовать ENUM. И то, и другое соответствует 3НФ.

вот кстати, когда в Пэинте проектировал инфо-,даталог.модель БД, то в скобках для типа кузова сначала написала (перечисление), но потом сделал как строчку. Но это ведь не так важно пока.
вот ты говоришь, что нужно вынести в отдельную таблицу типы кузовов, но, ЕСЛИ МЫ ЭТОГО НЕ СДЕЛАЕМ, разве будет нарушение 3НФ?? Где возникают транзит.зависимости от поля "Тип кузова" в таблице "Машина"? От этого поля ничего больше не зависит в этой таблице.
поясни этот момент, плиз

Цитата Akina @ 10.04.19, 04:36

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

Автор: Akina 10.04.19, 11:22

Цитата FasterHarder @ 10.04.19, 08:49

одно из определений сущности такое (Сущность - это что-то такое, о чем нужно хранить информацию в базе данных)

А про её, сущности, самостоятельность, никто ничего не пишет? Вот будь у тебя к той роли привязано что-то, скажем, система прав (Покупатель - смотреть своё, Манагер - смотреть и править своё, смотреть остальное, Управляющий - может всё) - вот тут она бы и стала сущностью. А сейчас это ничто, словарный атрибут.

Цитата FasterHarder @ 10.04.19, 08:49

ЕСЛИ МЫ ЭТОГО НЕ СДЕЛАЕМ, разве будет нарушение 3НФ??

Если поле будет ENUM - это 3НФ. Если text - это нарушение.

Автор: FasterHarder 10.04.19, 11:54

Цитата Akina @ 10.04.19, 11:22

Если поле будет ENUM - это 3НФ. Если text - это нарушение.

хм...интуитивно я понимаю, что надо бы ЕНУМ сделать, но, если брать офиц.треб. по 3НФ (пусть из Вики, надеюсь там точное описание): "2НФ + отсутствуют транзитивные функциональные зависимости неключевых атрибутов от ключевых". Тут не написано, что строку нужно заменять на ЕНУМ

. Или этот тип кузова нарушает 1НФ или 2НФ, но вроде нет.. Может ты намекаешь на то, что тип кузова - нетривиальная зависимость, так опять вроде бы нет...
не понимаю, если честно, почему ОБЯЗАТЕЛЬНО должен быть енум.

Цитата Akina @ 10.04.19, 11:22

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

Цитата Akina @ 10.04.19, 04:36

запрещающее менеджеру приобретать автомобиль в этом автосалоне.

еще про это хотел уточнить.
а ведь в данный момент НЕТ никакой возможности запретить продавцу купить свой авто.
Условно: пришел человек устраиваться на продажу машин, его управляющий взял + вбил по нему всю инфу (пусть ИД = 8 в табл. Менеджер).
Он же оставил заявку на покупку и управляющий вбил по нему инфо (пусть ИД = 26 в табл. Покупатель)

Как я понимаю, уникальность манагеров и покупателей достигается за счет ID, который никак не связан между собой в этих таблицах.
На данный момент в этой БД это есть проблема. Выход? Делать составной ключ, с привязкой, например к номеру паспорта? или соединять Манагера и Покупатель в единую сущность, типа "Person"?