[vitan 2]

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

А схемы Вы как рисуете? Наизусть помните все параметры компонентов, или читаете PDF каждый раз перед установкой? Или Вы не рисуете?

 

Параметрический поиск нужен несомненно при поиске компонента из очень больших баз, например посмотрите как сделан парам поиск в терраэлектронике.

А мы-то чем хуже?

 

Нужно для этого наворачивать функционал КЛИЕНТА.

Как? Парсить текстовые строки на предмет наличия в них пар параметр=значение?

Я когда-то тоже так поступил, написал систему, которая конструирует коды заказа компонентов из таких пар, а потом их расшифровывает. Но это уже больше похоже не на реляционную БД, а на XML и т.п. Мы же обсуждаем именно реляционную БД, т.к. наши схемотехнические редакторы хорошо связываются именно с ними.

Хотя, лично я не против перейти на XML, главное связать САПР с такой БД.

 

Получается что в клиенте надо провести поиск , запомнить этот элемент где он и как назвается, потом в альтиуме его найти и плюхнуть на схему. Это неудобно несколько.

Конечно, никто не должен юзать какой-то клиент перед тем, как поставить компонент на схему. Клиент нужен для других операций: для добавления компонентов, редактирования, утверждения и т.п. Схемотехник должен получать доступ к БД из своего САПР только по чтению, это мое глубокое убеждение.

 

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

Я думал, что убедил всех посмотреть на вопрос немного шире... :(

 

У нас в конторе структура сложнее на порядок.

Все правильно. Это я привел модуль работы с эл. компонентами для инженеров. :)

[Krys 2]

я поиском не пользуюсь

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

 

 

Моё имхо в том что выбирать из базы компонент параметрическим поиском - это попытка отупеть за счет функционала базы. Параметрический поиск нужен несомненно при поиске компонента из очень больших баз

У меня тут 2 довода:

1. Вы не верите, что рано или поздно данная общественная база будет очень большой?

2. У крупных контор (я имею в виду наших работодателей) на складе огромное количество элементов. Зачем плодить номенклатуру, если можно выбрать из имеющихся? Но при отсутствии параметрического поиска это практически невозможно...

3. А если ещё и думать в перспективе, что кто-то её захочет прикрутить общественную базу к своей базе наличия на складе предприятия - тогда тем более параметрический поиск не помешает.

 

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

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

 

Поэтому , раз база обсуждается применительно к работе только Альтиума, надо сделать максимально удобной работе именно в альтиуме, с учетом его ограниченных возможностей. Многие пользователи не будут пользоваться клиентом (лень, некогда), но скажут спасибо тем кто наполняет эту общественную базу

Я так понял, уже все согласились с тем, что база будет проектироваться с расчётом на более широкое использование, чем просто АД. При том САПР может быть несколько. И вообще, САПР - это будет частный случай предназначения базы.

 

П.С. прошу ещё раз перечитать это сообщение (#149): http://electronix.ru/forum/index.php?s=&am...st&p=822430

и вместе с ним исходное (#83): http://electronix.ru/forum/index.php?s=&am...st&p=819219

Там на примере дигикея я всё объяснил и мотивировал. У меня ощущение, что Вы не читали этих доводов.

 

Обновил.

Осталось: " УГО могут иметь параметры." в п. 1.1.2.3. Дальше пока не смотрел. Да и не понимаю (в структуре БД) :)

[Uladzimir 90]

Цитата(тау @ Oct 12 2010, 17:34) *

Цитата(тау @ Oct 12 2010, 17:34) *

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

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

То что не догонит-- абсолютно точно. Новые компоненты слишком быстро появляются.

В общем это и ненужно

Первым образом ищется то, что есть на предприятии, а это есть в базе

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

Затем то, что есть в общей базе. Значит это кто-то применял, и можно найти.

Затем то-- что есть у поставщиков или производителей.

Вот тут и нужно создавать новый компонент и добавлять к общей базе

 

[тау 31]

А схемы Вы как рисуете? Наизусть помните все параметры компонентов, или читаете PDF каждый раз перед установкой? Или Вы не рисуете?

Рисую . Помню обычно больше, чем можно заложить в десяток параметров (полей). Когда не помню - бегом лезу в даташит, при необходимости посмотреть. Весь даташит заложить в параметры невозможно, согласитесь. А ограничиваться при выборе только параметрическим поиском - упрощенчество какое-то , возможно голубая мечта начинающего схемотехника.

 

 

Как? Парсить текстовые строки на предмет наличия в них пар параметр=значение?

"параметр=значение" это слишком плохой параметрический поиск. Им пользоваться оченно неудобно. Всегда желателен ввод диапазончика.

 

Конечно, никто не должен юзать какой-то клиент перед тем, как поставить компонент на схему. Клиент нужен для других операций: для добавления компонентов, редактирования, утверждения и т.п. Схемотехник должен получать доступ к БД из своего САПР только по чтению, это мое глубокое убеждение.

+1.

не представляю себе как нормальный параметрический поиск прикрутить в альтиум (а несколько полей ? :) поиска )

 

