База данных CIS и полиморфизм компонентов, или как структурировать CIS Опции

[Hoodwin]

Можно ли организовать базу данных CIS таким образом, чтобы основной набор свойств компонентов хранился в одной большой таблице, а остальные данные хранились в дополнительных, более мелких таблицах, ссылающихся на базовую?
Ну, например, берем bench.mdb и видим, что таблица резисторов и конденсаторов по набору свойств почти совпадают. Строго говоря, все свойства, необходимые для CIS вообще совпадают, а некоторые физические свойства могут отличаться: у резисторов указывается мощность, а у конденсаторов - напряжение.
Мне такая организация не очень нравится. Хотелось бы иметь возможность в будущем вносить изменения в структуру базы данных. С большой вероятностью таковые изменения коснутся базового объекта, а не какого-то отдельного класса компонентов. Например, вот был раньше Layout и просто Footrint, а потом добавили Аллегро, и надо теперь уже в базе иметь два свойства - Layout PCB Footrint и Allegro PCB Footrint. при нынешней организации придется в каждой таблице прописывать новые поля, а так можно только в одной таблице прописать.

Я правильно думаю, что можно создать таблицу типа basic_cis, а потом во вкладке relational database прописать ее в качестве связанной таблицы для всех типов компонентов? И тогда в качестве связующего поля останется только part number? Или CIS использует для работы основную базу, а связанные только для просмотра свойств, и вся идея рушится?

[Hoodwin]

Сегодня поднял сервер, импортировал в него тестовую базу из Access, настроил сетевой доступ, SQC ODBC dat source, получил в итоге работу с CIS.
Потом создал простейшие две таблицы и объединил их при помощи View. В целом работает, так что можно ничего не мутить в настройках relational database у CIS. Нужно только грамотно таблицы создать.

Есть еще несколько вопросов.
1) Почему-то когда пытаюсь Save Query в CIS Explorer (вкладка Query), то capture вылетает с ошибкой.
2) Можно ли как-нибудь настроить тип поля voltage, tolerance и т.п., чтобы при поиске компонентов capture сравнивал числовое значение, а не строковое. Например, реши поискать конденсаторы по критерию voltage >= 60V, так получил только 63V, а 100V в список не попало, то есть он делал сравнение строк посимвольно.
3) Добавил в таблицу колонку Min_Temperature. Получил забавный эффект. Если в поисковом запросе написать Min_Temparature < -20, то оно показывает даже те компоненты, у которых этот параметр в точности равен -20. К чему бы это? В базе тип поля указан int.
4) Можно ли как-то пометить оригинальные таблицы в базе, чтобы их не путать с View при настройке CIS?

[vitan]

Сегодня поднял сервер, импортировал в него тестовую базу из Access, настроил сетевой доступ, SQC ODBC dat source, получил в итоге работу с CIS.
Потом создал простейшие две таблицы и объединил их при помощи View. В целом работает, так что можно ничего не мутить в настройках relational database у CIS. Нужно только грамотно таблицы создать.

Отлично. Труды мои не пропали зря.

2) Можно ли как-нибудь настроить тип поля voltage, tolerance и т.п., чтобы при поиске компонентов capture сравнивал числовое значение, а не строковое. Например, реши поискать конденсаторы по критерию voltage >= 60V, так получил только 63V, а 100V в список не попало, то есть он делал сравнение строк посимвольно.

А в базе тип указан числовой?

4) Можно ли как-то пометить оригинальные таблицы в базе, чтобы их не путать с View при настройке CIS?

Обычно таблицы используют для справочников и приписывают им префикс guide_.
А вьюхи я Вам советую называть по называнию схемотехнических библиотек.
У меня, например, на картинке они в правой колонке.

[Hoodwin]

Отлично. Труды мои не пропали зря.

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

А в базе тип указан числовой?

Не, для voltage тип указан не числовой а varchar. Но ведь Value обрабатывается ведь правильно, даже больше того, понимает единицы измерения и умеет по ним сравнивать, например, что 0.1uF > 470pF. И таких типов в принципе много: напряжение (конденсаторы, резисторы), ток (индуктивности), сопротивление (индуктивности), точность (все) и т.п.

Обычно таблицы используют для справочников и приписывают им префикс guide_.

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

А вьюхи я Вам советую называть по называнию схемотехнических библиотек.
У меня, например, на картинке они в правой колонке.

Я не совсем понял, Вы в CIS Explorer видите, например, IC_LOGIC\IC_LOGIC_BUFFERS, а не Logic\Buffers?
В общем нет никакой проблемы назвать вьюхи удобными названиями, скорее проблема в том, чтобы не показывать CIS'у никаких других названий, начиная от системных таблиц и заканчивая своими же вспомогательными.

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

[vitan]

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

Ну, лиха беда - начало... А что такое дефицитка?

Не, для voltage тип указан не числовой а varchar. Но ведь Value обрабатывается ведь правильно, даже больше того, понимает единицы измерения и умеет по ним сравнивать, например, что 0.1uF > 470pF. И таких типов в принципе много: напряжение (конденсаторы, резисторы), ток (индуктивности), сопротивление (индуктивности), точность (все) и т.п.

Если Value понимает правильно, то это неправильно. Любое число должно быть числом. Вы ведь базой собираетесь не только в оркаде пользоваться, сами же говорите. Поэтому смените тип на число, а с Value разбирайтесь отдельно.

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

Вы кого имеете ввиду под пользователем CIS? Схемотехник ничего другого и так не увидит, он будет выбирать компоненты из окошка в оркаде. А человеку, редактирующему конфигурацию CIS, можно просто объяснить, что все, что с префиксами guide_, например, не твоё.

