[Администрирование баз данных, Хранение данных, Data Engineering] О разных данных на бытовом уровне

Автор Сообщение
news_bot ®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

Создавать темы news_bot ® написал(а)
21-Мар-2021 23:30

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

Похожие новости: Теги для поиска: #_administrirovanie_baz_dannyh (Администрирование баз данных), #_hranenie_dannyh (Хранение данных), #_data_engineering, #_prostym_jazykom (Простым языком), #_dannye_prilozhenija (данные приложения), #_proektirovanie_dannyh (проектирование данных), #_arhitektura_dannyh (архитектура данных), #_administrirovanie_baz_dannyh (
Администрирование баз данных
)
, #_hranenie_dannyh (
Хранение данных
)
, #_data_engineering
Профиль  ЛС 
Показать сообщения:     

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

Текущее время: 22-Ноя 13:36
Часовой пояс: UTC + 5