Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Подскажите как грамотней спроектировать такую связь / 14 сообщений из 14, страница 1 из 1
02.02.2006, 15:00
    #33519221
iAndrew
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите как грамотней спроектировать такую связь
допустим есть у нас три сущности

Подразделение ID_Подразд
Человек ID_Сотрудник
Автомобиль ID_CAR

а мы являемся отделом по распределению автомобилей. Мы интегрированны в общую систему ЗАВОДА.
Причем у нас действует такое правило что сотрудники одного отдела ездят на машине одинаковой марки, но они могут перекрасить машину впоследствии в любой цвет, но изначально для всех машина черного цвета.

В итоге нужно чтобы в любой момент можно было вытянуть из базы, что в таком-то подразделении - ЧЕРНАЯ ВОЛГА (Например), но Сотрудник Иванов уже ездит на КРАСНОЙ ВОЛГЕ, а сотрудник Петров на БЕЛОЙ ВОЛГЕ

Теперь о том как это будет представлено в базе:

мой вариант..

Соединительная таблица
где или ID_Подразд или ID_Сотрудник равно NULL
ID_CAR NOT nULL, и с единственным сурогатным первичным ключом..
и DATE - дата выдачи в подразделении этих ЧЕРНЫХ ВОЛГ..

Правильно? или есть какиенить еще выходы из ситуации?
...
Рейтинг: 0 / 0
02.02.2006, 15:21
    #33519304
Серега
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите как грамотней спроектировать такую связь
Это на каком ЗАВОДЕ такими бирюльками занимаются? Уж не на ГАЗе ли?
...
Рейтинг: 0 / 0
02.02.2006, 17:15
    #33519784
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите как грамотней спроектировать такую связь
Правильности я у Вас не вижу. "Стандартная машина" - атрибут подразделения, и незачем засовывать ее в соединительную таблицу.

Но прежде чем говорить о правильности, стоит уточнить постановку задачи. Например, между сотрудниками и автомобилями прямо-таки напрашивается связь "многие ко многим". Кроме того, некоторые сотрудники могут быть младше 16 лет или по другой причине не иметь прав; и в том, и в другом случае описанный Вами сценарий явно имеет дыру.
...
Рейтинг: 0 / 0
03.02.2006, 07:50
    #33520743
iAndrew
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите как грамотней спроектировать такую связь
Сразу скажу - это абстрактная модель.. ничего неимеет общего с реальностью.
Просто возникла мысль, можно ли так организовывать соединение..

to softwarer
Попытаюсь развернуть задачу.

Проблема в том что автомобиль это не просто автомобиль - а набор деталей.
изначально каждый автомобиль состоит из 100 деталей (условно)
детали беруца из справочника, также есть справочник тип детали
в итоге деталь у нас - это таблица:

ID_Детали АВТО PK
ID_Детали FK
ID_Типа детали FK

посколько некоторые автомобили состоят из одинаковых деталей (например колесо в количестве 4 шт) то используем соединительную таблицу между сущностью Автомобиль(ID, Название, Год выпуска) и сущностью Деталь_Автомобиля

вид таблицы (ID_Детали_АВТО PKFK, ID_АВТОМОБИЛЯ PKFK, Колличество деталей)

Есть сущность Отдел и Сотрудник между ними связь Many-to-Many
между сотрудником и автомобилем Many-to-Many
Сотрудник может изменять набор деталей, но в подразделении должно всегда числиться базовая версия с базовым набором деталей.

Есть у меня такой ещё вариант, если сотрудников в отделе 10 человек, то внося авто в систему, мы делаем 10+1 копию одного и тогоже автомобиля причем 10 ID-шников фигурируют в соединительной таблице между Сотрудником и Авто, а один ID идет как внешний ключ в сущность отдел
...
Рейтинг: 0 / 0
03.02.2006, 10:27
    #33521059
ModelR
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите как грамотней спроектировать такую связь
Начните с формальной записи Ваших правил, с указанием наименования, кардинальности и обязательности связи и ее инверсии, скажем в нотации Баркера. Многое немедленно прояснится.
...
Рейтинг: 0 / 0
07.02.2006, 09:07
    #33527483
iAndrew
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите как грамотней спроектировать такую связь
Решил не создавать новую тему.. с предыдущими догадками вроде разрулил..

НО одна вещь не очень ясна:
Как реализовать одновременно понятие Базовый Автомобиль. и измененный автомобиль?
Пояснение:
Скомплектованый автомобиль - сущность, и с выделением нового автомобиля, мы добавляем ещё одну запись о автомобили с учетом количества всех его составляющих.. т.е. просто копируем базовую версию прекрепленную к отделу, имееющую более позднее время создание..
возможно ошибки при проектировании.. подскажите пожалуйста.

PS Прилагаю ER-модель.. возможно станет более понятна задумка
...
Рейтинг: 0 / 0
07.02.2006, 10:02
    #33527633
ModelR
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите как грамотней спроектировать такую связь
Крайние варианты :
1) Никак. после создания копированием измененная версия и исходная версия независимы, могут меняться произвольно, кто из кого копировал - не интересно. Запросом можно узнать отличия между любыми версиями.

