Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.223.237.221] |
|
Данный раздел предназначается исключительно для обсуждения вопросов использования языка запросов SQL. Обсуждение общих вопросов, связанных с тематикой баз данных - обсуждаем в разделе "Базы данных: общие вопросы". Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ. |
Сообщ.
#1
,
|
|
|
Всем хай! Сходу к делу!
Нужно спроектировать БД, имитирующую автосалон, где продаются НОВЫЕ ЗАРУБЕЖНЫЕ авто. Сущности: Машина: Код, марка, год выпуска, фото, макс.скорость, цена, объем движка, продана?, тип кузова, код продавца Менеджер: Код, фамилия, имя, отчество, дата рождения, фото, работает?, характеристика управляющего, причина увольнения Покупатель: Код, фамилия, имя, отчество, дата рождения, фото, фин. баланс, пол, судим? Роль: управляющий, менеджер, покупатель Сделка: Код, код менеджера, код покупателя, код машины, дата сделки, отзыв покупателя По ролям. Управляющий может: принимать/уволнять манагеров, менять привязку авто-менеджер, докупать/снимать для/с продажи авто, получать любую сводную информацию (любые отчеты) Менеджер: получать отчеты только по своим сделкам, менять только свою личную карточку Покупатель: покупать новые авто, менять личную карточку, видеть только свою историю сделок Примечание: каждое авто привязано ТОЛЬКО к 1-у манагеру, либо не привязана ни к кому (т е еще не выставлена на продажу). Манагер может продавать множество авто одновременно. Схема БД: Прикреплённый файл_______________.png (26,41 Кбайт, скачиваний: 809) По нормализации: 1НФ: вроде все ок, ключевые поля + атомарность 2НФ: вроде все ок, т к нет ни одной таблицы с составным ключом 3НФ: ВОПРОС №1! Если посмотреть на таблицу "Менеджер", то там есть поле "причина увольнения". Не является ли это транзитивной зависимостью от поля "Работает?"? Если менеджер не уволен, то это поле я планирую держать со значением NULL. Или нужно создавать отдельную таблицу по уволенным сотрудникам, чтобы привести к 3НФ?? ВОПРОС №2! Стоит ли вынести инфо о типах кузовов в отдельную таблицу (справочник)? Их кол-во заранее известно и не меняется. ВОПРОС №3! Таблица "Роль" стоит особняком. Она нужна для определения типа пользователя в системе. Это нормально? спс. за внимание! |
Сообщ.
#2
,
|
|
|
Цитата FasterHarder @ там есть поле "причина увольнения". Не является ли это транзитивной зависимостью от поля "Работает?"? Что ещё за поле "Работает?"? тупо признак? тогда это поле избыточно, и признаком является NULL в значении поля "Причина увольнения". Цитата FasterHarder @ Стоит ли вынести инфо о типах кузовов в отдельную таблицу (справочник)? Их кол-во заранее известно и не меняется. Или вынести, или использовать ENUM. И то, и другое соответствует 3НФ. Цитата FasterHarder @ Таблица "Роль" стоит особняком. Она нужна для определения типа пользователя в системе. Это нормально? Это таблица-справочник, и я вообще не вижу оснований к тому, чтобы объявлять её сущностью. Цитата FasterHarder @ Сущности: Выделение Менеджера и Покупателя в отдельные сущности возможно лишь в случае, если существует некое не имеющее исключение положение, запрещающее менеджеру приобретать автомобиль в этом автосалоне. Если такого запрета нет, то это одна сущность "Человек". Или "Субъект", если автосалон не против продаж автомашин юрлицам и иным объединениям. |
Сообщ.
#3
,
|
|
|
Цитата Akina @ Что ещё за поле "Работает?"? тупо признак? тогда это поле избыточно, и признаком является NULL в значении поля "Причина увольнения". точно!, ведь статус работает/уволен не нужен будет уже... например, захотел управляющий посмотреть отчет по уволенным манагерам ---> select .... where reasonFired IS NOT NULL с этим моментом все ясно и 3НФ есть. Цитата Akina @ Это таблица-справочник, и я вообще не вижу оснований к тому, чтобы объявлять её сущностью. ну, я полностью с тобой согласен в этом плане. Просто я коряво ведать написал, что это сущность. но с др.стороны, одно из определений сущности такое (Сущность - это что-то такое, о чем нужно хранить информацию в базе данных). ну, не знаю, тут ведать в терминах тонкости всякие. Но как я понимаю, ведь все равно таблица такая нужна с паролями, как минимум. как я понял, в плане таблицы (не сущности) "РОЛЬ" все ок. Цитата Akina @ Или вынести, или использовать ENUM. И то, и другое соответствует 3НФ. вот кстати, когда в Пэинте проектировал инфо-,даталог.модель БД, то в скобках для типа кузова сначала написала (перечисление), но потом сделал как строчку. Но это ведь не так важно пока. вот ты говоришь, что нужно вынести в отдельную таблицу типы кузовов, но, ЕСЛИ МЫ ЭТОГО НЕ СДЕЛАЕМ, разве будет нарушение 3НФ?? Где возникают транзит.зависимости от поля "Тип кузова" в таблице "Машина"? От этого поля ничего больше не зависит в этой таблице. поясни этот момент, плиз Цитата Akina @ Выделение Менеджера и Покупателя в отдельные сущности возможно лишь в случае, если существует некое не имеющее исключение положение, запрещающее менеджеру приобретать автомобиль в этом автосалоне. Если такого запрета нет, то это одна сущность "Человек". Или "Субъект", если автосалон не против продаж автомашин юрлицам и иным объединениям. кстати, да) я чего-то не додумал, что манагер может купить сам у себя авто). ну, запретим, конечно возможность приобретения манагерам машины в этом салоне (салон всего 1) |
Сообщ.
#4
,
|
|
|
Цитата FasterHarder @ одно из определений сущности такое (Сущность - это что-то такое, о чем нужно хранить информацию в базе данных) А про её, сущности, самостоятельность, никто ничего не пишет? Вот будь у тебя к той роли привязано что-то, скажем, система прав (Покупатель - смотреть своё, Манагер - смотреть и править своё, смотреть остальное, Управляющий - может всё) - вот тут она бы и стала сущностью. А сейчас это ничто, словарный атрибут. Цитата FasterHarder @ ЕСЛИ МЫ ЭТОГО НЕ СДЕЛАЕМ, разве будет нарушение 3НФ?? Если поле будет ENUM - это 3НФ. Если text - это нарушение. |
Сообщ.
#5
,
|
|
|
Цитата Akina @ Если поле будет ENUM - это 3НФ. Если text - это нарушение. хм...интуитивно я понимаю, что надо бы ЕНУМ сделать, но, если брать офиц.треб. по 3НФ (пусть из Вики, надеюсь там точное описание): "2НФ + отсутствуют транзитивные функциональные зависимости неключевых атрибутов от ключевых". Тут не написано, что строку нужно заменять на ЕНУМ . Или этот тип кузова нарушает 1НФ или 2НФ, но вроде нет.. Может ты намекаешь на то, что тип кузова - нетривиальная зависимость, так опять вроде бы нет... не понимаю, если честно, почему ОБЯЗАТЕЛЬНО должен быть енум. Цитата Akina @ А про её, сущности, самостоятельность, никто ничего не пишет? Вот будь у тебя к той роли привязано что-то, скажем, система прав (Покупатель - смотреть своё, Манагер - смотреть и править своё, смотреть остальное, Управляющий - может всё) - вот тут она бы и стала сущностью. А сейчас это ничто, словарный атрибут. я может сейчас не то напишу), но ведь у меня такая привязка на уровне клиента очень жесткая есть. Т е появляется форма аутентификации, там выбирается тип пользователя: управленец, продажник, покупщик и пароль нужно ввести. В зависимости от этого будет отображаться тот или иной интерфейс с тем или иным функционалом. Цитата Akina @ запрещающее менеджеру приобретать автомобиль в этом автосалоне. еще про это хотел уточнить. а ведь в данный момент НЕТ никакой возможности запретить продавцу купить свой авто. Условно: пришел человек устраиваться на продажу машин, его управляющий взял + вбил по нему всю инфу (пусть ИД = 8 в табл. Менеджер). Он же оставил заявку на покупку и управляющий вбил по нему инфо (пусть ИД = 26 в табл. Покупатель) Как я понимаю, уникальность манагеров и покупателей достигается за счет ID, который никак не связан между собой в этих таблицах. На данный момент в этой БД это есть проблема. Выход? Делать составной ключ, с привязкой, например к номеру паспорта? или соединять Манагера и Покупатель в единую сущность, типа "Person"? |