На главную
ПРАВИЛА FAQ Помощь Участники Календарь Избранное DigiMania RSS
msm.ru
! информация о разделе
user posted imageДанный раздел предназначается исключительно для обсуждения вопросов использования языка запросов SQL. Обсуждение общих вопросов, связанных с тематикой баз данных - обсуждаем в разделе "Базы данных: общие вопросы". Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ.

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

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

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

Схема БД:
Прикреплённый файлПрикреплённый файл_______________.png (26,41 Кбайт, скачиваний: 21)

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

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

спс. за внимание!
Сообщение отредактировано: FasterHarder -
I originate
You must appreciate, all the others imitate

SCOOTER "GUEST LIST"

'Pon the mic I'm the teacher!
Spread my words like a preacher!
Yiiihhaaaa!!!!

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

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

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

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

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

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

Цитата FasterHarder @
Сущности:

Выделение Менеджера и Покупателя в отдельные сущности возможно лишь в случае, если существует некое не имеющее исключение положение, запрещающее менеджеру приобретать автомобиль в этом автосалоне. Если такого запрета нет, то это одна сущность "Человек". Или "Субъект", если автосалон не против продаж автомашин юрлицам и иным объединениям.
Сообщение отредактировано: Akina -
Есть претензии ко мне как к модератору? читайте Правила, разделы 5 и 6, и действуйте соответственно.
Есть претензии ко мне как к участнику? да ради бога.
Не нравятся мои ответы? не читайте их.
В общем, берегите себя. Нервные клетки не восстанавливаются.
Цитата Akina @
Что ещё за поле "Работает?"? тупо признак? тогда это поле избыточно, и признаком является NULL в значении поля "Причина увольнения".

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

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

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

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

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

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

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

кстати, да) я чего-то не додумал, что манагер может купить сам у себя авто). ну, запретим, конечно возможность приобретения манагерам машины в этом салоне (салон всего 1)
I originate
You must appreciate, all the others imitate

SCOOTER "GUEST LIST"

'Pon the mic I'm the teacher!
Spread my words like a preacher!
Yiiihhaaaa!!!!

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

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

Если поле будет ENUM - это 3НФ. Если text - это нарушение.
Есть претензии ко мне как к модератору? читайте Правила, разделы 5 и 6, и действуйте соответственно.
Есть претензии ко мне как к участнику? да ради бога.
Не нравятся мои ответы? не читайте их.
В общем, берегите себя. Нервные клетки не восстанавливаются.
Цитата Akina @
Если поле будет ENUM - это 3НФ. Если text - это нарушение.

хм...интуитивно я понимаю, что надо бы ЕНУМ сделать, но, если брать офиц.треб. по 3НФ (пусть из Вики, надеюсь там точное описание): "2НФ + отсутствуют транзитивные функциональные зависимости неключевых атрибутов от ключевых". Тут не написано, что строку нужно заменять на ЕНУМ :). Или этот тип кузова нарушает 1НФ или 2НФ, но вроде нет.. Может ты намекаешь на то, что тип кузова - нетривиальная зависимость, так опять вроде бы нет...
не понимаю, если честно, почему ОБЯЗАТЕЛЬНО должен быть енум.

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

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

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

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

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

SCOOTER "GUEST LIST"

'Pon the mic I'm the teacher!
Spread my words like a preacher!
Yiiihhaaaa!!!!

SCOOTER "WEEKEND"
1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
0 пользователей:


Рейтинг@Mail.ru
[ Script Execution time: 0,1171 ]   [ 21 queries used ]   [ Generated: 19.04.19, 06:58 GMT ]