|
Доброго времени суток, Посетитель!
|
|
|
|
|
|
|
|
|
вид форума:
|
| |
|
|
| | подскажите пожалуйста как реализовать связь многие к одному, т.е. возможность вбивания данных в таблицу с многими значениями, а оно само вносилось в таблицу с одним значением, надеюсь написал понятно! | |
| |
| |
| |
|
|
| | Объявление: "Куплю мелафон, срочно"
вар. № 1 -
Таблы: ТипТовара (Код_Типа, Название), Товар (Код_Товара, Название, Код_Типа)
речь идет о том чтобы при вводе через форму названия товара в таблицу Товары автоматом попадал выдленный (текущив в другой форме) Тип товара - для этого по окончании ввода названия или при сохранении Нового Товара необходимо написать типа этого
Me.Код_Типа=Forms!Тип_Товара!Код_Типа
и будет счастье.
вар. № 2
есть Справочник (назовем так) где хранятся названия,
в форму вносим данные, а оно само определяет новые данные (не существующие в справочнике, и заносит их туда.
имеет место быть, но:
1. если данные вноим ручками то вариаций написания одного и тогоже будет сотни, у юзеров фантазии выше крыши.
2. так заполнять форму - просто тратить время, для этого и ест справочник от куда и берутся данные, а уж обработку "Не существует в списке" найти не проблема.
3. если данные не вносятся блудливыми лапками, а идут потоком сос стороны то есть запрос на проверку существует ли Запись - Записи без подчиненных.
пример
SELECT Naimen.Kod_N, Naimen.Vid, Naimen.Naimen, Naimen.Tcena
FROM Naimen LEFT JOIN Sklad ON Naimen.Kod_N = Sklad.Naimen
WHERE (((Naimen.Kod_N)=1) AND ((Sklad.Naimen) Is Null));
|
(Naimen.Kod_N)=1 - проверяет код конкретного названия на наличие его на складе, если на складе есть товар то запрос ничего не содержит, если товара нет - содержит его название - 1 строчку. дальше заносим новое название куда нужно
п.с. Osmor - прикрепи виртуальный мелафон - для чтения мыслей, осеня нужьна вещь насяльника!!! | |
| |
| | |
|
| |
|
|
| | Спасибо!
Завтра попробую!
А про чтение мыслей - все мы учились чему-нибудь и как-нибудь... | |
| |
| |
| |
|
|
| | мелафон - для того чтобы понять что конкретно хотел человек который задал вопрос.
- Петька! Прибор?!!
- 120!!!!
- что сто двадцать?????
- а что прибор????
вот где-то так был сформулирован вопрос. | |
| |
| |
| |
 30 Кб. |
|
| | Человек я в этом деле новый, поэтому не судите строго (вообщем стараюсь черпать инфу откуда возможно).
С таблицами и запросами научился кое как работать формы для меня темный лес, мне этого хватило на то чтобы создать то что мне хотелось, но сцуко чтобы связать таблицы связью многие со многими мне приходиться вбивать данные два раза (что очень ненравиться), поэтому стараюсь облегчить себе жизнь теми способами которые знаю и понимаю.
Посмотрите пожалуйста! | |
| |
| |
| |
|
|
| |
но сцуко чтобы связать таблицы
|
очень плохо видно.
Приаттач или выложи в паблик ресурсе саму базу в А2003 формате
HINT: выброси из базы лишние данные и не забудь сжать прежде чем выкладывать | |
| |
| |
| |
|
|
| | Базу постараюсь принести в понедельник вечером | |
| |
| |
| |
|
|
| | в чем конкретно проблема, почему вводим по два раза? опиши подробно!!! | |
| |
| |
| |
|
|
| | Дополнительные файлы (рис) сбросил на файлообменик files.mail.ru/CCHNWG (810кБ)
Основная идея в присвоение обозначений конструкторской документации (№КД)(номер уникальный) - это реализовал за счет таблиц обозначение,1,2,4,7,8, журнал регистрации прочих изделий (вроде почти все устраивает). Потом решил завязать все это с заданием на проектирование КД(номер уникальный) и заказом на изготовление (номер уникальный). Проблема в том что задание,КД и заказ должны быть связаны друг с другом связями многие со многими. Постарался решить это промежуточной таблицей.Итог: вбиваю №задание в табл.задание, затем вбиваю №кд в таблице обозначение, потом вбиваю заказ в табл.заказ и затем уже через подтаблицу связываю это все. Получается так как мне и хочется , т.е. например нажимая на + у номера заказа вываливаются номера обозначений и заданий присущие ему и т.д. (могу объяснить только на суперюзерском языке)))). Но блин так не нравиться так много лазить по таблицам и вбивать это все дело. В идеале было бы Вбив №КД в т. обозначение через подтаблицу вбивать остальные значения и чтобы при этом заказ и задания попадали в соответствующие таблицы.
Возможно все это решается другими методами, но к сожалению пока умею только так...
ps: В дополнительных файлах есть еще вторая база, но она меня не совсем удовлетворяет | |
| |
| |
| |
|
|
| | для чего абзац придумали ТЫ никогда не задумывался? | |
| |
| |
| |
|
|
| |
нажимая на + у номера заказа вываливаются
|
этого никто кроме рабзработчика не должен видеть!!!!
это табла - куда доступ должен быть ограничен.
все должно делаться формами, их для этого и придумали.
структура однозначно другая - более структурированная
если есть связь Заказ-Кд (три таблы Заказы, Кд, и КД_на_Заказ она строится из первых двух) в сводной достаточно хранить только Код_КД_на_Заказ а не Код_Кд и Код_Заказ.
если конструктор работает в КБ (три таблы Отделы, Сотрудники, Персонал - код_Отдела и код_сотрудника) достаточно в сводной табле только код_Персонал. | |
| |
| |
| |
|
|
| | Извини, что неудобоваримо написал и спасибо за ответ!!!
Про формы понял, однако не получается без дополнительного внесения записей.
У меня более страшный (для меня) случай связь многие со многими в 3-х таблицах:.Заказ, КД и Задание. Как с этим?
И еще к сожалению характеристика КД подразумевает под собой более 600 таблиц, поэтому у меня такая каракатица с обозначениями! Мож что посоветуешь!?
Заранее спасибо! | |
| |
| |
| |
|
|
| | Нужно четко прдставлять что хотим, как формируется заказ и проч.
пример
таблы
1. Заказчик
2. Заказы заказчиков
3.0 Наименования /узлов, деталей, материалов, сборок/
3. КД (сборки, узлы, детали, элементы) - перечень Названий документов + Название из. табл 3.0 для того чтобы в ней не плодить названия, таким способм у одного названия может быть сотни различных исполнений.
4. КД состав - перечень элементов входящих в КД /для детали это список материалов, для узла - список деталей + материалы, для сборки - список узлов + список деталей /если они не входят в узлы + материалы/
5. Состав Заказа - перечень Кд (таблы № 3) и количество
для контроля выполнения создаем таблу - Испонение КД
Заказ, название Кд, кол-во, Чертил, Дата начала, дата окончания /или что нужно контролировать/
для производства на основании исполненных КД можно лепить лимитно-заборную карту.
И еще к сожалению характеристика КД подразумевает под собой более 600 таблиц
|
я ни в одном чертеже невидел характеристик для описания которых нужно 600 таблиц 
даже 600 полей это перебор.
кажись не правильно выражаешься, раскрой мыслю о 600таблах.
может 600 табл. - это 600 строк в описании КД, каждая строчка отдельный чертеж. так это нормально я думаю на Шатл поболе чертежей будет - но это не 600 табл.
это описывается:
1. Название_детали/узла/сборки
2. Чертеж(и)_на....
3. ТМЦ_на_чертеж........
все три таблы в первом приближении описали всю сборку хоть Шатла, хоть ручки.
не нужно добавлять Институт-КБ-Отдел-Проектное Бюро и проч. если ФИО чертившего связанно с местом работы. достаточно ФИО которое входит в эту струтуру
Институт-КБ-Отдел-Бюро-Сотрудник.
ох не зря по мелафон писал  | |
| |
| |
| |
|
|
| | Спасибо, что возишься со мной!
По поводу формирования базы в принципе:
1. Прежде всего хочу создать журнал регистрации КД(чертежа основной сборки).
В чем сложность - 600 характеристик это в данном моем конкретном случае, а так их может быть 10000.
Объяснюсь: шифр чертежа состоит из 8 чисел разделенных дефисом ХХХХ-ХХХХ.
Первые 4 цифры это и есть характеристика - например мерительный ин-т для измерения параллельность оси и поверхности или стенд для сборки поворотный в 2-х осях и регулировкой по высоте... . Уверяю что в шатлах эта разбивка по характеристикам более мелкая. Соответственно цифры от 0000 до 9999
Вторые 4 цифры это порядковый номер. К сожалению, счетчик применить не могу, т.к. иногда к порядковому номеру могут прибавиться литеры...
2. Далее мне хотелось бы "прицепить" задание на проектирование которое формируется вне моего отдела, однако имеющее свой уникальный идентификационный номер. По одному заданию может быть быть выполнено несколько чертежей и заказов на проектирование.
3. Есть еще заказ на проектирование. Номер присваивается тоже вне зависимости от конструктора. Заказу могут соответствовать несколько чертеже и несколько заданий.
Если упрощенно это основное, что необходимо. Хотелось бы чтобы данные вписывались с одной формы. Но как это сделать во-первых множество характеристик (на мой взгляд каждой хар-ке должен соответствовать своя табл.), во-вторых для анализа данных мне необходимо чтобы например заказы формировались в запрос множество к одному.
И еще она сложность иногда мне необходимо вместо обозначения чертежей вбивать прочие изделия (стандартные, покупные...(сверла, штагенциркули, гаиковерты...))
Попробовал это сделать в этой базе http://files.mail.ru/M5H5L9 (830кБ), регистрируется все через табл. и подтабл., а что делать чтобы множество данных соотносились с одним не вбивая их дважды х.з..
Можешь, что подсказать?! | |
| |
| |
| |
|
|
| | лучше помотреть на саму базу а не на скрины - понятней будет.
частями:
по рис. 1.3. - № задания, Заказ, № узла, Наименование Узла - это всё звенья одной цепочки описаной выше мной /это все может иметь много вариантов но смысл один/
Табла "Задания" - Код_Задания, Название_Задания
Табла "Заказ" - Код_Заказ, Название_Заказ, Код_Задания из таблы Задания
Табала Виды_Номенклатуры - Код_Вида, Название_Вида - /чертеж, узел, деталь, изделие, метариалы, ГСМ и прочие виды нашего перечня из чего может состоять заказ.
Табал Номенклатура - Код_Номенклатуры, Код_Вида, Название - чертежи, гайки, узлы, изделия
Табал "Узлы_на Заказ" - Код_Узла_На_Заказ, Код_Номенклатуры, Код_Задания
и когда вставляем в нашу сводную достаточно встать одно поле Код_Узла_На_Заказ - для того чтобы потом можно было вытащить всю цепочку.
точно так же обстоит дело с КБ-Конструктор
часть 2
шифр чертежа состоит из 8 чисел разделенных дефисом ХХХХ-ХХХХ.
|
опиши характеристики - хотябы с десяток /или выложи базу убрав секретные части информации /
принцып построения БД - структуризация, и как можно больше, тем гибче система - а если все характеристики чертежа /чего либо вообще/ тулить в одну таблу то никакая прога не выдержит такого издевательства - и человек, который будет это делать - тоже.
Мне кажется ты хочешь ОТЧЕТ представить в виде таблицы и его набирать - это не правильно.
Сводный отчет по чертежу, заказу, ЛЗК строится на основании запросов к разным таблицам на основе построенной структуры.
Пример - нет нужды создавать таблу №_Чертежа, Станок - если есть:
т. Четеж - Код_Чертеж, Шифр
т Опреционная_карта - №_Карты, Код_Чертеж
т Операции - Код_Операции, Название_Операции
т Оборудование - Код_Оборуд, Название
т Оборуд_на_Операци - Код_Оборуд_на_Операци, Код_Операции, Код_Оборуд
т Оперкарта_Операции - Код_Опрерации_в_Оперкарте, №_Карты, Код_Операции
все для построения отчета какие станци идут на чертеж нужно делать запрос
в виде цепочки Код_Чертеж-№_Карты/связь через т. Опреционная_карта/--Код_Операции /связь через т Оперкарта_Операции /--Код_Оборуд /связь через т Оборуд_на_Операци/
дальше как в анекдоте оставляем начало и конец получаем Код_Чертеж---Код_Оборуд
задача программиста и состоит в том чтобы этот анекдот заработал.
также должна получатся и твоя большая сводная табла по чертежу
еще раз положи базу а не скрины, и опиши характеристики которые хочешь впихнуть в этот несчастный чертеж | |
| |
| |
| |
29 Кб. |
|
| | Вот Классификатор - ничего секретного, он общероссийский.
задача программиста и состоит в том чтобы этот анекдот заработал.
|
К сожалению, не программист и не когда не имел к этому отношения - инженер -конструктор(вроде неплохой). Просто захотелось выйти за рамки своих узкоспециальных знаний на конкретном примере. | |
| |
| |
| |
24 Кб. |
|
| | вторая часть | |
| |
| |
| |
30 Кб. |
|
| | Попутал! В первых двух база разделенная на 2 тома раром, а здесь классификатор.
Добавил в таблицы экономической части.
Это дополнительно два отдела занимающихся заказами оснастки: один внутренними(в заводе), другой внешними.
Извини если повторюсь, но прежде всего что ожидаю от этого:основной задачей всего того бреда, что я набросал в своей базе это анализ данных и регистрация номера проекта.
Трудно сказать, что для меня является трудностью, т.к. судя по твоим комментариям двигаюсь совершенно не в том направление, но все же обозначу чего не понимаю:1. Как присваивать такое большое кол-во характеристик не заводя адекватное кол-во таблиц.
2. как сделать так чтобы конструктор вносил данные о задание, узле, оснастке, заказе в удобоваримой форме и при этом можно было проводить анализ поэтим значениям ((имею ввиду например в табличной форме увидеть перечень заданий их состояние и и заказы связанные с ними)или(тоже самое но с перечень заказо присущие им задания и обозначения КД))
Ну и что нибудь для экономистов.
Наверно, коряво написал, извини, трудный день!
Можешь что подсказать, кроме как внимательно прочитать инструкцию Access?
 | |
