В самом простом варианте для подобного рода задач это представление знаний в виде набора таблиц решений, структура которых представляется в реляционной базе данных с процедурой поиска конкретного решения для заданных значений параметров.
Если смотреть в целом на Windows последних версий, то проблема в ее возрастающей гипер-сложности. Microsoft, с упорством достойного лучшего применения, старается "в одном флаконе" совместить потребности совершенно разных пользователей: технологических, офисных, домашних (бытовых). После Win7 компании нужно было оставить Windows в покое "как есть" не усложняя ее для технологических и офисных пользователей (обычное колесо ведь давно работает !), а для домашних (бытовых) начать разработку принципиально новой ОС с пользовательским интерфейсом и простотой наподобие Android. Гипер-сложность будет требовать все более бОльших выч.ресурсов, хотя ничего принципиально нового (новаторского) в саму операционную систему НЕ привносится. Вдобавок рано или поздно это объективно будет негативно сказываться на ее надёжности работы и в конечном итоге приведет в тупик.
Как говорится, хороший кузнец и блоху подкует. А принцип "что работает, приносит пользу, то пусть и работает" остаётся верным не только для обычного колеса.
Если смотреть в целом на Windows последних версий, то проблема в ее в возрастающей гипер-сложности. Microsoft, с упорством достойного лучшего применения, старается "в одном флаконе" совместить потребности совершенно разных пользователей: технологических, офисных, домашних (бытовых). После Win7 компании нужно было оставить Windows "как есть" не усложняя ее для технологических и офисных пользователей (обычное колесо ведь давно работает !), а для домашних начать разработку принципиально новой ОС с пользовательским интерфейсом и простотой наподобие Android. Гипер-сложность будет требовать все более новых и новых выч.ресурсов, хотя ничего принципиально нового (новаторского) в саму операционную систему НЕ привносится. Вдобавок это рано или поздно объективно будет негативно сказываться и на ее надёжности работы, а в конечном итоге рано или поздно приведет в тупик.
Пока что ничего удивительного для себя не увидел, кроме как настойчивого обозначения ложных целей создателями и поклонниками подобных AI-code генераторов для их скорейшей монетизации.
/// На деле вообще не так. В среднем продукте на рынке миллионы строк кода. Документирования логики и алгоритмов ни разу не видел. В норме работа кода понятна из UI, API, архитектуры и имен функций и дополнительно стабилизируется тестами. Пока из кода нельзя понять что и как он делает, такой код не пройдет ревью. Разобраться в тысячах строк чужого самодокументированного кода и внести доработки, это собственно и была ежедневная работа программистов. ///
Это уважаемый, Ваше чисто субъективное мнение с позиции типичного "кодера", а не как профессионального разработчика ПО. Поясню.
Во первых, вот уже как полвека, разработка серьезного ПО соотносится 1в1 с разработкой технического изделия, повторяет все его жизненные циклы. Непосредственная разработка (создание) программного кода одна из операций этого процесса и работа программиста соответствует функциям технолога по разработке технологии изготовления конкретной детали (то есть разработка алгоритма модуля, процедуры) и изготовлению ее рабочим на станке (написание кода этого модуля, процедуры на ЯП). В конечном итоге от правильно спроектированного ПО и надёжности программного кода зависит успех всего софт продукта. Как и техническое изделие, программный продукт может дорабатываться, совершенствоваться и поддерживаться достаточно долго во времени отчасти уже другими людьми не первоначально его создававшими. Другой рабочий по взятой из архива документированной технологии быстро изготовит новую деталь. А программист чтобы доработать конкретный модуль (процедуру), должен сначала потратить время чтобы разобраться и понять созданный его предшественником НЕ ДОКУМЕНТИРОВАННЫЙ программный код, чтобы корректно внести изменения. А если программная система содержит, как Вы говорите миллионы (хватит даже и десятков тысяч) строк на ЯП ? Поэтому документирование (! не путать с пояснениями функций отдельных операторов ЯП) программного модуля, включающее сам алгоритм и выделение его фрагментов в тексте, является необходимым и обязательным требованием профессиональной разработки ПО. Если Вы, как разработчик, работаете и создание свой продукт индивидуально, то можете делать это как считаете нужным. Но, согласитесь, что через полгода, вам придется разбираться и вспоминать что вы сами там написали.
Во вторых, созданный, а точнее автоматический сгенерированный программный код не соответствует стандартам принятым в организации. Например, конкретная процедура обязана в самом начале своей работы проверять корректность входных параметров на соответствие алгоритму и выдавать соответствующее сообщение вызывающей процедуре и заносить его в log-журнал (стек) системных вызовов для облегчения тестирования и обнаружения ошибок. Будет ли делать подобную работу автогенератор ? Сомневаюсь.
Тут ещё что важно отметить: КАК автоматом (AI-агентом) генерируется программный код ? Берет ли он уже готовый из своей БД на этом же ЯП или переписывает с него на требуемый ЯП, либо аналогично программисту "продумывает" алгоритм и согласно его логике генерирует операторы конкретного ЯП. Отсюда и можно будет сделать вывод: понимает ли автомат смысл созданного им кода и, соответственно, способен ли его как человек документировать.
В заключении. Было бы намного нужнее и полезнее, если бы автомат (AI, ИИ) был способен протестировать и верифицировать на надёжность программный код разработанный самим программистом и пояснить выявленные в нем недостатки.
В классическом понимании трактовался именно как ИИ (AI). К нему относились интеллектуальные системы способные вести рассуждения и делать логические выводы, в частности экспертные системы. Инструменты разработки были другие. Сейчас мода на ИНС и LLM модели, а что будет завтра никто не знает.
Разобраться в стороннем программном коде содержащем более 100 (ста) строк ЯП, неважно кем разработанным человеком или автогенератором, БЕЗ документирования его алгоритма и логики, созданным в непривычном стиле написания будет намного сложнее чем его разработать самому даже квалифицированному программисту, а тем более проверить его корректность, надёжность и сделать необходимую доработку под свои стандарты.
Речь шла, скорее, об универсальной системе реального времени с помощью которой основные принципы разработки софта для управления работой разного рода "железа" в принципе одинаковы.
У японцев с 1982г. был проект намного покруче чем представленная в статье ОС. Это ЭВМ 5-ого поколения. По сути они заглянули в XXI-ый век попыткой создать супер-ЭВМ базирующиеся на ИИ, но опередили время. Их идеи позднее использовались IBM при создания своего суперкомпьютера с ИИ Watson. Поэтому разработку такой универсальной ОС-РВ нужно рассматривать не более как НИОКР.
/// Ну как правило, если у вас не хватает квалификации проверить ее код, значит этот код более высокой квалификации. Тут как раз логично. /// Далеко не факт.
Разобраться в стороннем программном коде содержащем более 100 (ста) строк ЯП, неважно кем разработанным человеком или автогенератором, БЕЗ документировании его алгоритма и логики, созданным в непривычно стиле написания - намного сложнее чем его разработать самому даже квалифицированному программисту, а тем более проверить его корректность, надёжность и сделать необходимую доработку под свои стандарты.
/// Если без воды и умных терминов — это интерфейс, позволяющий ИИ-модели обращаться за данными к внешнему ресурсу, а затем отдавать информацию обратно. ///
Пока все рассуждения автора носят общий характер. Чтобы дать оценку, необходимо на каком-то не сложном конкретном примере детально по шагам представить всю технологию обмена данными между ИИ-моделью и внешними источниками данных и информации.
///В значительной степени перед нами стоит основная, фундаментальная проблема — невозможность оставаться в лидерах в ИТ при отсутствии общего технологического развития страны, без высокого внутреннего спроса на ИТ технологии со стороны предприятий других секторов экономики.///
Это, собственно, и есть главный постулат. ИТ-технологии не могут существовать сами по себе в некотором вакууме широкого отсутствия на них спроса. По сути, для дальнейшего ИТ-прогресса, достижения конкурентоспособности и реального суверенитета в отрасли, необходимы системные разработки с новыми идеями на уровне операционных систем, инструментальных средств для создания прикладного ПО, систем управления базами данных и интеллектуальных систем поддержки принятия решений и ИИ. Фактически необходима и разработка своего hardwеre, унифицированного (совместимого) с зарубежными аналогами. Причем все это надо делать в сжатые для XXI-ого века сроки. Остаётся открытым ответ на главный вопрос: достаточности научно-технического и технологического потенциалов, наличие высоко-квалифицированных кадров и организаторов - управленцев для такой прорывной ИТ- миссии.
///Почему я считаю, что именно кардинальная смена стека\парадигмы или ЯП делают значительно мудрее? Каждый язык имеет свою философию и формирует у человека специфичный взгляд на решение технических задач.///
Чисто субъективное мнение, если оно личное автора, а может подаваться им просто "для затравки" обсуждения такого посыла.
Во первых, и главное из чего нужно исходить, так это понимание того, что процесс разработки серьезного программного обеспечения 1в1 повторяет процесс разработки технического изделия: проектирование, изготовление, контроль, тестирование и поддержка. Программист, как один из участников этой цепочки, выполняет функцию технолога (разработка техпроцесса изготовления конкретной детали, то есть алгоритма) и рабочего изготовляющего деталь на станке (кодирование процедуры, модуля на конкретном ЯП). Поэтому, если замыкаться только на функции изготовления детали, то есть только на функции разработки программного кода, то это делает такого программиста-кодировщика более универсальным в смысле знания нескольких ЯП и НЕ более того. Термин "мудрее" тут не уместен. Если со временем и с многолетней практикой, чаще в какой-то одной прикладной предметной области, такой программист-кодировщик освоит и научится выполнять ДРУГИЕ функции разработки - постановщика задачи, архитектора, управленца, разработчика БД, тестировщика и писателя документации - то тогда он действительно расширит свои профессиональные навыки как специалист-разработчик ПО вне зависимости от конкретного ЯП.
Вывод: язык программирования или конкретная СУБД конечно же играют большую роль в разработке ПО, но ОБЩИЕ принципы постановки задачи, проектирование архитектуры и БД для конкретной реализации (веб- приложение или что-то другое), управление разработкой и последующая поддержка программного продукта независимы от языка программирования.
Проблема Windows в ее гипер-сложности. Microsoft с упорством достойного лучшего применения старается "в одном флаконе" совместить потребности совершенно разных пользователей: технологических, офисных, домашних (бытовых). После Win7 компании нужно было оставить Windows как есть не усложняя ее для технологических и офисных пользователей (обычное колесо ведь давно работает !), а для домашних начать разработку принципиально новой ОС с пользовательским интерфейсом и простотой наподобие Android. Гипер-сложность будет требовать все более новых и новых выч.ресурсов, хотя принципиально ничего нового в саму операционную систему не привносится. Вдобавок это рано или поздно объективно будет негативно сказываться и на ее надёжности работы, а в конечном итоге придет в тупик.
По идее, для облегчения прикладной разработки, такие сложные процессы как асинхронность и многопоточность должны обеспечиваться и моделироваться инструментальными средствами более высокого уровня чем на уровне этих же корутин в Kotlin'e. То есть, по большому счету, такие высокоуровневые средства (в разной форме, вплоть до мастеров и шаблонов и ещё чего нибудь) должны поставляться к (с) конкретной операционной системой для облегчения разработки в ней приложений, чтобы разработчик мог максимально сфокусироваться на его прикладной части, а не углубляться в сложные и мелкие деталях реализации многопоточности и асинхронности. Для желающих же строить все "своими кирпичами" - пожалуйста используйте свои средства, в данном случае имеющиеся в языке программирования Kotlin.
Начинать надо с того, что программирование для ЭВМ и связанная с ним дисциплина проектирование (разработка) структуры базы данных, в силу своей особенной специфики, не всем студентам, в силу личных особенностей человека, доступно. Например, я знал хороших математиков, но которые так и не научились хорошо программировать, а тем более проектировать базы данных. Короче, не всем это подходит, так как требует навыки логического и аналитического мышления и которые не всем людям подвластны. Основной моделью данных, в которой представляется структура базы данных, вот уже более 50-ти лет, остаётся реляционная модель и, соответственно, под нее разработаны и реляционные СУБД. Поэтому, изучение надо начинать с этой модели, какие отношения между данными ей присущи (один ко многим, многие ко многим, один ко одному), понятие нормализации структуры БД, их формы. Лучше всего это последовательно демонстрировать на простом примере содержащем в конечном виде не более 8-10 таблиц. Но повторяю, что такой курс для не специализированных по ИТ учебных заведений должен быть факультативным (добровольным). Другое дело, это учить умению пользоваться базами данных и работать с ними. Аналог для сравнения: учить как проектировать и изготавливать автомобиль и учить как им управлять и ездить. В этом и есть принципиальная разница.
Нет ничего проще и удобней разработки приложений под Windows чем VB6 и офисного программирования на VBA.
В самом простом варианте для подобного рода задач это представление знаний в виде набора таблиц решений, структура которых представляется в реляционной базе данных с процедурой поиска конкретного решения для заданных значений параметров.
Вот пусть под новым брендом что-то действительно принципиально новое создадут, а потом и продают. Тут скорее не маркетологи, а отсутствие идей.
Если смотреть в целом на Windows последних версий, то проблема в ее возрастающей гипер-сложности. Microsoft, с упорством достойного лучшего применения, старается "в одном флаконе" совместить потребности совершенно разных пользователей: технологических, офисных, домашних (бытовых). После Win7 компании нужно было оставить Windows в покое "как есть" не усложняя ее для технологических и офисных пользователей (обычное колесо ведь давно работает !), а для домашних (бытовых) начать разработку принципиально новой ОС с пользовательским интерфейсом и простотой наподобие Android. Гипер-сложность будет требовать все более бОльших выч.ресурсов, хотя ничего принципиально нового (новаторского) в саму операционную систему НЕ привносится. Вдобавок рано или поздно это объективно будет негативно сказываться на ее надёжности работы и в конечном итоге приведет в тупик.
Как говорится, хороший кузнец и блоху подкует. А принцип "что работает, приносит пользу, то пусть и работает" остаётся верным не только для обычного колеса.
Если смотреть в целом на Windows последних версий, то проблема в ее в возрастающей гипер-сложности. Microsoft, с упорством достойного лучшего применения, старается "в одном флаконе" совместить потребности совершенно разных пользователей: технологических, офисных, домашних (бытовых). После Win7 компании нужно было оставить Windows "как есть" не усложняя ее для технологических и офисных пользователей (обычное колесо ведь давно работает !), а для домашних начать разработку принципиально новой ОС с пользовательским интерфейсом и простотой наподобие Android. Гипер-сложность будет требовать все более новых и новых выч.ресурсов, хотя ничего принципиально нового (новаторского) в саму операционную систему НЕ привносится. Вдобавок это рано или поздно объективно будет негативно сказываться и на ее надёжности работы, а в конечном итоге рано или поздно приведет в тупик.
Пока что ничего удивительного для себя не увидел, кроме как настойчивого обозначения ложных целей создателями и поклонниками подобных AI-code генераторов для их скорейшей монетизации.
/// На деле вообще не так. В среднем продукте на рынке миллионы строк кода. Документирования логики и алгоритмов ни разу не видел. В норме работа кода понятна из UI, API, архитектуры и имен функций и дополнительно стабилизируется тестами. Пока из кода нельзя понять что и как он делает, такой код не пройдет ревью. Разобраться в тысячах строк чужого самодокументированного кода и внести доработки, это собственно и была ежедневная работа программистов. ///
Это уважаемый, Ваше чисто субъективное мнение с позиции типичного "кодера", а не как профессионального разработчика ПО. Поясню.
Во первых, вот уже как полвека, разработка серьезного ПО соотносится 1в1 с разработкой технического изделия, повторяет все его жизненные циклы. Непосредственная разработка (создание) программного кода одна из операций этого процесса и работа программиста соответствует функциям технолога по разработке технологии изготовления конкретной детали (то есть разработка алгоритма модуля, процедуры) и изготовлению ее рабочим на станке (написание кода этого модуля, процедуры на ЯП). В конечном итоге от правильно спроектированного ПО и надёжности программного кода зависит успех всего софт продукта. Как и техническое изделие, программный продукт может дорабатываться, совершенствоваться и поддерживаться достаточно долго во времени отчасти уже другими людьми не первоначально его создававшими. Другой рабочий по взятой из архива документированной технологии быстро изготовит новую деталь. А программист чтобы доработать конкретный модуль (процедуру), должен сначала потратить время чтобы разобраться и понять созданный его предшественником НЕ ДОКУМЕНТИРОВАННЫЙ программный код, чтобы корректно внести изменения. А если программная система содержит, как Вы говорите миллионы (хватит даже и десятков тысяч) строк на ЯП ? Поэтому документирование (! не путать с пояснениями функций отдельных операторов ЯП) программного модуля, включающее сам алгоритм и выделение его фрагментов в тексте, является необходимым и обязательным требованием профессиональной разработки ПО. Если Вы, как разработчик, работаете и создание свой продукт индивидуально, то можете делать это как считаете нужным. Но, согласитесь, что через полгода, вам придется разбираться и вспоминать что вы сами там написали.
Во вторых, созданный, а точнее автоматический сгенерированный программный код не соответствует стандартам принятым в организации. Например, конкретная процедура обязана в самом начале своей работы проверять корректность входных параметров на соответствие алгоритму и выдавать соответствующее сообщение вызывающей процедуре и заносить его в log-журнал (стек) системных вызовов для облегчения тестирования и обнаружения ошибок. Будет ли делать подобную работу автогенератор ? Сомневаюсь.
Тут ещё что важно отметить: КАК автоматом (AI-агентом) генерируется программный код ? Берет ли он уже готовый из своей БД на этом же ЯП или переписывает с него на требуемый ЯП, либо аналогично программисту "продумывает" алгоритм и согласно его логике генерирует операторы конкретного ЯП. Отсюда и можно будет сделать вывод: понимает ли автомат смысл созданного им кода и, соответственно, способен ли его как человек документировать.
В заключении. Было бы намного нужнее и полезнее, если бы автомат (AI, ИИ) был способен протестировать и верифицировать на надёжность программный код разработанный самим программистом и пояснить выявленные в нем недостатки.
В классическом понимании трактовался именно как ИИ (AI). К нему относились интеллектуальные системы способные вести рассуждения и делать логические выводы, в частности экспертные системы. Инструменты разработки были другие. Сейчас мода на ИНС и LLM модели, а что будет завтра никто не знает.
Разобраться в стороннем программном коде содержащем более 100 (ста) строк ЯП, неважно кем разработанным человеком или автогенератором, БЕЗ документирования его алгоритма и логики, созданным в непривычном стиле написания будет намного сложнее чем его разработать самому даже квалифицированному программисту, а тем более проверить его корректность, надёжность и сделать необходимую доработку под свои стандарты.
Речь шла, скорее, об универсальной системе реального времени с помощью которой основные принципы разработки софта для управления работой разного рода "железа" в принципе одинаковы.
У японцев с 1982г. был проект намного покруче чем представленная в статье ОС. Это ЭВМ 5-ого поколения. По сути они заглянули в XXI-ый век попыткой создать супер-ЭВМ базирующиеся на ИИ, но опередили время. Их идеи позднее использовались IBM при создания своего суперкомпьютера с ИИ Watson. Поэтому разработку такой универсальной ОС-РВ нужно рассматривать не более как НИОКР.
/// Ну как правило, если у вас не хватает квалификации проверить ее код, значит этот код более высокой квалификации. Тут как раз логично. /// Далеко не факт.
Разобраться в стороннем программном коде содержащем более 100 (ста) строк ЯП, неважно кем разработанным человеком или автогенератором, БЕЗ документировании его алгоритма и логики, созданным в непривычно стиле написания - намного сложнее чем его разработать самому даже квалифицированному программисту, а тем более проверить его корректность, надёжность и сделать необходимую доработку под свои стандарты.
/// Если без воды и умных терминов — это интерфейс, позволяющий ИИ-модели обращаться за данными к внешнему ресурсу, а затем отдавать информацию обратно. ///
Пока все рассуждения автора носят общий характер. Чтобы дать оценку, необходимо на каком-то не сложном конкретном примере детально по шагам представить всю технологию обмена данными между ИИ-моделью и внешними источниками данных и информации.
///В значительной степени перед нами стоит основная, фундаментальная проблема — невозможность оставаться в лидерах в ИТ при отсутствии общего технологического развития страны, без высокого внутреннего спроса на ИТ технологии со стороны предприятий других секторов экономики.///
Это, собственно, и есть главный постулат. ИТ-технологии не могут существовать сами по себе в некотором вакууме широкого отсутствия на них спроса. По сути, для дальнейшего ИТ-прогресса, достижения конкурентоспособности и реального суверенитета в отрасли, необходимы системные разработки с новыми идеями на уровне операционных систем, инструментальных средств для создания прикладного ПО, систем управления базами данных и интеллектуальных систем поддержки принятия решений и ИИ. Фактически необходима и разработка своего hardwеre, унифицированного (совместимого) с зарубежными аналогами. Причем все это надо делать в сжатые для XXI-ого века сроки. Остаётся открытым ответ на главный вопрос: достаточности научно-технического и технологического потенциалов, наличие высоко-квалифицированных кадров и организаторов - управленцев для такой прорывной ИТ- миссии.
///Почему я считаю, что именно кардинальная смена стека\парадигмы или ЯП делают значительно мудрее? Каждый язык имеет свою философию и формирует у человека специфичный взгляд на решение технических задач.///
Чисто субъективное мнение, если оно личное автора, а может подаваться им просто "для затравки" обсуждения такого посыла.
Во первых, и главное из чего нужно исходить, так это понимание того, что процесс разработки серьезного программного обеспечения 1в1 повторяет процесс разработки технического изделия: проектирование, изготовление, контроль, тестирование и поддержка. Программист, как один из участников этой цепочки, выполняет функцию технолога (разработка техпроцесса изготовления конкретной детали, то есть алгоритма) и рабочего изготовляющего деталь на станке (кодирование процедуры, модуля на конкретном ЯП). Поэтому, если замыкаться только на функции изготовления детали, то есть только на функции разработки программного кода, то это делает такого программиста-кодировщика более универсальным в смысле знания нескольких ЯП и НЕ более того. Термин "мудрее" тут не уместен. Если со временем и с многолетней практикой, чаще в какой-то одной прикладной предметной области, такой программист-кодировщик освоит и научится выполнять ДРУГИЕ функции разработки - постановщика задачи, архитектора, управленца, разработчика БД, тестировщика и писателя документации - то тогда он действительно расширит свои профессиональные навыки как специалист-разработчик ПО вне зависимости от конкретного ЯП.
Вывод: язык программирования или конкретная СУБД конечно же играют большую роль в разработке ПО, но ОБЩИЕ принципы постановки задачи, проектирование архитектуры и БД для конкретной реализации (веб- приложение или что-то другое), управление разработкой и последующая поддержка программного продукта независимы от языка программирования.
Проблема Windows в ее гипер-сложности. Microsoft с упорством достойного лучшего применения старается "в одном флаконе" совместить потребности совершенно разных пользователей: технологических, офисных, домашних (бытовых). После Win7 компании нужно было оставить Windows как есть не усложняя ее для технологических и офисных пользователей (обычное колесо ведь давно работает !), а для домашних начать разработку принципиально новой ОС с пользовательским интерфейсом и простотой наподобие Android. Гипер-сложность будет требовать все более новых и новых выч.ресурсов, хотя принципиально ничего нового в саму операционную систему не привносится. Вдобавок это рано или поздно объективно будет негативно сказываться и на ее надёжности работы, а в конечном итоге придет в тупик.
По идее, для облегчения прикладной разработки, такие сложные процессы как асинхронность и многопоточность должны обеспечиваться и моделироваться инструментальными средствами более высокого уровня чем на уровне этих же корутин в Kotlin'e. То есть, по большому счету, такие высокоуровневые средства (в разной форме, вплоть до мастеров и шаблонов и ещё чего нибудь) должны поставляться к (с) конкретной операционной системой для облегчения разработки в ней приложений, чтобы разработчик мог максимально сфокусироваться на его прикладной части, а не углубляться в сложные и мелкие деталях реализации многопоточности и асинхронности. Для желающих же строить все "своими кирпичами" - пожалуйста используйте свои средства, в данном случае имеющиеся в языке программирования Kotlin.
Начинать надо с того, что программирование для ЭВМ и связанная с ним дисциплина проектирование (разработка) структуры базы данных, в силу своей особенной специфики, не всем студентам, в силу личных особенностей человека, доступно. Например, я знал хороших математиков, но которые так и не научились хорошо программировать, а тем более проектировать базы данных. Короче, не всем это подходит, так как требует навыки логического и аналитического мышления и которые не всем людям подвластны. Основной моделью данных, в которой представляется структура базы данных, вот уже более 50-ти лет, остаётся реляционная модель и, соответственно, под нее разработаны и реляционные СУБД. Поэтому, изучение надо начинать с этой модели, какие отношения между данными ей присущи (один ко многим, многие ко многим, один ко одному), понятие нормализации структуры БД, их формы. Лучше всего это последовательно демонстрировать на простом примере содержащем в конечном виде не более 8-10 таблиц. Но повторяю, что такой курс для не специализированных по ИТ учебных заведений должен быть факультативным (добровольным). Другое дело, это учить умению пользоваться базами данных и работать с ними. Аналог для сравнения: учить как проектировать и изготавливать автомобиль и учить как им управлять и ездить. В этом и есть принципиальная разница.
Самопиар и хвастовство.