Введение

Когда я впервые увидел эти символы, то подумал, что это имя индейского вождя:  буква Y напомнила венец из перьев желтокожего вождя из книжек о Диком Западе. И даже произнесение “YANG” вслух произвело такой эффект, что мой далеко не прыткий английский бульдог Бучо вскочил на четыре лапы.

• Зачем все это?
• Как с этим работать?
• Что это даст именно мне?

О чём этот пост

1. Это пост-обзор вариантов управления моделями данных, известных автору, на основе опыта, слухов, и чтения инструкций
2. Также этот пост — попытка классификации существующих вариантов управления моделями данных
3. Напоследок приводится идея и начальные штрихи в реализации системы управления моделями данных, которая не должна содержать недостатков предыдущих

Определения и ограничения

• Есть набор виртуальных «классов» в понятии бизнес-пользователя. Например, «сайт», «папка», «новость», и т.д. Каждый из таких классов имеет набор полей (аттрибутов).
• Пока что у нас нет наследования классов, а поля ограничены примитивными String/Integer/Long/Enum/Boolean, даже без multiple, но с возможными заданными значениями по умолчанию
• Каждый класс записывается в отдельную таблицу, например, objects_sites, objects_news, objects_folder, etc. Таблица всегда содержит ID объекта, а также колонки для полей.
• Нужно сделать так, чтобы загрузка этих объектов работала через JPA (Hibernate), с использованием необходимого кэширования/транзакций/Lazy-loading'а и других вкусностей, которые нам даёт JPA.

• В качестве баз данных — MySQL 5.0, InnoDB, три схемы базы данных (разные типы могут лежать в разных схемах, чтобы отделить системные типы от пользовательских)
• Sun JDK 6.0
• Tomcat 6 + JOTM 2.1.9 + Hibernate 3.5.0-Final (patched)
• Для создания классов использовалась связка CGLib 2.2 (входящая в Hibernate) и ASM 3.2 (в Hibernate входит 3.1)

Реализация ссылочной модели в языке программирования Аргентум:
Практический пример, сравнение с популярными языками, семантика операций, особенности многопоточности, внутреннее устройство.

Вместо введения

Для кого я решил написать? Данная статья, написана для моих коллег аналитиков или для тех, кто желал бы им стать. Если вы теперь захотели стать аналитиком, то подумайте хорошенько. 

Микросервисы. С хайпом вокруг них, лучше быть разработчиком, архитектором, тестировщиком, проджект-менеджером, дизайнером. Хорошо быть кем угодно в микросервсиах, но только не аналитиком. Аналитик ведь всегда во всем виноват. Ни разу не слышал, чтобы в “факапе” и срыве сроков обвинили архитектора, ну или там разработку. Нет, господа, вина всегда лежала и будет лежать на плохой документации и нечетко поставленных задачах. Вот вся команда собралась и тычет в тебя пальцами. Дескать, это все он! Опытный архитектор спроектировал, хороший разработчик сделал, внимательный тестировщик протестировал, мотивированный проджект-менеджер обеспечил… а невнимательный аналитик все завалил. А меж тем, материалов по аналитике и как её вести на русском языке очень мало. И как “анализировать” эти самые микросервисы не совсем понятно. Более того, никто вам не скажет, чем “системный аналитик” теперь отличается от “солюшн архитектора”. Вот во всем этом я и захотел разобраться и поделиться. Поэтому, если вы не аналитик - не читайте. Вам не будет интересно. Ведь, нет в вас экзистенциального кризиса и вопросов “Кто я? и зачем я им нужен на проекте”.

Привет!

Меня зовут Коля, и я системный аналитик.

В большинстве источников моделирование данных (в контексте создания приложений) рассматривается как последовательное создание трёх моделей данных - концептуальной, логической и физический. Такого порядка придерживаются, например, DMBOK2 и BABOK, а также многочисленные статьи в сети Интернет:

Рискну предложить несколько дополнений и уточнений к этому процессу - как на основании собственного опыта, так и обобщения опыта коллег, с которыми обсуждал этот вопрос.

В статье рассмотрен подход, основанный на разбиении структуры приложения на слои и подслои, который позволяет с единой позиции подойти к описанию основных используемых типов архитектуры приложений.

За созданием хранилища данных и особенно его поддержкой кроются жуткие монстры, пугающие в первую очередь бизнес, а уже потом IT-отдел.

В этой статье рассмотрим наиболее частые проблемы, касающиеся хранилищ данных, с которыми сталкивается менеджмент компании, а также способы их решения.

Всем привет! Меня зовут Елизавета Акманова, и я рада приветствовать вас в моей новой статье. Если вы помните, моя первая публикация касалась пяти ключевых трендов в бизнес-анализе. Сегодня я приглашаю вас отправиться в увлекательное путешествие под названием «Рекомендации по моделированию данных».

Отмечу, что в данной статье не будут рассмотрены технические аспекты, такие как типы баз данных, уровни нормализации, типы данных, и т.п. Эти вопросы не являются предметом обсуждения. Основное внимание будет уделено бизнес-целям создания модели данных. Я дам рекомендации по работе с моделями данных, основанные на моем личном опыте.

Первое, с чего хочется начать: что такое модель данных и база данных? Зачем их разделяют и в чем их принципиальное отличие?