Я думал, что убедил всех посмотреть на вопрос немного шире... :(

одно другому не мешает, если придумать нечто грандиозное , но нереализуемое в альтиуме, то эта ветка станет многим неинтересна.

 

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

мне кажется это ошибочный подход. Пофигизм такого рода чреват невозможностью изготовления (например ) или еще всякими осложнениями.

 

П.С. прошу ещё раз перечитать это сообщение

Я в нём писал, что параметрический поиск очень иногда упрощает жизнь. И, если уж Вы всё равно вводите основные параметры в поле "REM", то почему бы ещё капельку не поднапрячься и их же ввести по раздельности - каждый параметр в своё поле. Работы больше совсем нанемножко, зато сразу резкий качественный скачок полезности базы - появляется параметрический поиск.

Надеюсь, я Вас убедил...

нет , не убедили. Убедите тогда, когда скажете как это реализовать в альтиуме (групповой поиск по нескольким полям по условиям выборки из диапазона по каждому полю - база то огромная :) )

 

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

Хорошо, не буду навязывать. Умолкаю.

 

[vitan 2]

А ограничиваться при выборе только параметрическим поиском - упрощенчество какое-то , возможно голубая мечта начинающего схемотехника.

Ну почему же??? Я вот себя к начинающим не отношу, но голубая мечта - это да! Почему бы не упростить себе жизнь? Скажите, не лучше ли заполнять свою память чем-то более полезным, чем десятки параметров? По-моему, это дело компьютера.

 

"параметр=значение" это слишком плохой параметрический поиск. Им пользоваться оченно неудобно. Всегда желателен ввод диапазончика.

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

 

не представляю себе как нормальный параметрический поиск прикрутить в альтиум (а несколько полей ? :) поиска )

А вот на Вашей же картинке разве нельзя вверху полей задавать одновременно несколько условий как это приведено на моей картинке?

 

нет , не убедили. Убедите тогда, когда скажете как это реализовать в альтиуме (групповой поиск по нескольким полям по условиям выборки из диапазона по каждому полю - база то огромная :) )

Альтиум не позволяет задавать условия вида "(параметр>число) И (параметр<число)"?

[тау 31]

А вот на Вашей же картинке разве нельзя вверху полей задавать одновременно несколько условий как это приведено на моей картинке?

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

 

Альтиум не позволяет задавать условия вида "(параметр>число) И (параметр<число)"?

можно в окне браузера таблицы , которые Вы упомянули в ссылке. А вот из окна библиотек , из которого компоненты "тянутся" на схему , условий отбора, кроме сортировки колонок не предусмотрено. Или я плохо искал.

 

 

[vitan 2]

можно в окне браузера таблицы , которые Вы упомянули в ссылке.

А вот из окна библиотек , из которого компоненты "тянутся" на схему , условий отбора, кроме сортировки колонок не предусмотрено. Или я плохо искал.

Теперь понятны Ваши прошлые посты.

Не парьтесь, переходите на ментор! :)

Шутю.

Правда, не понятно, зачем нужен отдельный браузер...

 

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

+1. Нормальный подход. Рейтинг (или что там будет вместо этого: проверки) поможет принять ответственность на себя. :) Но база выполнит свою функцию, предоставит возможность повторно использовать наработки. Это же то, что нужно, разве нет?

При том САПР может быть несколько. И вообще, САПР - это будет частный случай предназначения базы.

