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

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

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

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

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

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

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

    спс. за внимание!
    Сообщение отредактировано: FasterHarder -
      Цитата FasterHarder @
      там есть поле "причина увольнения". Не является ли это транзитивной зависимостью от поля "Работает?"?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


            Рейтинг@Mail.ru
            [ Script execution time: 0,0273 ]   [ 16 queries used ]   [ Generated: 19.03.24, 10:40 GMT ]