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

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

А можно полюбопытствовать, зачем? Особенно учитывая идеологию Аллегро, где схематик на 99% отвязан от footprint. Оставшийся 1% это лишь "рекомендуемый" footprint, который может вообще отсутствовать в схематике.

Советую Вам не пользоваться возможностями редактора CIS, а подготавливать необходимые виды (таблицы) средствами СУБД. При этом Вы никогда не столкнетесь с проблемами при изменении структуры БД, точнее, эти проблемы не отразятся на работе схемотехников. Конкретно по организации хранения свойств компонентов можете посмотреть ветку про БД в разделе альтиума, я там приводил картинки со структурой для SQL Server. Там приведена не самая совершенная структура, но для начала очень даже сгодится. Сейчас же я продвигаю организацию хранения свойств для компонентов наподобие того, как это сделано в SharePoint, это имхо наиболее продвинутый вариант...

Почти ничего не понял из написанного
Вроде бы конкретные вопросы задал про организацию таблиц, а не про редактор.

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


Кстати - да, вопрос не без оснований. В смысле - почему для аллегро нужна отдельная запись о футпринте? Разве не достаточно того, что было записано для какого-либо другого САПРа?

vitan, ну вот опять Вы мне про редактор... Я вообще о другом тему поднял исходно. Попробую объяснить в терминах С++. Вот смотрите, есть несколько объектов следующей структуры:


Как видим, довольно приличное число полей идентично для разных типов данных, и лишь незначительное количество отличается. В концепции объектно-ориентированного программирования принято такие структуры оформлять в виде наследования:


Это не просто отражает суть структуры, а делает удобным развитие базы в будущем. Например, допустим, что в ТЗ есть требование спроектировать устройство под расширенный температурный диапазон. И теперь мы хотим формализовать применимость компонентов по такому критерию, то есть, мы хотим для всех компонентов добавить в качестве базовых свойств минимальную и максимальную температуры. В случае простой системы таблиц мы должны в каждую таблицу добавить два параметра. В случае иерархии с наследованием нам достаточно внести изменение только в базовую счасть - struct BasicComponent:

Собственно, пример футпринта тоже был взят для иллюстрации именно развития базовых свойств компонента по мере усложнения набора применений БД. Но, - оказался неудачным, поэтому я не буду его далее обсуждать.
Мое мнение заключается в том, что гораздо более вероятно, что если в будущем потребуются какие-либо изменения в структуре таблиц, то они будут относиться к базовым свойствам (базовому классу в терминологии ООП), а не к частным. Конечно, частные свойства наследованных классов тоже могут меняться, но это будет носить менее регулярный характер. Ну, например, тонкопленочные резисторы тоже можно характеризовать предельным напряжением пробоя в пленке, и этот параметр будет важен для высокоомных резисторов. А для подавляющего большинства т.н. general purpose резисторов такой параметр обычно остается вне внимания проектировщика. Как вариант, можно пытаться добавить этот параметр в таблицу резисторов.

Итак возвращаюсь к исходной проблематике. Реализовать такое наследование средствами БД можно с помощью related tables. Для этого придется правда в таблице наследованных свойств повторить какое-нибудь ключевое уникальное свойство. Тогда структура таблицы резисторов будет выглядеть примерно так:


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

Зря вы не хотите послушать. Лекция про наследование лишняя, я Вам то же самое пытаюсь объяснить с самого начала. Только вы хотите это сделать в редакторе, а я Вам говорю, что это делать надо в СУБД.

В каком редакторе? Речь о настройках взаимодействия CIS с базой данных.

В том, в котором Вы собираетесь прописывать связанные таблицы. Который вызывается нажатием кнопки редактирования .dbc.

Так я вообще-то хотел прописывать таблицы в каком-нибудь Microsoft SQL Server Management Studio. Но все равно, где бы они ни были созданы и связаны, их нужно правильно настроить для взаимодействия с CIS. Все что я хочу выяснить, так это то, умеет ли CIS работать со связанными таблицами в Part Managere, то есть, когда часть важных свойств находится в связанной таблице. насколько я понимаю, если у меня таблица Resistors содержит только ссылку на стандартные свойства в таблице стандартных свойств, то при попытке написать для нее SELECT с указанием выборки по любому стандартному свойству сервер откажется, сказав что таких свойств в таблице resistors нет. И для правильного поиска нужно будет либо View создать и там искать, либо писать более сложный select, вроде "найти все такие записи в таблице Resistors, у которых в связанных с ними основных данных свойство X равно Y".

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

Если коротко: делайте View на каждую библиотеку. Там все будет видно.

Сегодня поднял сервер, импортировал в него тестовую базу из 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?

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


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


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

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


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


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


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

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

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


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


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


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


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