2) Измененная версия - это строго базовая плюс изменения. Для каждой версии хранятся лишь отличия (+, -) от базовой (возможно пустой), а реальный состав вычисляется запросом.
...
Рейтинг: 0 / 0
07.02.2006, 10:56
    #33527854
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите как грамотней спроектировать такую связь
Блин , таблица выданных машин с двумя полями : изначальный цвет, текущий цвет.

Хотя проще всего запретить на фиг этим сотрудникам красить машины -- дешевле выйдет.
...
Рейтинг: 0 / 0
07.02.2006, 10:59
    #33527870
iAndrew
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите как грамотней спроектировать такую связь
нужно не только цвет .. а впринципе изменение деталей..

И в любой момент получить:
a) базовую конфигурацию для отдела
б) текущую конф. у сотрудника отдела
в) то какая кофигурация у данного сотрудника была базовой (проверяеца по году выдачи)
...
Рейтинг: 0 / 0
07.02.2006, 11:39
    #33528057
gardenman
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите как грамотней спроектировать такую связь
2 ModelR
По изменениям восстанавливать текущее значение - очень непроизводительно.

Моё предложение:

1) Таблица отделов ( DEPT_ID, DEPT_NAME) первичный ключ - DEPT_ID
2) Таблица людей (DEPT_ID,PERSON_ID, PERSON_NAME...,CAR_ID,CAR_ATTR_ID)
Первичный ключ - PERSON_ID,
(CAR_ID,CAR_ATTR_ID) - определяют машину и набор атрибутов на момент
когда сотруднику выделили машину.
3) Таблица машин (CAR_ID, ... условно-постоянные атрибуты...,LAST_CAR_ATTR_ID),
где LAST_CAR_ATTR _ID - указатель последний вариант изменяемых атрибутов
4) Таблица изменяемых атрибутов машин (CAR_ID,CAR_ATTR_ID,DT,...список изменяемых атрибутов машины) Первичный ключ на CAR_ID,CAR_ATTR_ID)

Таким образом имеем:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
select 
   (A.* -Атрибуты на момент выделения автомобиля сотруднику),
   (B.* -Атрибуты автомобиля на текущий момент ),
   (CAR.* - условно-постоянные атрибуты автомобиля)
from
   PERSON,CAR,CARATTR A,CARATTR B
where
   PERSON.CAR_ID=CAR.CAR_ID
   and (PERSON.CAR_ID,PERSON.CAR_ATTR_ID)=(A.CAR_ID,A.CAR_ATTR_ID)
   and (CAR.CAR_ID,CAR.LAST_CAR_ATTR_ID)=(B.CAR_ID,B.CAR_ATTR_ID)

Ну и внешних ключей понадобавлять :)
...
Рейтинг: 0 / 0
07.02.2006, 12:31
    #33528280
ModelR
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите как грамотней спроектировать такую связь
2 gardenman
Последний вопрос автора был не про историю атрибутов, а про состав (комплектацию) толи разных экземпляров, толи разных состояний одного экземпляра. В любом случае есть три множества - две комплектации (множества деталей) и разница между ними как множество пар <+|- , деталь>.

Проблема таже, что и в складском учете - что из этих трех связанных величин хранить?
...
Рейтинг: 0 / 0
07.02.2006, 12:36
    #33528308
gardenman
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите как грамотней спроектировать такую связь
Ну... я посмотрел на вот этомт пост:

И в любой момент получить:
a) базовую конфигурацию для отдела
б) текущую конф. у сотрудника отдела
в) то какая кофигурация у данного сотрудника была базовой (проверяеца по году выдачи)

Все это можно вроде бы можно получить в моем запросе....
А... ну его нафиг короче говоря...
...
Рейтинг: 0 / 0
07.02.2006, 12:53
    #33528384
iAndrew
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите как грамотней спроектировать такую связь
Спасибо всем за ответы но проблма разрешенной так и не осталась..

Видимо придеться делать простым копированием базовой машины с набором деталей столько раз - сколько у нас сотрудников..
а потом работать с каждым сотрудником и с его машиной индивидуально
...
Рейтинг: 0 / 0
07.02.2006, 13:08
    #33528446
iAndrew
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите как грамотней спроектировать такую связь
А вот теперь кажеться решилась :)
т.е. вообще не связывать машину с отделом.. ни с сотрудником.. а связывать с Сотрудник-Отдела
Копируем набор данных о машине на всех сотрудников отдела.
это и есть базовый автомобиль на сотрудников этого отдела.
при изменениях накапливать историю путем предков\потомков..
в любой момент можно получить базовый конфиг авто просто перейдя на корень дерева - он у всех сотрудников отдела одинаков..
и легко получить текущую ситуацию перейдя на конечный элемент дерева - у всех сотрудников конец свой..

Вот и всё.. Как вам такой выход?
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Подскажите как грамотней спроектировать такую связь / 14 сообщений из 14, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]