Форум на Исходниках.RU https://forum.sources.ru Форум на Исходниках.RU Форум на Исходниках.RU https://forum.sources.ru/index.php?showtopic=414515&view=findpost&p=3795278 Wed, 10 Apr 2019 11:54:45 +0000 Нормализация до 3НФ, БД из 5 маленьких табличек https://forum.sources.ru/index.php?showtopic=414515&view=findpost&p=3795278 Цитата Akina @
Если поле будет ENUM - это 3НФ. Если text - это нарушение.

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

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

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

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

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

Как я понимаю, уникальность манагеров и покупателей достигается за счет ID, который никак не связан между собой в этих таблицах.
На данный момент в этой БД это есть проблема. Выход? Делать составной ключ, с привязкой, например к номеру паспорта? или соединять Манагера и Покупатель в единую сущность, типа "Person"?]]> FasterHarder Базы данных: SQL https://forum.sources.ru/index.php?showtopic=414515&view=findpost&p=3795276 Wed, 10 Apr 2019 11:22:38 +0000 Нормализация до 3НФ, БД из 5 маленьких табличек https://forum.sources.ru/index.php?showtopic=414515&view=findpost&p=3795276 Цитата FasterHarder @
одно из определений сущности такое (Сущность - это что-то такое, о чем нужно хранить информацию в базе данных)

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

Если поле будет ENUM - это 3НФ. Если text - это нарушение.]]> Akina Базы данных: SQL https://forum.sources.ru/index.php?showtopic=414515&view=findpost&p=3795265 Wed, 10 Apr 2019 08:49:36 +0000 Нормализация до 3НФ, БД из 5 маленьких табличек https://forum.sources.ru/index.php?showtopic=414515&view=findpost&p=3795265 Цитата Akina @
Что ещё за поле "Работает?"? тупо признак? тогда это поле избыточно, и признаком является NULL в значении поля "Причина увольнения".

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

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

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

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

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

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

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

кстати, да) я чего-то не додумал, что манагер может купить сам у себя авто). ну, запретим, конечно возможность приобретения манагерам машины в этом салоне (салон всего 1)]]> FasterHarder Базы данных: SQL https://forum.sources.ru/index.php?showtopic=414515&view=findpost&p=3795206 Wed, 10 Apr 2019 04:36:59 +0000 Нормализация до 3НФ, БД из 5 маленьких табличек https://forum.sources.ru/index.php?showtopic=414515&view=findpost&p=3795206 Цитата FasterHarder @
там есть поле "причина увольнения". Не является ли это транзитивной зависимостью от поля "Работает?"?

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

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

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

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

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

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

Выделение Менеджера и Покупателя в отдельные сущности возможно лишь в случае, если существует некое не имеющее исключение положение, запрещающее менеджеру приобретать автомобиль в этом автосалоне. Если такого запрета нет, то это одна сущность "Человек". Или "Субъект", если автосалон не против продаж автомашин юрлицам и иным объединениям.]]> Akina Базы данных: SQL https://forum.sources.ru/index.php?showtopic=414515&view=findpost&p=3795186 Tue, 09 Apr 2019 19:59:16 +0000 Нормализация до 3НФ, БД из 5 маленьких табличек https://forum.sources.ru/index.php?showtopic=414515&view=findpost&p=3795186 Нужно спроектировать БД, имитирующую автосалон, где продаются НОВЫЕ ЗАРУБЕЖНЫЕ авто.
Сущности:
Машина: Код, марка, год выпуска, фото, макс.скорость, цена, объем движка, продана?, тип кузова, код продавца
Менеджер: Код, фамилия, имя, отчество, дата рождения, фото, работает?, характеристика управляющего, причина увольнения
Покупатель: Код, фамилия, имя, отчество, дата рождения, фото, фин. баланс, пол, судим?
Роль: управляющий, менеджер, покупатель
Сделка: Код, код менеджера, код покупателя, код машины, дата сделки, отзыв покупателя

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

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

Схема БД:
_______________.png (, : 898)

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

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

спс. за внимание!]]> FasterHarder Базы данных: SQL