| |
| |
| |
15 Кб. |
|
| | 1.Вот посмотри. По принцыпу как сделана структра Фирма-Заказ-Платежи так нужно организовывать структуру базы, если нужно вести учет Заявок_на_Оплату (платежек на одину заявку м.б. много) - то создаем Заявка (Код_Заявки, №Заявки, Заказ), а в Платежах Поле Заказ меняем на поле Код_Заявки.
Вся таблца "Сводная" разбивается на несцолько цепочек таблиц (Проект (Заказчик, Название)--->ТЗ (Код_Проект, ТЗ)--->Узлы_на_ТЗ (Код_ТЗ, Узел, Кол-во)------->Состав_узлов (Код_Узла, Номенклатура, кол-во) если комплектация узла различна на разные ТЗ то так (Код_ТЗ, Код_Узла, Номенклатура, кол-во)
2. Если структура Иерархии (Вид_инструмента-Тип_Инструмент-Перечень_видов-Название) имеет четкие рамки вложенности, то можно создать нужное кол-во таблиц связанных между собой последовательно а данне из последней (Перечень_видов) - воткнуть в таблу Номенклатура.
Но тут есть жесткое условие ВСЯ цепочка должна быть прописана, не получится вставить Вид_инструмента в Номенклатуру "на прямую", все равно нужно будет создавать хотя бы один Тип_Инструмен и для него один Перечень_видов.
Я сделал для большого (неогрниченного) количества вложений табла - Разделы и Структура разделов.
3. Названия Полей и табл лучше писать на английском.
п.с. Извини времени очень мало. | |
| |
| |
| |
|
|
| | При беглом рассмотрении, не вникая в предметку:
1. Таблицы со странными именами "0" ... "8" заменяются двумя (разделы и классификатор) с "правильными" названиями таблиц и полей (именование ко всем таблицам относится).
Это разрулит странное "многие к одному".
2. Таблица "Сводная" разбивается на несколько (поиск по фразе "нормализация", и изучение),
дабы не "...смешались кони, люди..."
Вкратце. : ) | |
| |
| |
HiProg.com - Технологии программирования
|