Я не совсем понял, Вы в CIS Explorer видите, например, IC_LOGIC\IC_LOGIC_BUFFERS, а не Logic\Buffers?

Я в CIS уже не работаю (давно дело было). У меня в схематике виден просто линейный список библиотек, одна из которых называется IC_LOGIC_BUFFERS.
Но если привести эту картинку к CIS, то будет так: IC\LOGIC\BUFFERS, т.е. в виде дерева, а не просто линейный список (фактически - левая колонка, а не правая).

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

О, да. Поначалу меня тоже напрягало. Сейчас у меня уже около 70 библиотек, и новых почти не появляется. Один раз поработал пару дней, и теперь наслаждаюсь. Плюс, в новых версиях ментор (у меня ментор) наконец-то перешел на организацию описания связи библиотек с БД в виде XML, так что это теперь при желании это можно автоматизировать. Вот бы сразу бы еще это сделали, так вообще бы песня была бы.
Так что из этого следует только лишь обычная кривость\непродуманность софта (ладно, специально для Вас: отдельной части софта ), но никак не необходимость одной таблицы на все случаи жизни. Этой одной таблицей вся функциональность БД усыхает до уровня простой библиотеки, а то и еще пониже.

[Hoodwin]

Ну, лиха беда - начало... А что такое дефицитка?

Да уж...
Дефицитка (или ведомость дефицита материалов) - это такой документ, который отражает потребности в пополнении склада комплектующих с целью обеспечения производства заданного количества изделий готовой продукции. У нас пока используется построение сего документа на базе 1С:Производство, но там это реализовано несколько убого, из-за чего полноценного развития не получило. Причины такие:
1. Дефицитка от 1С не учитывает такого понятия как аналоги компонента. В результате склад может ломиться от деталей, а попадет в дефицит.
2. Насколько я помню, аналоги в 1С указываются в справочнике материалов, что вообще-то в отношении электроники неверно. Аналоги должны указываться в спецификации конкретного исполнения изделия, хотя и могут быть указаны в справочнике материалов, если действительно полные аналоги. Например, возьмем конденсатор по питанию X7R 0.1мкФ 25В 10%. Если он у меня стоит в цифровой схеме с напряжением 5В, то я могу считать его аналогом и конденсатор с напряжением и 10В, и 50В. А если он стоит в цепях источника питания на 24В, то мне вообще нужен только на 50В конденсатор. Или, другой вариант: можно ли считать аналогами свинцовую и бессвинцовую версию одной и той же микросхемы? По функциональности и собираемости на современных линиях - безусловно да, а по выполнению директивы ROHS - безусловно нет.
3. Дефицитка в простом виде не отслеживает динамику поступлений комплектующих. Если мы вчера сформировали дефицитку по деталям изделия А исполнения 1, после чего заказали их кратно катушкам, упаковкам, блистерам и т.п., а сегодня мы получили заказ на исполнение 2, в котором львиная доля деталей совпадает с исполнением 1, то сколько надо докупить? Реально можно заново начать строить дефицитку, указав в ней уже два вида изделий, и потом вычтя из общей суммы то, что уже заказано. Но это довольно быстро ведет к путанице, а бронирования деталей нет.
4. У нас со временем сложилась ситуация, когда бухгалтерия стала отказываться вставлять в нормативы изделия всякие дешевые детали вроде резисторов и конденсаторов, мотивируя это тем, что они в сумме не тянут и на 3% в себестоимости комплектующих, но при этом очень сильно затруднен учет их остатков, ну и вообще возни с ними много, а толку мало. Ну и в итоге из нормативов они стали исчезать, а при приходе катушки сразу списываются ввиду небольших цен. И вроде если для бух.учета такое упрощение вполне катит, то для обеспечения производства - совершенно не катит!

В общем, надо искать иные способы точного учета компонентов.

Если Value понимает правильно, то это неправильно. Любое число должно быть числом. Вы ведь базой собираетесь не только в оркаде пользоваться, сами же говорите. Поэтому смените тип на число, а с Value разбирайтесь отдельно.

Ну поле Value носит чисто OrCAD-овскую семантику, и я не хочу ничего в нем менять. Если мне будут нужны другие функции от базы, то я создам другие поля по мене необходимости. Здесь важно именно то, что Capture понимает, что Value - размерная величина и даже умеет понимать размерность. Если сделать value типа float, то размерность пропадет, а номинал станет неудобоваримым. Придется всегда помнить, по какому эталону размерности создана каждая база. Вопрос, как то же самое распространить на Voltage, Tolerance, Power, Current, и прочие физические параметры.

Вы кого имеете ввиду под пользователем CIS? Схемотехник ничего другого и так не увидит, он будет выбирать компоненты из окошка в оркаде. А человеку, редактирующему конфигурацию CIS, можно просто объяснить, что все, что с префиксами guide_, например, не твоё.

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

Но если привести эту картинку к CIS, то будет так: IC\LOGIC\BUFFERS, т.е. в виде дерева, а не просто линейный список (фактически - левая колонка, а не правая).

Так CIS выстраивает дерево в соответствии с полем Part_Type. Но первый уровень иерархии он называет по имени таблицы в базе. Поэтому если таблица называется IC_LOGIC_BUFFERS, она и будет так смотреться в иерархии. Вот если таблица будет называться Misc, а внутри будет раздел компонентов с Pаrt_Type = IC\Logic\Buffers, то тогда да, в СIS Explorer увидим иерархию \\Misc\IC\Logic\Buffers