Нужен совет новичку

Здравствуйте.
Во первых спасибо всем кто оказывал помощь, благодаря ей моя первая база неплохо работает и здорово облегчает мою работу. Теперь пришла очередь более сложной (для меня) базы. Пока нет ни таблиц, ни форм, есть только идея
Необходимо сделать базу для сервисного центра по учёту заказов запчастей, в голове это выглядит так:
Есть необходимый набор данных которые должны быть в базе,
1. номер заказа
2. Дата заказа
3. название клиента
4. Товар (до 5-ти штук разных артикулов)
5. список заказаных к нему запчастей (до 20-ти штук к каждому товару).
6. количество каждой запчасти
7. дата отправки заказа
8. дата получения
Сначала думал сделать одну таблицу и соответственно одну форму, но прочитав книги и форум понял что наверное лучше делать несколько таблиц и форму с подчинённой формой внутри. В форму вносятся данные о заказе (товар, клиент, номер, даты и т. д.) а в подчинённую данные о запчастях. Просьба моя такова, подскажите, как всё таки лучше, как разбить таблицы, какие установить связи, как лучше делать, через запрос или напрямую?
Понимаю что без черновика это тяжело, но нужно не готовое решение, а просто пару советов.

0

У Вас - обычная БД "Склад", "Продажи" и т. д....

ТаблицаЗаказов:
1. НомерЗаказа
2. Дата заказа
3. НомерКлиента
4. дата отправки заказа
5. дата получения

ТаблицаКлиентов:
1. НомерКлиента
2. Название клиента
3. ...

Связь: ТаблицаЗаказов.НомерКлиента=ТаблицаКлиен тов.НомерКлиента

Главныу форму и подчинённую лучше связывать через свойства «Подчиненные поля» (LinkChildFields), «Основные поля» (LinkMasterFields).

Добавлено через 2 минуты
ТаблицаЗаказ:
1. НомерЗаказа
2. НомерЗап_части
3. Кол_во

1

Сообщение от Михайло У Вас - обычная БД "Склад", "Продажи" и т. д....

База для отслеживания заказов на запчасти, но в принципе похожа очень на склад. Для меня самое сложное это привязать список запчастей к конкретному товару. Тоесть сервис присылает заявку в которой указан товар и список запчастей к нему, вот как их связать пока не понимаю, читаю щас О разработке структуры базы данных (для начинающих), думаю часть вопросов снимется. И всё таки, как лучше подчинённая форма или одна форма и через запрос?

0

Сообщение от Nigeriez как лучше подчинённая форма или одна форма и через запрос?

При работе с подчинённой формой, при правильной связи с главной формой, вам не нужно заморачиваться с ключевыми полями в подчинённой форме, внешний ключ будет заполняться автоматом, что весьма удобно. Также в таком случае всё наглядно для пользователя. Что касается unbound (свободные) форм, то они чужды Акцессу.

1

С таблицами вроде определился, теперь связи, вижу их примерно так, хотя могу и ошибаться.
Что скажите?

0

Интересная картинка. А где сама БД? По фотографии не лечим, это в другой салон
Пока только видно, что связи без ссылочной целостности и подозреваю наличие полей подстановок в таблицах.

И ещё: наименование товара с артикулом так интересно контачат, как валенок с розеткой

1

Сообщение от Nigeriez С таблицами вроде определился

Почитай про нормализацию. Главное -- осознай, зачем это надо. Тогда всё будет проще. Вот хоть это

1

Сообщение от alvk Интересная картинка. А где сама БД? По фотографии не лечим, это в другой салон Пока только видно, что связи без ссылочной целостности и подозреваю наличие полей подстановок в таблицах. И ещё: наименование товара с артикулом так интересно контачат, как валенок с розеткой

Собственно базы то пока нет, есть только пустые таблицы. Это моя вторая база (первая простенькая была, одна таблица и пара запросов), хочу сначала так сказать набросок сделать.
Артикул для каждого товара уникален, вот и связал их.

0

Nigeriez, Я думаю alvk хотел сказать что в таблицы "Формирование Заказа" и "Товары", нужно связывать не по Артикул -> Наименование товара, а по Артикул -> Код Товара. Да и в "Формирование Заказа" хранить наименование товара и наименование запчастей в общем то не нужно.
А вообще т.к. я тоже недавно Акцесс осваивать начал, пишу бд для продаж. То у меня сложилось мнение, что строковые данные типа ФИО, адресов, примечаний, должны храниться в тематических таблицах.
Например есть таблицы
1)Клиенты (ФИО, адрес, телефоны)
2)Товар(Артикул, Наименование, Цена)
3)Заказы(Код Заказа, Код Клиента, Код Товара, Кол-во)
И если в первых двух таблицах хранятся конкретные данные, то в третей хранятся в основном ссылки на эти данные + некая дополнительная инфа к заказу, как то количество и допустим общая сумма заказа(хотя и ее можно высчитывать по формулам уже после открытия конкретного заказа допустим).

