Я работаю с PowerDesigner много лет, и это действительно очень мощный инструмент. До этого я использовал Microsoft Visio, но он обладает меньшими возможностями.
Два года назад у меня была возможность поработать в крупном проекте где используется PowerDesigner, в банке De Volksbank (четвертый по величине банк в Голландии). PowerDesigner там является стандартным инструментом моделирования баз данных.
PowerDesigner имеет как свои достоинства, так и недостатки.
2 Преимущества
Что нравится лично мне?
2.1 Поддержка многих типов моделей
Для проектирования БД в основном используются логическая и физическая модели, но есть также множество других типов моделей.
2.2 Поддержка Reverse Engineering
Можно подкючитья к уже существующей базе данных, прочитать ее метаданные и на их основе создать модель.
2.3 Поддержка больших моделей
Диаграмму, состоящую из большого числа таблиц (например, нескольких сотен), можно разбить на несколько диаграмм меньшего размера (которые при этом все входят в одну модель).
2.4 Поддержка разных баз данных
Поддержка многих типов баз данных (например, в банке De Volksbank используется Teradata) и генерация скриптов создания БД для них.
2.5 Возможность валидации
Например, контроль наличия первичных ключей у всех таблиц, обнаружение аномальных связей между таблицами и т.д. (десятки разных проверок). Можно добавлять свои собственные валидации.
2.6 Возможность автоматизации
Очень мощная черта PowerDesigner - это возможность его расширения, добавления новой функциональности.
Например, можно добавить новый атрибут к таблице базы данных. Затем добавить поле для редактирования этого атрибута на соответствующую форму GUI. Затем добавить код, который на основе значения этого атрибута выполняет какое-то действие. Например, генерирует файл с кодом для создания хранимой процедуры. Или выполняет для этой таблицы какую-нибудь специфическую валидацию.
Код пишется на языке VBScript. Текст (например, код хранимой процедуры) можно сгенерировать на основе шаблона. Шаблоны создаются при помощи специального языка разметки GTL (Generation Template Language). Из VBScript, как и из GTL, есть доступ к объектной модели, содержащей метаданные разрабатываемой базы данных.
Одна маленькая, да удаленькая голландская компания разработала по заказу банка плагин для упрощения работы с их хранилищами данных (data warehouses). В банке использовались би- и тритемпоральные базы данных, в которых хранилась полная история изменений всех данных (для проектирования этих баз, по крайней мере некоторых, использовался паттерн проектирования Data Vault). Нужно было обеспечить получение информации по состоянию на любой конкретный момент времени в прошлом, по запросу пользователей.
Это было реализовано в виде плагина для PowerDesigner. Разработчики баз данных при создании моделей добавляли в них дополнительную метаинформацию для таблиц и баз данных. После этого можно было сгенерировать код для автоматического создания всей необходимой инфраструктуры - таблиц для хранения промежуточных данных, представлений (view), хранимых процедур и т.д.
Этот плагин был впечатляющим продуктом (я немного поучаствовал в его разработке).
3 Недостатки
3.1 Контроль версий
Описание модели хранится в одном большом XML-файле. Из-за этого очень неудобно контролировать изменения с использованием системы контроля версий (например, Git). Особенно когда несколько человек работают с одной и той же моделью (проблемы с merge).
Вышеупомянутая компания частично решила этот вопрос, создав инструмент под названием DeComposer. С его помощью можно разбить файл модели на множество мелких XML-файлов (а также собрать все эти отдельные файлы обратно в один файл). Скажем, определение каждой таблицы базы данных сохраняется в своем файле и т.д. После чего все эти отдельные файлы можно сохранить в системе контроля версий.
Процесс работы с моделью при этом выглядит так:
Выгрузить все файлы из системы контроля версий
Собрать файл модели при помощи DeComposer
Поработать с моделью
Разбить файл модели на отдельные файлы при помощи DeComposer
3.2 Трудности программирования
Объектная модель для представления метаданных базы данных (таблицы, их колонки, связи между таблицами и т.д.) усложненная и запутанная.
Программирование возможно только на языке VBScript, который совершенно примитивен. В документации где-то упоминается, что можно также использовать C#, но я не смог найти никакой информации по этому поводу.
Нет отладчика.
Сам процесс программирования непонятный и запутанный. С одной стороны, пишутся отдельные скрипты на VBScript и шаблоны на языке GTL. Потом эти разрозненные кусочки кода хитрым образом компонуются вместе путем конфигурирования в специальном визуальном редакторе. С другой стороны, дополнительные атрибуты, элементы GUI и др. не программируются, а конфигурируются в этом же редакторе (то, что сейчас называется No Code). Пока с этим разберешься, голову можно сломать. Эта методика при этом обеспечивает меньшую гибкость, чем давало бы использование обычного традиционного программирования.
Так что написание вышеупомянутого плагина было в некотором роде подвигом (учитывая его сложность).
3.3 Ручные действия
Валидация модели и генерация кода (скрипт создания базы данных и др.) производится вручную (путем выбора пункта из меню), то есть нельзя встроить это в процессы CI/CD.
3.4 Плохая поддержка
PowerDesigner в последние годы практически не развивается (наверное, из-за того, что SAP - очень большая и неповоротливая компания). Служба поддержки возникающие проблемы решает тоже очень медленно.
4 Заключение
Резюмируя вышесказанное: PowerDesigner - инструмент очень мощный, но расширять и автоматизировать его очень неудобно.
Я задумывался о том, чтобы разработать свой инструмент для проектирования баз данных, лишенный этих недостатков.
Этот инструмент должен по крайней мере поддерживать следующую функциональность:
XML не подходит для описание моделей. Вместо этого лучше разработать специализированный DSL (Domain Specific Language). При этом описание модели можно разбивать на отдельные файлы. Например, описание каждой таблицы хранить в отдельном файле подобно тому как при написании кода на C# или Java мы помещаем код каждого класса в отдельный файл.
Удобная для использования объектная модель для представления метаданных базы данных. Это я уже разработал (по другому поводу) с использованием C#.
Использование более мощного языка для программирования расширений вместо VBScript (например, C#).
Все действия (валидация, генерация) должны выполняться из командной строки для облегчения интеграции с CI/CD.
Но пока из-за отсутствия и финансирования, и свободного времени пришлось этот проект отложить.
Не знаю, как в вашей стране, а у нас в Голландии COBOL до сих пор используется достаточно широко.
Что я видел сам:
1999 - Авиакомпания KLM. К счастью, мне самому не пришлось там сталкиваться с COBOL-ом - я писал на другом устаревшем языке - PL-1. Там же использовалась и СУБД IMS, разработка IBM родом из 1960-х годов.
Кстати, в конце 1990х годов KLM рассматривала возможность использования системы планирования полетов других авиакомпаний вместо своей. Одна из кандидаток - система одной из американских авиакомпаний родом из 1960-х, написанная на FORTRAN вообще без использования СУБД (все данных хранились в файлах).
2010 - Центробанк. Прямо-таки заповедник COBOL.
2017 - Металлургический комбинат Tata Steel. Основная программа, собственная ERP-cистема для управления всем производством (на первом уровне согласно 5-уровневой архитектуре управления индустриальными процессами), написана на COBOL. (Там, правда, еще использовались Java и Python, но основная часть реализована на COBOL). Там же использовалась и СУБД IMS.
Сейчас COBOL все еще широко используется в банках, страховых компаниях, крупных предприятиях типа Gasuine (местный "Газпром").
Сейчас заглянул в LinkedId - в Голландии 64 открытых вакансий по COBOL. Довольно много для такого устаревшего языка.
Кстати, в Голландии в 2000-х годах увеличились продажи мейнфреймов.
Чтобы написать книгу (техническую), не нужно знать язык очень хорошо. Гораздо важнее иметь, что сказать. Я в 2000 году написал много документации на работе и несколько статей по программированию на голландском, хотя знал этот язык в то время довольно посредственно. После исправления грамматических ошибок редактором (имеется в виду человек) статьи были опубликованы в журнале нашей компании.
Я не думаю, что эта статья выйдет в каком-либо серьезном журнале, потому что она не отвечает принятым стандартам. У меня вызывает большие сомнения возможность реализации сверхпроводимости в соединении с такой формулой.
В 90-х годах я сверстал при помощи LaTeX докторскую диссертацию по радиофизике для моей тещи. Это несколько сотен страниц со сложными формулами, некоторые из которых были на страницу или больше.
Сделать это при помощи Word было бы гораздо сложнее.
Хотя для работы с TeX, если и не быть программистом, нужно хотя бы обладать программистским мышлением.
Много лет назад один знакомый рассказывал реализованную кем-то интересную идею представления таких взаимозависимых параметров в виде веселой рожицы с изменяющимися деталями.
Вспомнилось, как в 2013 году я работал в голландской компании KEMA, которую купила норвежская компания DNV (Det Norske Veritas). Через некоторое время объявили, что мы теперь будем работать по норвежским правилам. Продолжительность рабочего дня осталась 8 часов, но теперь в это время стал входить обеденный перерыв (30 минут). Зарплата осталась такая же.
Помнится, году в 1993 один программист в Харькове в разговоре со мной посетовал на то, что работы для программистов практически не осталось, потому что созданы программные системы на все случаи жизни и на долю IT-персонала остается только их настраивать и конфигурировать.
Я при этом усмехнулся про себя, потому что в это время был занят написанием программы расчета зарплаты для одного завода.
Что-то в мире пошло не так, и в результате я с того времени и по настоящий день занимаюсь написанием кода.
bash - вполне функциональный язык программирования, за счет собственного синтаксиса + использования команд UNIX/Linux (в состав которых входят, например, такие мощные средства, как grep, find, sed или awk). Вот кто-то даже реализовал быструю сортировку на bash:
Когда-то в 2000 году я участвовал в одном проекте в голландской телефонной компании KPN Telecom, и мы активно использовали Korn Shell, вплоть до скриптов объемом в 3000-4000 строк. (Korn Shell - это почти то же самое, что и bash).
Хотя, по правде говоря, в оболочках типа bash удобно использовать только несколько специфических их черт, типа перенаправления ввода/вывода при помощи '<' и '>' или передачи данных из программы в программу через pipeline. А для больших программ удобнее использовать более развитые языки программирования типа Python (в прошлом этим языком также часто бывал Perl).
Замена ENUM на внешний ключ не влияет на нормализацию аж никак. Иными словами, в какой нормальной форме была таблица, в той и осталась.
Статья не имеет никакого отношения к нормализации.
Не требует. Но удобнее завести отдельную таблицу.
1 Введение
Я работаю с PowerDesigner много лет, и это действительно очень мощный инструмент. До этого я использовал Microsoft Visio, но он обладает меньшими возможностями.
Два года назад у меня была возможность поработать в крупном проекте где используется PowerDesigner, в банке De Volksbank (четвертый по величине банк в Голландии). PowerDesigner там является стандартным инструментом моделирования баз данных.
PowerDesigner имеет как свои достоинства, так и недостатки.
2 Преимущества
Что нравится лично мне?
2.1 Поддержка многих типов моделей
Для проектирования БД в основном используются логическая и физическая модели, но есть также множество других типов моделей.
2.2 Поддержка Reverse Engineering
Можно подкючитья к уже существующей базе данных, прочитать ее метаданные и на их основе создать модель.
2.3 Поддержка больших моделей
Диаграмму, состоящую из большого числа таблиц (например, нескольких сотен), можно разбить на несколько диаграмм меньшего размера (которые при этом все входят в одну модель).
2.4 Поддержка разных баз данных
Поддержка многих типов баз данных (например, в банке De Volksbank используется Teradata) и генерация скриптов создания БД для них.
2.5 Возможность валидации
Например, контроль наличия первичных ключей у всех таблиц, обнаружение аномальных связей между таблицами и т.д. (десятки разных проверок). Можно добавлять свои собственные валидации.
2.6 Возможность автоматизации
Очень мощная черта PowerDesigner - это возможность его расширения, добавления новой функциональности.
Например, можно добавить новый атрибут к таблице базы данных. Затем добавить поле для редактирования этого атрибута на соответствующую форму GUI. Затем добавить код, который на основе значения этого атрибута выполняет какое-то действие. Например, генерирует файл с кодом для создания хранимой процедуры. Или выполняет для этой таблицы какую-нибудь специфическую валидацию.
Код пишется на языке VBScript. Текст (например, код хранимой процедуры) можно сгенерировать на основе шаблона. Шаблоны создаются при помощи специального языка разметки GTL (Generation Template Language). Из VBScript, как и из GTL, есть доступ к объектной модели, содержащей метаданные разрабатываемой базы данных.
Одна маленькая, да удаленькая голландская компания разработала по заказу банка плагин для упрощения работы с их хранилищами данных (data warehouses). В банке использовались би- и тритемпоральные базы данных, в которых хранилась полная история изменений всех данных (для проектирования этих баз, по крайней мере некоторых, использовался паттерн проектирования Data Vault). Нужно было обеспечить получение информации по состоянию на любой конкретный момент времени в прошлом, по запросу пользователей.
Это было реализовано в виде плагина для PowerDesigner. Разработчики баз данных при создании моделей добавляли в них дополнительную метаинформацию для таблиц и баз данных. После этого можно было сгенерировать код для автоматического создания всей необходимой инфраструктуры - таблиц для хранения промежуточных данных, представлений (view), хранимых процедур и т.д.
Этот плагин был впечатляющим продуктом (я немного поучаствовал в его разработке).
3 Недостатки
3.1 Контроль версий
Описание модели хранится в одном большом XML-файле. Из-за этого очень неудобно контролировать изменения с использованием системы контроля версий (например, Git). Особенно когда несколько человек работают с одной и той же моделью (проблемы с merge).
Вышеупомянутая компания частично решила этот вопрос, создав инструмент под названием DeComposer. С его помощью можно разбить файл модели на множество мелких XML-файлов (а также собрать все эти отдельные файлы обратно в один файл). Скажем, определение каждой таблицы базы данных сохраняется в своем файле и т.д. После чего все эти отдельные файлы можно сохранить в системе контроля версий.
Процесс работы с моделью при этом выглядит так:
Выгрузить все файлы из системы контроля версий
Собрать файл модели при помощи DeComposer
Поработать с моделью
Разбить файл модели на отдельные файлы при помощи DeComposer
3.2 Трудности программирования
Объектная модель для представления метаданных базы данных (таблицы, их колонки, связи между таблицами и т.д.) усложненная и запутанная.
Программирование возможно только на языке VBScript, который совершенно примитивен. В документации где-то упоминается, что можно также использовать C#, но я не смог найти никакой информации по этому поводу.
Нет отладчика.
Сам процесс программирования непонятный и запутанный. С одной стороны, пишутся отдельные скрипты на VBScript и шаблоны на языке GTL. Потом эти разрозненные кусочки кода хитрым образом компонуются вместе путем конфигурирования в специальном визуальном редакторе. С другой стороны, дополнительные атрибуты, элементы GUI и др. не программируются, а конфигурируются в этом же редакторе (то, что сейчас называется No Code). Пока с этим разберешься, голову можно сломать. Эта методика при этом обеспечивает меньшую гибкость, чем давало бы использование обычного традиционного программирования.
Так что написание вышеупомянутого плагина было в некотором роде подвигом (учитывая его сложность).
3.3 Ручные действия
Валидация модели и генерация кода (скрипт создания базы данных и др.) производится вручную (путем выбора пункта из меню), то есть нельзя встроить это в процессы CI/CD.
3.4 Плохая поддержка
PowerDesigner в последние годы практически не развивается (наверное, из-за того, что SAP - очень большая и неповоротливая компания). Служба поддержки возникающие проблемы решает тоже очень медленно.
4 Заключение
Резюмируя вышесказанное: PowerDesigner - инструмент очень мощный, но расширять и автоматизировать его очень неудобно.
Я задумывался о том, чтобы разработать свой инструмент для проектирования баз данных, лишенный этих недостатков.
Этот инструмент должен по крайней мере поддерживать следующую функциональность:
XML не подходит для описание моделей. Вместо этого лучше разработать специализированный DSL (Domain Specific Language). При этом описание модели можно разбивать на отдельные файлы. Например, описание каждой таблицы хранить в отдельном файле подобно тому как при написании кода на C# или Java мы помещаем код каждого класса в отдельный файл.
Удобная для использования объектная модель для представления метаданных базы данных. Это я уже разработал (по другому поводу) с использованием C#.
Использование более мощного языка для программирования расширений вместо VBScript (например, C#).
Все действия (валидация, генерация) должны выполняться из командной строки для облегчения интеграции с CI/CD.
Но пока из-за отсутствия и финансирования, и свободного времени пришлось этот проект отложить.
.
.
А ссылку дать можете?
Это не тот Серл. В статье упоминается Джордж, и диск изобрел Джон.
Не знаю, как в вашей стране, а у нас в Голландии COBOL до сих пор используется достаточно широко.
Что я видел сам:
1999 - Авиакомпания KLM. К счастью, мне самому не пришлось там сталкиваться с COBOL-ом - я писал на другом устаревшем языке - PL-1. Там же использовалась и СУБД IMS, разработка IBM родом из 1960-х годов.
Кстати, в конце 1990х годов KLM рассматривала возможность использования системы планирования полетов других авиакомпаний вместо своей. Одна из кандидаток - система одной из американских авиакомпаний родом из 1960-х, написанная на FORTRAN вообще без использования СУБД (все данных хранились в файлах).
2010 - Центробанк. Прямо-таки заповедник COBOL.
2017 - Металлургический комбинат Tata Steel. Основная программа, собственная ERP-cистема для управления всем производством (на первом уровне согласно 5-уровневой архитектуре управления индустриальными процессами), написана на COBOL. (Там, правда, еще использовались Java и Python, но основная часть реализована на COBOL). Там же использовалась и СУБД IMS.
Сейчас COBOL все еще широко используется в банках, страховых компаниях, крупных предприятиях типа Gasuine (местный "Газпром").
Сейчас заглянул в LinkedId - в Голландии 64 открытых вакансий по COBOL. Довольно много для такого устаревшего языка.
Кстати, в Голландии в 2000-х годах увеличились продажи мейнфреймов.
Чтобы написать книгу (техническую), не нужно знать язык очень хорошо. Гораздо важнее иметь, что сказать. Я в 2000 году написал много документации на работе и несколько статей по программированию на голландском, хотя знал этот язык в то время довольно посредственно. После исправления грамматических ошибок редактором (имеется в виду человек) статьи были опубликованы в журнале нашей компании.
А пока физики выражают сомнения:
Источник: https://nplus1.ru/news/2023/07/27/superconductivity-at-room-temperature-but-is-it-real
Я и не знал, что Владимир Владимирович интересуется вопросами сверхпроводимости :-)
Посмотрим, что скажет по этому поводу Артем Оганов.
Для любого натурального числа N можно построить осциллятор с периодом N.
В 90-х годах я сверстал при помощи LaTeX докторскую диссертацию по радиофизике для моей тещи. Это несколько сотен страниц со сложными формулами, некоторые из которых были на страницу или больше.
Сделать это при помощи Word было бы гораздо сложнее.
Хотя для работы с TeX, если и не быть программистом, нужно хотя бы обладать программистским мышлением.
Эту идею предложил математик Герман Чернов в 1973 году: https://ru.wikipedia.org/wiki/Лица_Чернова
Вспомнилось, как в 2013 году я работал в голландской компании KEMA, которую купила норвежская компания DNV (Det Norske Veritas). Через некоторое время объявили, что мы теперь будем работать по норвежским правилам. Продолжительность рабочего дня осталась 8 часов, но теперь в это время стал входить обеденный перерыв (30 минут). Зарплата осталась такая же.
Помнится, году в 1993 один программист в Харькове в разговоре со мной посетовал на то, что работы для программистов практически не осталось, потому что созданы программные системы на все случаи жизни и на долю IT-персонала остается только их настраивать и конфигурировать.
Я при этом усмехнулся про себя, потому что в это время был занят написанием программы расчета зарплаты для одного завода.
Что-то в мире пошло не так, и в результате я с того времени и по настоящий день занимаюсь написанием кода.
Конечно, процедурный
bash - вполне функциональный язык программирования, за счет собственного синтаксиса + использования команд UNIX/Linux (в состав которых входят, например, такие мощные средства, как grep, find, sed или awk). Вот кто-то даже реализовал быструю сортировку на bash:
https://gist.github.com/shreyansh26/af6fae1bb2497d0486c2cc36215f61eb
Когда-то в 2000 году я участвовал в одном проекте в голландской телефонной компании KPN Telecom, и мы активно использовали Korn Shell, вплоть до скриптов объемом в 3000-4000 строк. (Korn Shell - это почти то же самое, что и bash).
Хотя, по правде говоря, в оболочках типа bash удобно использовать только несколько специфических их черт, типа перенаправления ввода/вывода при помощи '<' и '>' или передачи данных из программы в программу через pipeline. А для больших программ удобнее использовать более развитые языки программирования типа Python (в прошлом этим языком также часто бывал Perl).