Мне как фриланс-архитектору часто приходится сталкиваться с людьми из бизнеса, которые не понимают что такое ИТ, как там все происходит и зачем все эти страшные слова.
А когда люди не понимают о чем говорят они закрываются и боятся принять какое-либо решение. А так как мне нужно рассказать о своих способностях и том, чем я могу быть полезен, т.е. по сути продать свои услуги, мне часто приходится искать общие понятия, так сказать common ground. Когда люди начинают строить аналогии с тем, что им понятно, происходит уже более предметное обсуждение.
Часто встречаясь с одними и теми же проблемами, в конце концов, я решил поделиться своим опытом, возможно, это кому-то будет полезно в чистом виде, а кто-то поймёт принцип и придумает примеры и объяснения получше.
В этой статье я хочу рассказать об уровнях данных – Физическом, Логическом, Концептуальном.
Физический уровень
Физический уровень - это уровень базы данных. Я не буду рассказывать историю эволюции баз данных и про их типы. Для начала нужны базовые знания, на которые впоследствии можно наложить новые.
Итак, представьте себе, что у вас есть коробка для хранения и целый набор различных крепёжных элементов – болты, гайки, саморезы, гвозди, эксцентрики и прочее (рис.1)
Коробка - это и есть база данных, а крепёжные элементы — это данные.
Свалив все в коробку вы уже получили базу, содержащую данные. Теперь каждый раз, когда вам нужно что-то достать, вы будете открывать коробку и доставать из неё нужный элемент крепежа. При этом вам каждый раз придётся копаться во всей коробке.
Это называется неструктурированная и ненормированная база данных. Её преимущества в простоте и дешевизне.
Неудобства очевидны - это необходимость копаться во всей коробке в поисках конкретного элемента и тратить на это кучу времени. Конечно, через какое-то время вы запомните какие примерно элементы есть в коробке и если дюбелей в ней нет, то искать вы их не будете. И, конечно, постепенно вы выработаете какие-то свои правила поиска нужных элементов в куче.
Однако, то, что очевидно для вас, совсем не очевидно для другого человека. Для человека незнакомого с вашей коробкой и её содержим, поиск будет настоящим мучением.
Точно та же проблема будет стоять и перед любым ИТ-специалистом.
Со временем вы захотите навести больше порядка в своей коробке – т.е. её структурировать. Выделить каждому типу элементов свой контейнер, чтобы как можно быстрее находить нужное.
Для этого вы купите дополнительные контейнеры поменьше и раскидаете в них соответствующие элементы. Болты в один контейнер, гвозди в другой, гайки в третий и так далее.
При этом вы наверняка начнёте размещать наиболее часто используемые коробочки наверх, наиболее редко используемые вниз. Элементы, которые часто используете вместе, размещать рядом и так далее.
На языке ИТ это называется нормализация. А крепёжные элементы — это объекты.
После выполнения нормализации, в каждой коробочке будет находится свой тип объекта – гайки, болты или гвозди.
Нормализацию вы можете продолжать и дальше. Например, вы можете купить коробочки поменьше и разложить саморезы по металлу, дереву и бетону в разные.
Можете дополнительно разделить их по длине, цвету или скажем ходу резьбы.
Как и в случае с коробками, фанатичная нормализация базы данных создаёт те же проблемы – большой уровень вложенности и замедление поиска нужного элемента, которого просто может не оказаться в коробке.
Потому ИТ-специалисты всегда стараются соблюдать баланс между чёткой структурой и удобством её использования.
Поэтому иногда специально прибегают к денормализации.
Например, болт и гайка почти всегда используются вместе. Если следовать прямой логике структуризации – болты нужно положить в одну коробочку, а гайки в другую.
Но с точки зрения удобства, это хуже, т.к. приходится заглядывать в две коробочки и тратить на это время. Потому, вы можете пойти на осознанную денормализацию и положить болты и гайки в одну коробочку.
Если коробочек много или скажем они не прозрачны или ещё по каким-либо причинам удобства, вы можете наклеить на каждую коробочку метку – индекс.
С помощью таких индексов скорость поиска существенно повышается, т.к. вы точно знаете где что хранится и возможно что хранится в соседних коробочках.
Таким образом, организуя хранилище крепёжных элементов, вы можно сказать, что вы управляете базой данных.
Вы можете выполнять две основные операции над коробкой – извлекать элементы и класть элементы.
Конечно, вы можете осуществлять поиск, выбирать конкретные элементы или считать их количество. Т.е. то же самое, что и с базой данных.
При этом самой коробочке все равно какие типы элементов в ней хранятся, как они будут использоваться и как удобно вам с ним обращаться. Её задача хранить элементы.
Что делать с элементами или какой в них бизнес-смысл — это задача логического уровня.
Логический уровень
Однажды в моей жизни произошла забавная ситуация, когда я работал в крупной компании с процедурами, регламентами, базами заявок и прочее.
Мне нужно было чтобы от одного стола открутили перегородку, а к другому столу ее прикрутили. Конечной целью являлась прикрученная перегородка ко второму столу, а то, что её нужно было открутить от второго стола, воспринималось все равно что взять её у стены.
Потому и заявку я оставил на прикручивание перегородки к столу. Монтажник пришёл с шуруповёртом и был очень недоволен, что заявка на прикручивание перегородки, а нужно ещё открутить. Мы тогда посмеялись и спросили, помочь ли ему переключить шуруповёрт в режим реверса. Ведь с житейской точки зрения, это глупость чистой воды, возьми открути перегородку, потрать лишние 30 секунд.
Если посмотреть на ситуацию более системно, то все дело в том, что шуруповёрт давно был продуман и подготовлен к такой ситуации. Производитель давно подумал о функции реверса и потому отказ монтажника от того, чтобы открутить перегородку кажется абсурдным.
Но ведь ситуация могла быть и совсем другой, например, если бы он пришёл с шуруповертом, у которого нет функции реверса, и он физически мог бы только закрутить болт, но не мог бы его открутить.
На рисунке 3 представлена упрощённая логическая модель из примера с заявкой.
В ИТ-мире это особенно важно, ведь если перед программистом не стояло задачи реализовать реверс, то монтажник сделать ничего не сможет.
Обратите внимание, что мы говорим о тех самых объектах с физического уровня – болтах. Но операции, которые мы теперь выполняем над ними уже не достать или положить, а прикрутить или открутить. При том, что сами операции открутить или прикрутить, определяются направлением вращения отвёртки, а отнюдь не самим болтом.
Конечно, у болта есть свойство это направление резьбы, которая определяет в какую сторону нужно поворачивать отвёртку.
В ИТ-мире вы часто можете услышать слово атрибут объекта, вместо свойства.
При этом заметьте, что, если мы изменим направление резьбы, сами операции закрутить и открутить останутся, но нужно будет изменить направление вращения отвёртки.
Таким образом, когда мы говорим о логическом уровне работы с данными, мы говорим о каких-то осмысленных операциях над данными, позволяющими решать какие-то задачи.
Помимо списка операций, мы всегда думаем о ценности наличия тех или иных объектов, т. е. об их предназначении. Зачем нам эти объекты и что мы будем с ними делать?
Часто в ИТ-мире это называется бизнес-логикой или бизнес-смыслом.
Саморезу все равно, что на нем висит картина или роликовые коньки, у него есть свойство «несущая способность» и операция держать нагрузку. Но мы вкладываем в это разную ценность в одном случае мы добавляем эстетическую составляющую в комнате, в другом имеем удобную функцию хранения.
Подводя итог нужно сказать, что на логическом уровне мы определяем - свойства объектов (атрибуты), операции, предназначение (бизнес-логика).
Концептуальный уровень
Уровень концепции — это уровень верхнеуровневых рассуждений без деталей.
Мы часто используем этот уровень, даже не подозревая об этом.
Например, чтобы повесить картину на стену, нужен комплект крепления, который состоит из дюбеля, самореза и шуруповёрта. Я специально опускаю детали типа необходимости сверления отверстия или необходимости иметь дрель.
Концептуальный уровень позволяет нам определить основные объекты, их связи друг с другом, не впадая в детализацию (вес картины, длинна самореза и так далее).
Концептуальный уровень позволяет быстро сформировать набросок логической модели, договориться о понятиях и выровнять понимание.
В жизни мы часто очень неосторожно используем понятия, буквально жонглируем ими. Но когда дело доходит до автоматизации, часто возникают проблемы в реализации.
Один из моих любимых примеров на этот счёт является сервис Яндекс такси. Для пользование сервисом нужно создать аккаунт и согласиться с условиями соглашения (договора), т.е. стать Клиентом. При этом нужно привязать карту для оплаты, владельцем карты не обязательно должны быть вы, потому появляется понятие Плательщик. Однако, относительно недавно появилась функция – Такси другому человеку, которая явно указывает на тот факт, что пользоваться услугой может другой человек – Потребитель. (рис.4)
Здесь я специально не использую слово пассажир, т.к. хочу сфокусировать ваше внимание на ключевых объектах и их отношениях.
Краткий итог по данным и их уровням
Физический уровень – как организовываем и храним данные.
Логический уровень – описываем и манипулируем данными.
Концептуальный – рассуждаем о данных и их связях.
Надеюсь, статья была вам полезной и занимательной.
P.S.: эта статья не для ИТ специалистов, статья рассчитана на средне статического человека, не связанного с ИТ, с максимальным упрощением. А как в любом упрощении, в статье сделаны осознанные допущения и упущены некоторые детали.
Например, объяснить что такое ключи и гипер ссылки, я не стал да и пример для этого нужен другой.
