4-я ЛЕКЦИЯ ОБ ОРГАНИЗАЦИИ ДАННЫХ
(ФРАГМЕНТ)
&2. Устранение типизации (второй контринтуитивный принцип)
Из примера про скрепку мы уже знаем как драматически прирастает число взаимосвязей при добавлении сущностей, давайте разберём ещё один модельный пример.
Предположим, нам необходимо разложить несколько тысяч книг по стеллажам. Все эти книги разные: есть там и детективы, есть фантастика, есть учебники по сопромату, есть стихи малоизвестных румынских поэтов; эти книги из сотен разных стран, за разные временные периоды, разных авторов и т.п.
У нас есть залы, стеллажи и полки. Как мы распределим книги, чтобы их находить быстро, и ходить поменьше? Завести ли нам зал "Фантастика" или зал "История древнего мира" или всё поделить на "Художественное" и "Научное", а уже внутри по жанрам и странам? Или как-то иначе? При этом, надо помнить, что и перестроек в библиотеке не должно быть очень много.
Предположим, мы завели зал научной фантастики, в этом зале стеллажи поставили "по странам", а внутри "по датам", а внутри дат "по алфавиту" (фамилии авторов). И вот нас попросили принести книгу Stanislaw Lem "Solaris". Если мы знаем её ID, то мы заглянем "куда следует" и узнаем, что книга с таким ID лежит в зале "Фантастика", на стеллаже "Польская Фантастика", на полке "книги 60-х" и там просмотреть до буквы L.
Вопрос: "Зачем мы придумали всю эту раскладку со всеми этими именами ("Фантастика", "Польская фантастика" и/или др. ), с тем же успехом можно было просто указать: книга с таким-то ID лежит в 1-м зале, на 2 стеллаже, на третьей полке"?
При этом, совершенно неважно, что лежит ещё на этой полке в этом зале. Мы найдём также быстро, если там рядом будет лежать "что угодно", но зато точно сэкономим пространство. Ведь, если мы не будем заранее отводить залы под "жанры", а стеллажи - под "страны" и т.д. - то есть не будем "типизировать", то мы и не будем загадывать и отводить и резерв площади под каждое "направление", а будем просто "линейно" и экономно заполнять пространство "чем угодно".
(Понятная аналогия с программированием: тут мы спрашиваем какое резервное пространство запроектировать под польскую фантастику 60-х годов или - общем виде - под жанр N, страны М, временного периода Х, автора на Y (и никогда не угадаем этого резерва, поэтому заложим избыток площадей/стеллажей и всё равно "налетим" на противоречие). Когда программист рассуждает схожим образом, то спрашивает себя: какой объём памяти выделить соответствующим переменным? Но даже, если память выделяется динамически, всегда "налетит" на противоречие или - по крайней мере - будет использовать её избыточно и не оптимально).
Но рассмотрим случай, когда мы не знаем никакого ID и, тем не менее, надо узнать, где у нас лежит книга "Solaris", 1960 года, автор Lem, поляк? А заодно может быть узнать ID, если таковой есть (просто мы его не знаем).
Если бы не было никакой системы хранения, то, конечно, бедный библиотекарь, не знал бы, куда ему идти, и - в предельном случае - пришлось бы перебирать всё подряд. Именно для того, чтобы такого не случилось, сведения о книгах и упорядочили по жанрам, странам, авторам и т.д. Но, внимание, зачем это упорядочили именно так? То есть, зачем завели "переменные": "Жанр", "Страна", "Имя автора" и т.д.? Ведь задача "найти" никак не связана с задачей "типизировать". Мы не типизируем и не классифицируем. Мы делаем так, чтобы быстро найти. Это не одно и тоже.
Обострим ситуацию. Пусть имеется "куча-мала" самых разнообразных записей о любых штуковинах с самими разнообразными свойствами, а не только книги (назовём эту "кучу" - "chaotic sets of any" или просто "chaotic sets"). Если "куча" очень большая, то её разделяют на несколько меньших и создают правило к какой "кучке" обратиться.
Например (Вариант 1):
- "группа" записей о штуковинах, где длина записи до 10 символов;
- "группа" записей о штуковинах, где длина записи от 11 до 30 символов;
- "группа" записей о штуковинах, где длина записи от 31 до 50 символов;
- и т.п.
Обратите внимание: эти "группы" НЕ должны быть типизированы - это просто разные "кучки". Они могут разделяться, хоть по числу символов или иному простому вычисляемому принципу.
А вот так нельзя (Вариант 2):
- в этой "группе" - записи о книгах,
- в этой "подгруппе" - о детективах,
- в этой "подгруппе" - о фантастике,
- в этой "подподгруппе" - о научной фантастике,
- в этой "подподгруппе" - о фэнтэзи
- и т.д.,
- в этой "подгруппе" - о поэзии,
- в этой "подподгруппе" - об английской поэзии,
- в этой "подподгруппе" - о французской поэзии
- и т.д.,
- в этой "группе" - записи о ботинках,
- в этой "группе" - записи о растениях
- и т.д.
Во-первых, не удастся упорядочить все сущности одновременно и полно, и непротиворечиво.
Например, может потребоваться в подгруппу о поэзии добавить не только географию, но и жанры (например, "баллада", "канцона", "экспромт", "лимерик" , "хокку" и т.д. - и т.д. - их очень много ). И тогда сразу можно будет убедиться в том, что структура, предложенная в варианте 2 не подойдёт. Станут очевидны противоречия между группировкой по странам и группировкой по жанрам, а также иные противоречия.
Например, если в раздел о поэзии добавить жанры, а не только географию, уже можно запутаться, а если Вам, всё же, удастся непротиворечиво впихнуть жанры в эту структуру, то появление всякой следующей сущности снова создаст противоречия.
Для примера рассмотрим, куда, пользуясь вариантом 2, нам поставить книги писателя Ерошенко, который, путешествуя по миру, писал в дневниках стихи, перемежающиеся прозой в разных жанрах на нескольких языках, в том числе, на японском и эсперанто или его же лекции о русской литературе на китайском языке.
То есть, некорректными будут любые утверждения вида: "запись о книге должна находиться в ДАННОЙ подгруппе (А), поскольку - это книга (а не ботинок), поскольку это научная фантастика, поскольку это не английская книга и т.д.".
Мы не сможем доказать, что не случится ситуации, когда "запись о той же самой книге должна находиться также и в ИНОЙ подгруппе (не-А), например, поскольку это не только фантастика, но одновременно и детектив, и/или имеем общий псевдоним сразу двух авторов и/или иное.
Конечно, можно снять возникшее противоречие, перестроив/дополнив систему вышеприведённых утверждений, то есть предусмотрев и подобный случай. Но, видите ли, мы так будем её постоянно перестраивать, поскольку подобные коллизии будут появляться регулярно.
И будем помнить, что всякая такая "перестройка" с большой степенью вероятности повлечёт за собой переписывание соответствующих инструкций, перекладку книг, передвигание стеллажей и дополнительную работу людей, а также и дополнительное обучение, равно и модификацию кода обслуживающих программ (см. далее) и транспорт данных. И такая катавасия будет происходить достаточно часто.
Если абстрагироваться от примера с книгами, то вышеизложенное можно записать следующим образом:
"Некорректными будут любые утверждения вида: "Запись о Сущности "X" должна находиться в конкретной группе (А), поскольку эта сущность описывается определённым набором свойств (Specific sеt of properties). Ибо всегда возможна ситуация, когда "запись о той же самой сущности должна находиться также и в ИНОЙ группе (не-А), поскольку ранее объявленный Specific set of properties (с ударением на слово "specific") неполон. Именно набор наших представлений (стереотип) о “специфичном” для каждого случая, по мере развития любого проекта, становится неполным. А когда мы его дополняем, система становится противоречивой.
Ни доказать, ни опровергнуть достаточность (полноту) любого специфичного набора свойств и одновременно его непротиворечивость мы не можем.Всякая непротиворечивая модель организации данных будет неполна.
Доказал это, как известно, Курт Гёдель, первая теорема которого о неполноте гласит: "Аксиоматика любой формальной системы неполна и содержит неразрешённые предположения". Повторять его доказательство здесь мы не будем, оно легко находится в Сети. В нашем случае достаточно формулировать так: любой набор свойств (по условию) будет либо неполным, либо противоречивым.
В общем, вариант 2 нам не подходит. И это было объяснение "во-первых", почему он плох.
Во-вторых, нет самой необходимости создавать "полную и непротиворечивую классификацию". Свойства - это не полки. Нам надо быстро найти сущность, а не описать мир.
А тогда как же мы поступим, в соответствии с Вариантом 1?
- Поскольку в слове "Solaris" - 7 символов, то идём в соответствующий зал "1-10" (а не "Научная фантастика").
- А стеллажи в нём пусть будут устроены по алфавиту (не обязательно: один стеллаж = 1 буква; можно, например, "Стеллаж А-D", "Стеллаж E-H" и т.д.), а не "Страна" или др.
- Так что, если бы у нас была не только библиотека самых разнообразных книг, а большой склад самых разнообразных товаров, то на одном стеллаже (и даже в одной ячейке) с книгой "Solaris" могли бы находиться туфли "Salomon", колечко "Tiffany" и т.д. И это разнообразие облегчило бы нам поиск, а не усложнило его. И Вы, вероятно, сразу вспомните пример, c адресным хранением товаров на складах, который мы подробно разбирали во второй главе. Поскольку это оно и есть.
Получается, вопреки интуиции, что, если мы типизируем, мы ищем долго и алгоритмы наши "кривые и пухнущие", а программы медленные. Если же работаем c chaotic sets - быстро, а наши алгоритмы будут просты и - скорее всего - меняться не будут. И это наш второй контринтуитивный принцип, поскольку, конечно, очень трудно удержать себя от "наведения порядка" и полюбить работу с "беспорядочными кучками" вместо выдумывания "концепций" или "моделей данных". Теперь давайте рассмотрим ситуацию, когда кто-то для нашей библиотеки подрядился писать базу данных, причём мы стали выдавать не только книги, но и музыку, как на носителях, так и виде файлов, вдобавок появились и аудиокниги...
(конец фрагмента)
Материал опубликован на сайте "Открытые бизнес-методики и технологии TRIZ-RI" 17 июля 2020 г.