Вот! Полностью поддерживаю.

[jkrieger 0]

Хочу предложить свои определения некоторым понятиям.

 

БД - один или несколько файлов, в которых хранитятся данные в виде таблиц, подключение к которому(ым) выполняется одной строкой подключения.

 

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

 

Запрос - команда на языке, понятном СУБД. результатом выполнения которой будет некоторая операция с данными (выборка. изменение, добавление и т.п.)

 

Компонент - запись в таблице, однозначно определяемая по ключевым полям, описывающая характеристики и соответствующая реальному изделию (примерно так).

 

Альтиум не позволяет задавать условия вида "(параметр>число) И (параметр<число)"?

 

В Альтиуме можно строить SQL запросы (прямо там где расширенный поиск). Но это не совсем имхо удобно.

 

UPD: Поправка! Так как все данные альтиум импортирует как текстовые значения, то сравнения больше меньше не работают.

Изменено 12 октября, 2010 пользователем Jack Krieger

[Krys 2]

Рисую . Помню обычно больше, чем можно заложить в десяток параметров (полей). Когда не помню - бегом лезу в даташит, при необходимости посмотреть. Весь даташит заложить в параметры невозможно, согласитесь. А ограничиваться при выборе только параметрическим поиском - упрощенчество какое-то

Весь датащит и не надо. Задача параметрического поиска - лишь ограничить область выбора. И чем по большему числу параметров можно будет искать, тем Уже будет область выбора. А дальше, естественно, читать датащит и только после этого принимать решение об использовании. Вопрос только в том, что без параметрического поиска рыться придётся условно говоря в 15 датащитах, а с таковым - в 3х. Либо помнить, как Вы, всё в уме, тогда параметрический поиск не требуется. Но помнить в уме нереально.

возможно голубая мечта начинающего схемотехника.

То, что Вы полностью всю работу проделываете вручную (поиск сразу среди датащитов и т.п.) - это не является признаком профессионализма. Это скорее показывает неумение (или отсутствие возможности на предприятии) пользоваться инструментами, облегчающими инженеру работу.

 

мне кажется это ошибочный подход. Пофигизм такого рода чреват невозможностью изготовления (например ) или еще всякими осложнениями.

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

 

нет , не убедили. Убедите тогда, когда скажете как это реализовать в альтиуме (групповой поиск по нескольким полям по условиям выборки из диапазона по каждому полю - база то огромная :) )

Хорошо. Тогда я задам встречный вопрос. А в АД легко сделать параметрический поиск по текстовым полям вида Um = 0,7 V, чередующимися с записью Vм = 0,7 В? Это, если и возможно, то крайне ненадёжно. Т.к., как показано, при вводе можно случайно допустить вольность типа Um и Vм и т.п. А чтобы это детектировать и приводить к нужному виду - требуется наворачивать очень длинные условия поиска, длинные макросы... Получается, что поиск по текстовым строкам с группой параметров также неудобен, как и поиск по отдельным полям параметров. Но если нет разницы, то давайте хотябы параметры друг от друга отделим. Хоть какая-то дифференциация. В текстовой строке даже порядок упоминания параметров может быть какой попало. И при поиске придётся подключать мозг и каждую строчку анализировать ещё и на это.

 

Хорошо, не буду навязывать. Умолкаю.

Извините, если обидел.

 

БД - один или несколько файлов, в которых хранитятся данные в виде таблиц, подключение к которому(ым) выполняется одной строкой подключения.

Тут лично мне как далёкому от БД непонятно, что значит "подключение" и что значит "одной строкой"? Или несколькими? и чем плохо первое или второе.

 

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

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

Можно ещё примерно такое предложение добавить: в пределах одной таблицы все записи имеют одинаковый набор полей.

 

Компонент - запись в таблице, однозначно определяемая по ключевым полям, описывающая характеристики и соответствующая реальному изделию (примерно так).

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

 

UPD: Поправка! Так как все данные альтиум импортирует как текстовые значения, то сравнения больше меньше не работают.

А может перед сравнением эти значения можно преобразовать через какие-либо функции (такие как в языках программирования типа StrToVal ()) в числовое значение? Ну это тоже как гипотеза, т.к. я в этом ничего не понимаю.