1

Сообщение от Don1172005 Nigeriez, Я думаю alvk хотел сказать что в таблицы "Формирование Заказа" и "Товары", нужно связывать не по Артикул -> Наименование товара, а по Артикул -> Код Товара.

Да это я затупил, артикул и код товара это одно и тое, имя поля задал не правильно.

0

Кое что подправил, удалил лишние поля, вот только связи по полям "НомерЗаказа" вызывают сомнения (тип поля "счётчик").

Миниатюры

 

0

Сообщение от Nigeriez Кое что подправил

Так лучше, особенно если НомерЗаказа ты не собираешься использовать во внешнем мире. Для, скажем, печати чека или уведомления клиенту (чтоб мог, скажем, позвонить, назвать номер заказа и узнать, как дела) лучше таки завести внешний номер. И лучше текстовый...

Добавлено через 3 минуты
И -- я правильно понял, что задача не учебная? -- таки не очень понятно со складом. База подходит для ситуации, когда клиент делает заказ, то, что есть складывается в ящичек, остальное заказывается и по приходу ящик заполняется и заказ отправляется. У меня такое чувство, что жизнь несколько сложнее.

1

Nigeriez, я не вижу в ваших связях ссылочной целостности, отсюда и не видно характер связей, где там сторона один, а где много?

1

Сообщение от iifat И -- я правильно понял, что задача не учебная? -- таки не очень понятно со складом. База подходит для ситуации, когда клиент делает заказ, то, что есть складывается в ящичек, остальное заказывается и по приходу ящик заполняется и заказ отправляется. У меня такое чувство, что жизнь несколько сложнее.

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

Добавлено через 2 минуты

Сообщение от alvk я не вижу в ваших связях ссылочной целостности, отсюда и не видно характер связей, где там сторона один, а где много?

Наверное я бестолковый, пытаюсь понять это "один" и "много" второй день, куплю книжку сегодня, почитаю.

0

Сообщение от Nigeriez то что есть на складе отправляется сейчас, а чего нет, то заказывается и отправляется по мере поступления

По-моему, лучше вместо "Нет на складе" ввести "Отправки". Точнее говоря, две таблицы -- "Отправка" и "Товар на отправку". Не знаю, может, дело вкуса, но мне как-то больше импонируют таблицы, которые заполняются и не правятся (недостижимый идеал, конечно, ошибки были, есть и будут).

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

Сообщение от Nigeriez пытаюсь понять это "один" и "много"

Да чего там особо понимать... Строка, например, таблицы клиентов соответствует клиенту, строка заказов -- заказу, на одного клиента может приходиться много заказов, один заказ приходится на одного клиента -- значит, связь один ко многим, на стороне один -- клиент, на стороне "много" -- заказ, реализуется включением в таблицу на стороне "много" (заказ) полей из первичного ключа таблицы на стороне "один" клиента. Только и всего. И так по каждой отдельной связи.

1

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

Согласен с вами, но моя задача первичный заказ, то чего не хватает я для себя учитываю, а занимаются этим другие люди, у них своя система заказов и учёта, я им просто список скидываю, даже номер заказа не указываю. А клиент просто добавляет в следующий свой заказ то что ему не довезли и так по кругу. Через опу конечно, но такова политика компании. Так что отсутствующие запчасти тоже привязаны к заказу намертво.

0

Вроде разобрался, хотя сомнения остались, никак мне связи по полям "НомерЗаказа" покоя не дают, или я по неопытности напрасно дёргаюсь.

Миниатюры

 

0

Сообщение от Nigeriez Согласен с вами, но моя задача первичный заказ

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

Только убери ж наконец названия товара/запчасти из ФормированиеЗаказа! В таблице на стороне "много" должен присутствовать первичный ключ другой таблицы отношения -- а что у тебя там первичные ключи?

Кстати, что там с товаром и запчастью? Это что, действительно никак не связанные друг с другом понятия, как следует из твоей схемы?

1

Сообщение от iifat Кстати, что там с товаром и запчастью? Это что, действительно никак не связанные друг с другом понятия, как следует из твоей схемы?

Ну связь относительная, одна и та же запчасть может подходить к разному товару, есть конечно и уникальные но основная масса взаимозаменяемы.

Добавлено через 3 минуты

Сообщение от iifat Только убери ж наконец названия товара/запчасти из ФормированиеЗаказа! В таблице на стороне "много" должен присутствовать первичный ключ другой таблицы отношения -- а что у тебя там первичные ключи?

Если честно, то не совсем понял.

0

А я ж говорил -- надо почитать про связии, главное -- хорошо понять!

Таблица ФормированиеЗаказа связана с Товар отношением один ко многим с ФормированиеЗаказа на стороне "много" -- это ж из твоей схемы, так? Значит, она должна включать ключевые поля таблицы Товар -- и только ключевые, никаких других полей из Товара быть не должно!

1