Реляционная база данных состоит из следующих отношений

Реляционная база данных состоит из следующих отношений:

ПС(НП, ИП, ГП0, где ПС – поставщик, НП, ИП, ГП – номер, имя и город поставщика соответственно;
ДТ(НД,ИД,ВД,ЦД), где ДТ – деталь, НД,ИД,ВД,ЦД – номер, имя, вариант и цена детали соответственно;
ПТ(ПН,ПИ,СП,ГП), где ПТ – потребитель, ПН,ПИ,СП,ГП – номер, имя, статус и город потребителя соответственно;
ПДП(НП,НД,ПН,КЛ), где ПДП – поставщик-деталь-потребитель; КЛ- количество деталей с номером НД, поставляемых поставщиком с номером НП потребителю с номером ПН.

Построить следующие запросы:
- получить сведения о деталях, которые не пользуются спросом,
- получить полные сведения о потребителях деталей варианта А.




Я еще не очень понимаю как работать c SQL в Management Studio, но может быть кто-нибудь сможет помочь разобраться со всеми заданиями. Я буду пробовать что-то делать сам и сразу спрашивать правильно я делаю или нет.

Сначала нужно создать базу данных и создать таблицы. Таблицы я буду создавать следующие.

Имя таблицы 1: Поставщик
Строки: Номер поставщика, Имя поставщика, Город поставщика

Имя таблицы 2: Деталь
Строки: Номер детали, Имя детали, Вариант детали, Цена детали

Имя таблицы 3: Потребитель
Строки: Номер потребителя, Имя потребителя, Статус потребителя, Город потребителя

Потом в задании пункт ПДП, это как правильно оформить... тут уже как-то связь нужно сделать между таблицами.

Имя таблицы 4: ПДП(Поставщик - деталь - потребитель)
Строки: Колво деталей, Номер поставщика, Номер потребителя

Тут я не очень понимаю задание... как мне правильно оформить таблицу. Что в ней должно быть и как логически понять всю цепочку?

Теперь создаю Диаграмму и пытаюсь соединить таблицы.
Задаю первичные ключи в пунктах: Номер поставщика, Номер детали, Номер потребителя. В 4ой таблице подскажите как быть...

Прикрепил скрин, вот что получилось. Подскажите, что нужно переделать. Как нужно было правильно организовать таблицы, чтобы потом правильно создавать запросы?

Миниатюры

 

0

В таблице ПДП создайте колонку [Номер детали] - это будет внешний ключ к таблице Деталь.

Колонку [Цена детали] я бы перенес в таблицу ПДП - там у вас уже хранится [Кол-во деталей] и при подсчете суммы сделки вам не придется строить лишнюю связь в таблице Деталь.

- получить сведения о деталях, которые не пользуются спросом:
Строите запрос между таблицами Деталь и ПДП через LEFT JOIN - записи, у которых будет NULL в столбце ПДП.[Кол-во деталей] не пользуются спросом..

- получить полные сведения о потребителях деталей варианта А:
Строите запрос между таблицами Потребитель и ПДП через INNER JOIN с условием WHERE ПДП.[Номер детали] = 'А' - оставшиеся записи это заказы на деталь А. Перечислением всех колонок из таблицы Потребитель узнаете необходимую вам информацию. Если будут дублирующие записи, то устранить их можно через DISTINCT

1

Я не очень если честно понимаю как все это будет работать(. Буду пытаться разобраться в логике... и я не разу не делал запросы и тоже не очень понимаю что это. Попробую найти материал для чайников по запросам.

Вот что получилось. Так правильно?

Миниатюры

 

0

Не совсем, судя по схеме, у вас таблица деталь ссылается на таблицу ПДП, а должно быть наоборот, то есть как с поставщиками и потребителями.
Дальше наверно будет правильно в таблице детали сделать составной первичный ключ по детали и версии, чтобы пары значений не дублировались.
Ну и не вполне понятно зачем было переносить цену детали из каталога собсно деталей в своеобразную таблицу договоров, нелогично как-то, но это только мое мнение.

1

Значит сделать первичный ключ на "номер детали" и "версия". Версия это "вариант детали"? Но вариант это тип чар... его нельзя ключем делать. Получается в ПДП нету первичного ключа. Вот так получается? А про перенос строк в другую таблицу, давайте уже так оставим, и так многое не понятно(

Миниатюры

 

0

Оставляйте, это я так, к слову, база же ваша и работать с ней вам.
Да, вариант детали я имел в виду. В таблице детали пока ПК только номер. Получается одинаковых вариантов на этот номер может быть сколь угодно много. Вас это устраивает? Тогда все норм.
В таблице ПДП первичным ключом может быть связка "Номер детали - Номер поставщика - Номер потребителя".

1

Я не очень понимаю как оно там внутри все между собой будет работать... поэтому не могу четко сказать устраивает или нет.

Получается так, у каждой детали есть "Номер детали". И у каждой детали есть свой "Вариант детали". А почему тогда например на номер детали 1, будет несколько вариантов детали? Ведь при заполнении первой строки я укажу, что для первой детали будет определенный вариант.

Например:
|Номер | Деталь | Вариант
| 1 | Лонжерон | Левый,задний

Или потом при обращении к таблице Деталь, все как-то запутается и перепутается? Извиняюсь за мое чайничество и глупые вопросы, очень хочу разобраться, но все придет постепенно!

Сообщение от Kruds В таблице ПДП первичным ключом может быть связка "Номер детали - Номер поставщика - Номер потребителя".

А что значит связка? Я думал имеется в виду сразу 3 ключа может быть в таблице, но так нельзя...

Миниатюры

 

0

3 первичных ключа в таблице быть не может, а вот три поля в одном ПК пожалуйста.
Насчет деталей:
С ограничением только на номер получится что для каждой детали (читай для каждого номера) можно будет указать только один вариант, другой не вставится с таким номером. А вполне может быть ситуация когда хранить надо что-то такое:
1 Лонжерон Передний
1 Лонжерон Задний
1 Лонжерон Левый

Поищите в интернете книги или статьи по реляционным моделям, потому что прежде чем строить базу лучше все же разбираться в том что такое сущности, какие между ними могут быть отношения, ключи, нормалицазия.

1