[vitan 2]

Обновил.

Господа! НЕ ТОРОПИТЕСЬ!

 

Не надо сейчас начинать обсуждать структуру БД.

Да и добавлять комментарии в файлик не удобно, тем более .docx.

 

Я напомню, с чего все началось. Нужно вначале определить требования. А перед этим понять, что именно создается, определим, как принято говорить "бизнес-цели". :)

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

 

Судя по словам

При том САПР может быть несколько. И вообще, САПР - это будет частный случай предназначения базы.

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

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

Правильно, что начали с терминов.

Только термины типа "база данных", "таблица", "запрос" и т.п., имхо обсуждать нечего, это общеупотребительные вещи.

Даже "компонент" имхо обсуждать не надо, ибо всем понятно, что это - то, что можно взять и подержать в руках, а никак не запись в БД.

Вот "библиотека", например, - другое дело.

 

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

Признаком группировки предлагаю считать, ммм.. как бы это выразить..., тип компонента. Например, резистор, конденсатор и т.п. (чтобы параметры нормально группировались).

 

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

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

Так?

 

Если да, то надо определить, по какому интерфейсу будет к БД коннектиться САПР.

 

UPD: Поправка! Так как все данные альтиум импортирует как текстовые значения, то сравнения больше меньше не работают.

Плохо дело...

[Krys 2]

Только термины типа "база данных", "таблица", "запрос" и т.п., имхо обсуждать нечего, это общеупотребительные вещи.

Даже "компонент" имхо обсуждать не надо, ибо всем понятно, что это - то, что можно взять и подержать в руках, а никак не запись в БД.

Вот "библиотека", например, - другое дело.

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

 

Склада и закупок нет. Так?

Я высказываю пожелание, чтобы склад и закупки были хотябы предусмотрены (заполнять это общими усилиями не требуется, но предусмотреть...). Чтобы имеющуюся общую базу можно было как-то приспособить малыми силами для работы на отдельно взятом предприятии.

[Uladzimir 90]

Не надо сейчас начинать обсуждать структуру БД.

Да и добавлять комментарии в файлик не удобно, тем более .docx.

До этого еще далеко, но где то надо фиксировать проеденное. Текст на форуме для этого еще больше не подходит

Я напомню, с чего все началось.

Я тоже. В начале шла речь только об алтиуме в другой ветке.

Эту я создал тоже для обсуждения того же. Но она благодаря вашим усилиям плавно и неуклонно перетекает к общим базам.

Принято

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

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

Правильно, что начали с терминов.

Только термины типа "база данных", "таблица", "запрос" и т.п., имхо обсуждать нечего, это общеупотребительные вещи.

Как для кого. Может кто и первый раз слышит. Все мы с чего то начинали.

Я настоятельно рекомендую называть библиотекой компонентов совокупность компонентов, сгруппированных по какому-то признаку. Это не запрос, не таблица в БД и не файлик от альтиума.

И это тоже библиотека. вот поэтому я хочу иметь и классификатор по библиотекам. Вот тут на форуме многие под библиотекой понимают только интегральную.

Еще Астап Бендер говорил-- про мальчика :)

Признаком группировки предлагаю считать, ммм.. как бы это выразить..., тип компонента. Например, резистор, конденсатор и т.п. (чтобы параметры нормально группировались).

До этого я еще не дошел. Но тоже надо. Поймите, то, что вам ясно по определению, многие понимают совсем иначе

Поэтому все это нужно изобразить в дианраммах, связях, описаниях...

Если да, то надо определить, по какому интерфейсу будет к БД коннектиться САПР.

Вот и я просил примерчик для опробования интерфейчика. а покуда не опробовано--чегось говорить

Плохо дело...

Плохо. Но авось поправят

 

Ну судя по скачиванию--в 10 активно участвующих в этом обсуждении не будет.

Постоянно выкладывать файл-- нет необходимости.

последняя версия терминов лежит тут. и там же можно все писать

[noxius 0]

к слову... есть платный хостинг с MySQL, PHP итп

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

 

просто еще не совсе монятно что должно хранится на сервере... файл базы данных *.mdb И к нему прописывать какимто образом линк из САПР

