База данных 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'у никаких других названий, начиная от системных таблиц и заканчивая своими же вспомогательными.

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