либо там будет (на примере альтиума) файл DBLIB.ldb и *.mdb и в альтиуме(к примеру) прописывать линк к DBLIB.ldb..

 

хостинг только сегодня проплатил.. некоторые моменты попробую проверить сам.. но может есть уже некоторые предложения..?

 

Постоянно выкладывать файл-- нет необходимости.

последняя версия терминов лежит тут. и там же можно все писать

(не разобрался как править файл у вас на сайте..)

не совсем понятна схема Базы(я так понял это БД?)

тогда каким образом к базе данных относятся библиотеки(я так понимаю это файлы..)

 

если База это не БД, то может назвать все это несколько иначе.. к примеру информационная ситема компанентов(название сходу придумал немного кривоватое =) ) но ведь по сути мы будем все сводить к определенному компоненту(у нас будет множество компонентов с какимито характеристиками символами итп..)

иначе даже после прочтения определинея Базы (мой мозг к примеру) все равно воспринимает это как база данных...

...сам запутался... =)

Изменено 13 октября, 2010 пользователем noxius

[Uladzimir 90]

просто еще не совсе монятно что должно хранится на сервере... файл базы данных *.mdb

Да. и я пример тоже положил

к нему прописывать какимто образом линк из САПР

либо там будет (на примере альтиума) файл DBLIB.ldb

Нет. это как раз каждый сам настраивает. Но и его положил

не разобрался как править файл у вас на сайте..

Да никак. скачивать, править и выкладывать назад

не совсем понятна схема Базы(я так понял это БД?)

Мне тоже. Там создание идет общей. Выложен пример только для алтиум.

В общем именно этот вопрос и обсуждается

тогда каким образом к базе данных относятся библиотеки(я так понимаю это файлы..)

Там на них указаны ссылки и все. Если ссылка есть, а файла нету-- соответственно не будет или УГО или Footprint или...

если База это не БД, то может назвать все это несколько иначе.. к примеру информационная ситема компанентов

Ну да. Базы еще товарно-сырьевые есть :). В общем База и база это разные вещи.

иначе даже после прочтения определинея Базы (мой мозг к примеру) все равно воспринимает это как база данных...

Не поверите, мой тоже. Поэтому и хочу все провести под определения.

Чтоб не подумали, что база у нас овощная :) и не присылали теток не переборку картофеля :)

[vitan 2]

тогда каким образом к базе данных относятся библиотеки(я так понимаю это файлы..)

 

Я понимаю (и всем предлагаю) под библиотекой компонентов просто группу компонентов, находящихся в БД.

 

В моей БД компоненты лежат в одной таблице, но имеют поле, в котором записано, какой группе (библиотеке) они принадлежат. Чтобы поместить компонент на схему (точнее, поместить его УГО и добавить к нему атрибуты из БД), я выбираю в САПР так называемую библиотеку. Здесь слово "библиотека" носит уже чисто схемотехнический смысл, ибо она доступна из САПР и связана с САПР. Связь группы компонентов в БД и САПР обеспечивают те самые файлики, в которых галочками настраивается видимость атрибутов (и другие вещи).

В моем случае САПР ищет УГО в местах, где хранятся УГО, т.е. в библиотеках УГО. Точно так же САПР печатных плат ищет футпринты - по путям с библиотеками футпринтов. Соответствие же путей поиска УГО и библиотек компонентов, находящихся в БД, задается в тех же файлах настройки.

 

Как я понял, в альтиуме нет разделения между компонентом и его УГО, т.е. информация об этом хранится где-то в бинарном виде в файликах во внутреннем формате альтиума. Если так, то для альтиума понятие библиотеки УГО вырождается в понятие библиотеки компонентов.

 

Тем не менее, предлагаю отделять понятия библиотек компонентов, библиотек УГО и библиотек футпринтов. Для альтиума два последних, очевидно, будут просто копировать структуру библиотек компонентов, но для других САПР будет большая польза. Это, если я правильно понял, как работает альтиум.

 

Таким образом, библиотека компонентов - это некоторая сущность в БД.

 

Я плохо ориентируюсь в альтиуме, но думаю, что всех смущают файлики .dblib.

Видимо, все думают о них, как о библиотеках. Я так понял, это файлики, настраивающие видимость атрибутов, но сами не содержащие инфы о компонентах. Это так?