Модель рм т база данных: Модели баз данных — Национальная библиотека им. Н. Э. Баумана

Мета-данные. На пути к идеалам управления моделями данных / Хабр

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

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

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

Предполагается, что читатель является (или когда-нибудь станет) разработчиком Enterprise Application, которому часто нужно писать быстро и качественно, но не боящегося лезть в дебри JPA/JTA/RMI чтобы «подкрутить напильником» особо тонкие места.

Данные — то, что хранится в базе данных приложения. Данные о клиентах, пользователях, заказах и т.п.

Метаданные — описание структуры данных. Описание того, какие типы объектов хранятся в базе данных, какие у них есть поля (аттрибуты, элементы), описание зависимостей между объектами. В общем случает типы могут наследовать атрибуты родительского типа, а один атрибут в общем случае может присутствовать у двух и более типов, несвязанных отношением наследования.

Enterprise Application работает с использованием (чаще всего) Application Server’а (WebLogic, JBOSS) и некоторой РСУБД (Oracle, Informix, MySQL). Хотя автор не видит ничего зазорного в самостоятельной сборке AS на основе Tomcat/Hibernate/JOTM/DBCP/etc, это очень и очень интересно, но за рамками данного топика.

В качестве РСУБД предполагается одна из тех стандартных, которая поддерживается Hibernate/OpenJPA.

В топике используются термины из XML Schema: пространство имён, тип, атрибут. Последним двум в некоторой степени соответствуют понятия Java класс (объект класса, бин) и свойство (property, aka get+set, также иногда просто поле, field).

Введение. Простейший случай

Большие приложения — чаще всего это не только приложения с большим объёмом данных. Чаще всего это приложения работающие с большим количеством разнородных данных, имеющих разную структуру с точки зрения бизнес-логики. (Кстати, последнее важно — структура данных может быть различной на уровне СУБД, на уровне приложения и даже внутри него)

Самым простым случаем является определение модели данных в виде набора классов и соответствующих ему набору таблиц в базе данных. Грубо говоря: один класс — ода таблица в базе данных. Каждое свойство объекта представлено свойством (property) класса-бина и колонкой в базе данных. Однако, подобный механизм имеет недостатки, которые проявляются при разработке и использовании Enterprise приложения:

• Добавление или изменение модели данных потребует изменения как структуры базы данных, так и кода программы с последующей перекомпиляцией и т.д.
• Как следствие, нельзя это сделать «на лету»
• Сложные изменения, такие как перенос атрибута из дочернего типа в родительских, потребует также написание ручных скриптов (DDL+DML) на обновление структуры базы
• Изменение структуры требует от специалиста знания SQL/Java

Нужно, однако, отметить и плюсы подобного подхода:

• Лучшая цена за хорошую производительность. Буквально «out-of-the-box» мы получаем самую прозрачную структуру хранения данных, самую очевидную как для JPA-прослойки (hibernate, etc), так и для РСУБД (и её администратора).
• С точки зрения программиста бизнес-логики, не меняющего структуру данных, самый удобный API мы также получаем out-of-the-box

Заметьте в последнем предложении важное уточнение — «бизнес-логики». Речь идёт об описании процессов взаимодействия структур данных, их изменении и пр. — то есть кода, который должен знать и знает о структуре данных. Но если, например, мы говорим про редактирование бинов через WEB-интерфейс (или любым другим способом), то для написания редактора, который может редактировать 80% объектов, не зная заранее их структуры (т.н. generalized), нам придётся разбираться с Reflection/Beans/etc и другими, в принципе, не очень страшными словами. (Страшные — в конце топика).

Современные средства проектирования позволяют автоматизировать часть процессов связанных с обновлением, например, структуры базы данных по коду, либо наоборот — сгенерировать или обновить код по описанию структуры данных. Не уверен, но, думаю, существуют средства создания одновременно и кода, и структуры базы данных на основе некой абстрактной схемы данных, записанной, например, в виде XML Schema. (Код так точно можно сгенерировать — см. XML Beans и пр.). Однако все эти средства работают в «offline» и не затрагивают работающее приложение (если вы, конечно, не сделаете обновление прямо по «живому», но ничего хорошего из этого не бывает).

Кстати, некоторые из вспомогательных утилит можно заставить и формочки для каждого типа объектов нарисовать.

Гибкие структуры данных

Самой гибкой можно считать структуру, в которой каждый объект хранится как запись в базе данных в виде, ну, например, XML. То есть большая-большая таблица, в которой две колонки — ID объекта и его содержание в виде XML. Как вы правильно догадываетесь, основной недостаток подобной структуры — очень низкая производительность базы данных в тот момент, когда нам нужно будет вычислить, ну например, всех клиентов из города «Москва». Для этого придётся базе данных распарсить каждое значение.

Чтобы структура осталось гибкой, но поменьше нагружать базу данных, объект разбивают на кусочки и выносят в отдельные таблицы. Например,

— Объекты: ID, обязательное поле 1, обязательное поле 2

— Значения: ID объекта, идентификатор аттрибута, значение

Можно пойти дальше и, без ограничения гибкости, разделить атрибуты разных типов по разным таблицам или колонкам. Подобная схема успешно применяется в приложении (вырезано) для обработки данных в несколько терабайт.

Ещё недостатки:

За гибкость нужно платить. Во-первых, слой работы с данными придётся писать самостоятельно. Во-вторых, возникает большое желание сэкономить и оставить для бизнес-логики API, который бы отражал структуру базы данных:

— дай объект ID такой-то

— дай аттрибут ID такой-то

— обнови значение

— запиши аттрибут ID такой-то объекта такой-то

— обнови версию объекта (+1)

Конечно, с точки зрения программиста generalized редактора данных очень удобно иметь методы вроде getAllAttributes(). Однако с точки зрения бизнес-логики это неудобно, особенно если нужно помнить все ID нужных атрибутов (они могут быть и числовыми).

Нужно отметить, однако, что API в общем случае не обязан совпадать со структурой базы данных. Главное — чтобы 80% действий выполнялись самым простым и очевидным способом. То есть если у нас в базе хранятся клиенты, получение имени клиента или его адреса должна быть одна строка кода вроде client.getAddress(). Однако для гибких структур написание таких оболочек может сильно подорвать производительность, во-вторых, структуры имеют обыкновение меняться…

Однако если такие оболочки не пишет тот, кто отвечает за написание процедур доступа к данным, будьте готовы, что через пару лет у вас будет столько оболочек «упрощённого» доступа к данным, сколько инициативных программистов работают со «стандартным» API.

Структуры с ограниченными возможностями

В этом разделе хочется рассказать ещё об одном подходе, которая используется в одной малоизвестной CMS.

С точки зрения кода доступ к атрибутам объекта осуществляется таким же образом, как и у гибких структур — через методы вроде getAttribute / getAllAttributes / etc. Однако для CMS, основная задача которой редактировать объекты по отдельности (без relations между объектами), а также просто вывести объект в XML для дальнейшей обработки — данного API вполне хватает.

Интересно то, что список типов данных хранится в некотором конфигурационном файле. Также в этом файле для каждого типа хранится список аттрибутов и их тип. На основании конфигурационного файла при запуске создаётся или обновляется структура таблиц. В дальнейшем «на лету» при изменении структуры данных таблицы обновляются.

Плюсы:

— очевидная модель данных для СУБД

— гибкость «на лету»

Минусы

— с точки бизнес-логики API слишком гибкий (см. предыдущий раздел)

— нужно писать свою систему доступа к данным, которая в настоящий момент, к сожалению, в отличии от системных объектов (пользователи, группы, etc) игнорирует транзакции, кеши и прочие прелести

Классификация… попытка

Если мы рассматриваем метамодель, то для её описания нужно ответить на следующие вопросы:

• что является отправной точкой для описания модели? (разумеется, это должна быть одна точка) Где хранится информация об объектах и их аттрибутах?
• как организовано хранение данных в БД?
  • выполнены ли требования первой нормальной формы?
  • Два разных простых (не multiple) атрибута хранятся:
    • в виде двух разных колонок
    • в виде двух разных строк

• как организован доступ к данным на уровне Application Server’а?
  • используются стандартные методы JPA (EntityManager, etc)
  • используются свои классы доступа к данным

• как организован доступ к данным на уровне бизнес-логики?
  • используются стандартные методы вроде getName(), getAddress(), etc
  • используются нестандартный API вроде getAttribtute(ID…)

• есть ли доступ к мета-данным из программы?
  • есть, и даже можно изменять
  • есть
  • только через Reflections / Hibernate Mapping / etc

Хочу… идеальная для автора

Из предыдущего пункта легко выводятся требования к идеальной (с точки зрения автора) системе описания и оперирования моделями данных:
— описание структуры данных должно быть в базе данных, что позволит оперативно изменять описание модели, возможно — через само приложение
— сами данные при этом должны хранится в нормализованной (вплоть до 3-4 формы) базе данных, где каждому типу соответствует своя таблица данных. Система управления должна сама заботится о поддержании схемы базы данных в соответствии с мета-данными.
— доступ к данным должен осуществляться через стандартные интерфейсы JPA / EntityManager.
— с точки зрения бизнес-логики основные поля основных объектых типов должны быть доступны через простой API без дополнительного resolving / casting / narrowing (т.е. сразу после загрузки из EntityManager)
— но система должна также обеспечивать доступ к мета-данным. В том числе для конкретного объекта — получения списка всех полей.

В настоящее время автор занимается написанием подобной системы, используя:

— Hibernate — как драйвер доступа к данным

— CGLIB / ASM — для динамического конструирования классов на основе их описания, включая аннотации для Hibernate

— XML Schema — для описания типов данных и их атрибутов

Но об этом в следующий раз.

Модели баз данных | Системы управления базами данных

СУБД используют различные модели данных. Самые старые системы можно разделить на иерархические и сетевые базы данных — это пререляционные модели.

В иерархической модели элементы организованы в структуры, связанные между собой иерархическими или древовидными связями. Родительский элемент может иметь несколько дочерних элементов. Но у дочернего элемента может быть только один предок.

«Система управления информацией» (Information Management System) компании IMB — пример иерархической СУБД.

Иерархическая модель организует данные в форме дерева с иерархией родительских и дочерних сегментов. Такая модель подразумевает возможность существования одинаковых (преимущественно дочерних) элементов. Данные здесь хранятся в серии записей с прикреплёнными к ним полями значений. Модель собирает вместе все экземпляры определённой записи в виде «типов записей» — они эквивалентны таблицам в реляционной модели, а отдельные записи — столбцам таблицы. Для создания связей между типами записей иерархическая модель использует отношения типа «родитель-потомок» вида 1:N. Это достигается путём использования древовидной структуры — она «позаимствована» из математики, как и теория множеств, используемая в реляционной модели.

Рассмотрим в качестве примера иерархической модели данных организацию, хранящую информацию о своём работнике: имя, номер сотрудника, отдел и зарплату. Организация также может хранить информацию о его детях, их имена и даты рождения.

Данные о сотруднике и его детях формируют иерархическую структуру, где информация о сотруднике – это родительский элемент, а информация о детях — дочерний элемент. Если у сотрудника три ребёнка, то с родительским элементом будут связаны три дочерних. В иерархической базе данных отношение «родитель-потомок» — это отношение «один ко многим». То есть у дочернего элемента не может быть больше одного предка.

Иерархические БД были популярны, начиная с конца 1960-х годов, когда компания IBM представила свою СУБД «Система управления информацией. Иерархическая схема состоит из типов записей и типов «родитель-потомок»:

• Запись — это набор значений полей.
• Записи одного типа группируются в типы записей.
• Отношения «родитель-потомок» — это отношения вида 1:N между двумя типами записей.
• Схема иерархической базы данных состоит из нескольких иерархических схем.

В сетевой модели данных у родительского элемента может быть несколько потомков, а у дочернего элемента — несколько предков. Записи в такой модели связаны списками с указателями. IDMS («Интегрированная система управления данными») от компании Computer Associates international Inc. — пример сетевой СУБД.

Иерархическая модель структурирует данные в виде древа записей, где есть один родительский элемент и несколько дочерних. Сетевая модель позволяет иметь несколько предков и потомков, формирующих решётчатую структуру.

Сетевая модель позволяет более естественно моделировать отношения между элементами. И хотя эта модель широко применялась на практике, она так и не стала доминантной по двум основным причинам. Во-первых, компания IBM решила не отказываться от иерархической модели в расширениях для своих продуктов, таких как IMS и DL/I. Во-вторых, через некоторое время её сменила реляционная модель, предлагавшая более высокоуровневый, декларативный интерфейс.

Популярность сетевой модели совпала с популярностью иерархической модели. Некоторые данные намного естественнее моделировать с несколькими предками для одного дочернего элемента. Сетевая модель как раз и позволяла моделировать отношения «многие ко многим». Её стандарты были формально определены в 1971 году на конференции по языкам систем обработки данных (CODASYL).

Основной элемент сетевой модели данных — набор, который состоит из типа «запись-владелец», имени набора и типа «запись-член». Запись подчинённого уровня («запись-член») может выполнять свою роль в нескольких наборах. Соответственно, поддерживается концепция нескольких родительских элементов.

Запись старшего уровня («запись-владелец») также может быть «членом» или «владельцем» в других наборах. Модель данных — это простая сеть, связи, типы пересечения записей (в IDMS они называются junction records, то есть «перекрёстные записи). А также наборы, которые могут их объединять. Таким образом, полная сеть представлена несколькими парными наборами.

В каждом из них один тип записи является «владельцем» (от него отходит «стрелка» связи), и один или более типов записи являются «членами» (на них указывает «стрелка»). Обычно в наборе существует отношение 1:М, но разрешено и отношение 1:1. Сетевая модель данных CODASYL основана на математической теории множеств.

Известные сетевые базы данных:

• TurboIMAGE;
• IDMS;
• Встроенная RDM;
• Серверная RDM.

В реляционной модели, в отличие от иерархической или сетевой, не существует физических отношений. Вся информация хранится в виде таблиц (отношений), состоящих из рядов и столбцов. А данные двух таблиц связаны общими столбцами, а не физическими ссылками или указателями. Для манипуляций с рядами данных существуют специальные операторы.

В отличие от двух других типов СУБД, в реляционных моделях данных нет необходимости просматривать все указатели, что облегчает выполнение запросов на выборку информации по сравнению с сетевыми и иерархическими СУБД. Это одна из основных причин, почему реляционная модель оказалась более удобна. Распространённые реляционные СУБД: Oracle, Sybase, DB2, Ingres, Informix и MS-SQL Server.

«В реляционной модели, как объекты, так и их отношения представлены только таблицами, и ничем более».

РСУБД — реляционная система управления базами данных, основанная на реляционной модели Э. Ф. Кодда. Она позволяет определять структурные аспекты данных, обработки отношений и их целостности. В такой базе информационное наполнение и отношения внутри него представлены в виде таблиц — наборов записей с общими полями.

Реляционные таблицы обладают следующими свойствами:

• Все значения атомарны.
• Каждый ряд уникален.
• Порядок столбцов не важен.
• Порядок рядов не важен.
• У каждого столбца есть своё уникальное имя.

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

Часто у полей будет одно и то же имя в обеих таблицах. Например, таблица «Заказы» может содержать пары «ID-покупателя» и «код-товара». А в таблице «Товар» могут быть пары «код-товара» и «цена». Поэтому чтобы рассчитать чек для определённого покупателя, необходимо суммировать цену всех купленных им товаров, использовав JOIN в полях «код-товара» этих двух таблиц. Такие действия можно расширить до объединения нескольких полей в нескольких таблицах.

Поскольку отношения здесь определяются только временем поиска, реляционные базы данных классифицируются как динамические системы.

Первая модель данных, иерархическая, имеет древовидную структуру («родитель-потомок»), и поддерживает только отношения типа «один к одному» или «один ко многим». Эта модель позволяет быстро получать данные, но не отличается гибкостью. Иногда роль элемента (родителя или потомка) неясна и не подходит для иерархической модели.

Вторая, сетевая модель данных, имеет более гибкую структуру, чем иерархическая, и поддерживает отношения «многие ко многим». Но быстро становится слишком сложной и неудобной для управления.

Третья модель — реляционная — более гибкая, чем иерархическая и проще для управления, чем сетевая. Реляционная модель сегодня используется чаще всего.

Объект в реляционной модели определяется как позиция информации, хранимой в базе данных. Объект может быть осязаемым или неосязаемым. Примером осязаемого объекта может быть сотрудник организации, а примером неосязаемой сущности — учётная запись покупателя. Объекты определяются атрибутами — информационным отображением свойств объекта. Эти атрибуты также известны как столбцы, а группа столбцов — как ряд. Ряд также можно определить как экземпляр объекта.

Объекты связываются отношениями, основные типы которых можно определить следующим образом:

В этом виде отношений один объект связан с другим. Например, Менеджер -> Отдел.

У каждого менеджера может быть только один отдел, и наоборот.

В моделях данных отношение одного объекта с несколькими. Например, Сотрудник -> Отдел.

Каждый сотрудник может быть только в одном отделе, но в самом отделе может быть больше одного сотрудника.

В заданный момент времени объект может быть связан с любым другим. Например, Сотрудник -> Проект.

Сотрудник может участвовать в нескольких проектах, и каждый проект может объединять несколько сотрудников.

В реляционной модели объекты и их отношения представлены двухмерным массивом или таблицей.

Каждая таблица представляет объект.

Каждая таблица состоит из рядов и столбцов.

Отношения между объектами представлены столбцами.

Каждый столбец представляет атрибут объекта.

Значения столбцов выбираются из области или набора всех возможных значений.

Столбцы, которые используются для связи объектов, называются ключевыми. Есть два типа ключей — первичные и внешние.

Первичные служат для однозначного определения объекта. Внешний ключ — это первичный ключ одного объекта, существующий как атрибут в другой таблице.

Преимущества реляционной модели данных:

1. Простота использования.
2. Гибкость.
3. Независимость данных.
4. Безопасность.
5. Простота практического применения.
6. Слияние данных.
7. Целостность данных.

Недостатки:

1. Избыточность данных.
2. Низкая производительность.

В последнее время на рынке СУБД появились продукты, представленные объектными и объектно-ориентированной моделью данных, такие как Gem Stone и Versant ОСУБД. Также производятся исследования в области многомерных и логических моделей данных.

Особенности объектно-ориентированных систем управления базами данных (ООСУБД):

• При интеграции возможностей базы данных с объектно-ориентированным языком программирования получается объектно-ориентированная СУБД.
• ООСУБД представляет данные как объекты одного или нескольких языков программирования.
• Такая система должна отвечать двум критериям: являться СУБД и должна быть объектно-ориентированной. То есть должна насколько это возможно соответствовать современным объектно-ориентированным языкам программирования. Первый критерий подразумевает: длительное хранение данных, управление вторичным хранилищем, параллельный доступ к данным, возможность восстановления, а также поддержку нерегламентированных запросов. Второй критерий подразумевает: сложные объекты, идентичность объектов, инкапсуляцию, типы или классы, механизм наследования, переопределение в сочетании с динамическим связыванием, расширяемость и вычислительную полноту.
• ООСУБД дают возможность моделирования данных в виде объектов.

А также поддержку классов объектов и наследование свойств и методов классов подклассами и их объектами.

На данный момент не существует общепринятого стандарта ООСУБД. Считается, что подобные модели данных находится на ранней стадии развития.

Примеры ООСУБД:

• D Gemstone;
• IRS;
• ORION;
• ONTOS.

Применение ООСУБД:

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

Данная публикация представляет собой перевод статьи «Types of Database Models | Database Management System» , подготовленной дружной командой проекта Интернет-технологии.ру

телеграм канал. Подпишись, будет полезно!

Основные модели баз данных — Разные уроки по Программированию

    1) Иерархическая — представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней,  структура запись-потомок должна иметь в точности одного предка.

    В 1968 году была введена в эксплуатацию первая промышленная СУБД система IMS фирмы IBM. Это была первая иерархически база данных благодаря которой определили ряд фундаментальных понятий в теории систем баз данных, которые и до сих пор являются основополагающими для сетевой модели данных.

Такая форма используется:

    a. Серверы каталогов, такие, как LDAP и Active Directory (допускают чёткое представление в виде дерева)

    b. файловые, база настроек Windows WMI и Реестр Windows.

    2) Сетевая — являющаяся расширением иерархического подхода, сетевой структуре данных у потомка может иметься любое число предков. 

    Такая модель данных используется:

        1) в графических системах для формирования 3D изображений. 

        2) в системах пространственной координации объектов.

    3) Реляционная — данные в базе данных представляют собой набор отношений. Отношения (таблицы) отвечают определенным условиям целостности. Реляционная модель данных поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения 

и уровня базы данных.

    Такая форма используется:

        a. Oracle

        b. MS SQL, MY SQL

        c. Potgresql

        d. MS Access

    4) Объектная и объектно-ориентированная – Данные в таких базах представляют из себя объекты с определенными наборами свойств и методов и поведения. Отношения данных объектов строятся на основе  обобщения свойств и методов и поведения различных объектов по отношению

ORM или как забыть о проектировании БД / Хабр

От автора

Прошел год как я сменил профессию сетевого администратора на профессию программиста. За этот год было много необычного и странного. Удалось плотно поработать с sqlalchemy, взглянуть на ponyorm, поиграться с hibernate и nhibernate, освежить models из django… и знаете что? Весь код который я видел ассоциировался у меня с последствиями деятельности обезьяны имеющей запас гранат… оказалось что пускать программистов к бд — не самая лучшая затея. Под катом много боли и ненависти, но вдруг кому-то пригодится.

Прежде чем начать, хочу ввести пару допущений:

1. Весь текст представляет собой IMHO
2. Все имена и кейсы — синтетичны. Любое совпадение с реальными проектами и персоналями — случайность.
3. У автора большие проблемы с Великим и Могучим (боремся через личные сообщения)

Что такое ORM?

Прежде чем учить кого-то уму-разуму стоит понять что представляет из себя термин ORM. Согласно аналогу БСЭ, аббревиатура ORM скрывает буржуйское «Object-relational mapping», что в переводе на язык Пушкина означает «Объектно-реляционное отображение» и означает «технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования»… т.е. ORM — прослойка между базой данных и кодом который пишет программист, которая позволяет созданые в программе объекты складывать/получать в/из бд.
Все просто! Создаем объект и кладем в бд. Нужен этот же объект? Возьми из бд! Гениально! НО! Программисты забывают о первой буковке абравиатуры и пхнут в одну и ту же табличку все! Начиная от свойств объектов, что логично, и, заканчивая foreign key, что никакого отношения к объекту не имеет! И, что самое страшное, многие тонны howto и example пропагандируют такой подход… мне кажется что первопричина кроется в постоянной балансировке между «я программист» и «я архитектор бд», а т.к. ORM плодятся и множатся — голос программиста давлеет над архитекторским. Все, дальше боли нет, только imho.

«Кто Вы, Мистер Брукс?» или «Что такое объект?»

Как определить «что такое объект» в ORM? Сколько человек смогут с первого раза донести весь смысл? Давайте я попробую.
Предположим что все мы живем на территории Белоруссии/Украины/России, прям как я. Согласно законодательству, в стране запрещены однополые браки и многоженство. При этом есть понятие «воинской обязанности» и прочих «специфичных» для каждого пола свойств. Что из этого следует?

1. Для каждого пола желательно (но не принципиально) иметь свою табличку
2. Где-то надо хранить информацию о принадлежности мужа жене и обратно

«Дык это ж OneToOne! Классика! Чего тут сложного? Определим fkey у строки для мужского или женского пола и побежали дальше» — ага, я умею читать мысли. НО! Наше ПО через год стало интересно арабским шейхам и они недоумевают, как так, не более 1 жены?!?! Да и кому fkey добавлять? Мужскому полу? Женскому? А если все в одной таблице — кто напишет и будет сопровождать логику проверяющую что у дамы приклонного возраста не появится супруга?
Непонятно? Ок. Давайте псевдокодом:
man_1 = new Man()
man_1.name = "Иван"
woman_1 = new Woman()
woman_1.name = "Таня"
???
А что дальше?
man_1.wife = woman_1 или woman_1.husband = man_1
А как сохранить ЭТО в бд? А никак! В примере заведомо не верный подход к структуре данных!
Свойство name объектов woman_1 и man_1 — является свойством объекта ORM, а вот cвойство wife объекта man_1 и husband объекта woman_1 — это уже отношения объектов ORM! ЭТО РАЗНЫЕ СВОЙСТВА!
Все еще не понятно? Ок. Давайте еще более гуманитарным языком подойдем к вопросу.
Есть Иван и есть Татьяна. Если они забракуются то? Правильно! Они не изменятся! А если оторвать руки (или иной важный орган) Ивану и сбрить волосы Татьяне — они изменятся! Так вот, брак — отношение объетов, а руки и волосы — свойства объектов. Все, я не знаю как еще объяснить.

Тяжкое наследие ООП

Худо-бедно мы пришли к пониманию объекта. Стало вполне понятно кто есть кто. Но как ЭТО сохранить в бд? Некоторые товарищи с умными лицами и длинными бородами пропагандируют утверждение «все есть объект». Давайте попробуем придерживаться того-же, раз уж мы рассматриваем ORM. Допустим для объектов Man и Woman мы используем разные таблицы. Где будем хранить «объект» их отношения? Правильно! В ОТДЕЛЬНОЙ ТАБЛИЦЕ! Назовем ее woman_and_man. В табличке пока будет всего 2 колонки представляющих собой fkey: man_id и woman_id.
«Постойте, любезный, это уже ManyToMany какой-то!» — ага, я все еще читаю ваши мысли! Впринципе, я с вами соглашусь, с одной маааленькой поправкой. Если для таблицы woman_and_man определить правильные constraint — она легким движением руки превращается в OneToOne. Не верите? Пробуем!
Для случая OneToOne нам необходимо соблюсти следующие правила:

1. Одна женщина не может иметь более одного мужа мужского пола
2. Один мужчина не может иметь более одной жены женского пола

Введем соответствующие constraint:

1. значение man_id впределах таблицы woman_and_man должно уникально и не null
2. значение woman_id впределах таблицы woman_and_man должно уникально и не null

Все! У нас OneToOne!
Отправляем ПО на экспорт в ОАЭ — меняем constraint для man_id и получаем ManyToOne/OneToMany! Обратите внимание, структура таблиц не изменится, изменятся только constraint!
Отправляем ПО на экспорт в страну со взаимным многоженством/многомужеством (а есть такие?!) — меняем constraint для woman_id и получаем ManyToMany! Обратите внимание, структура таблиц не изменится, изменятся только constraint!
Проверьте ваши ORM — вы найдете пример использования OneToOne/ManyToOne/OneToMany через доп. таблицу.

Критикам посвящается

После высказывания своих мыслей руководителю я получил вполне ожидаемую реакцию: «Зачем так усложнять? KISS!»
Пришлось «набраться опыта»:

Были случаи с циклическими связями между объектами содержащими среди свойств fkey и задачей «бекапа/сериализации» этого безобразия в xml/json. Нет, бекапы то делаются, вот восстанавливать потом это безобразие чертовски сложно… необходимо жестко отслеживать какие свойства создаются при восстановлении/десериализации, а потом повторно проходить по объектам и восстанавливать связи между ними. Придерживаясь правила выше — надо сначала восстановить объекты, а уж потом связи между ними. Т.к. хранится эта информация в разных таблицах/сущностях — логика была линейной и простой.

На каждый выпад «возьми монгу и не парься» или «документо-ориентированые бд рулят» я всегда приходил к одному и тому же результату который еще никто покрыть не смог:

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

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

P.S. Это далеко не весь «поток сознания» связаный с ORM. Есть еще пара абзацев по null, пара по потимизации запросов и отложеной загрузке объектов, абзац по свойствам отношений (ага, и такое бывает), но актуально ли это? Прошу критиков высказываться в коментариях. Особо острые и интересные вопросы включу в продолжение.

Модели представления данных в CMS — Информационные Технологии | Компьютерные Науки | Интернет | Защита Информации | Связь | Мультимедиа

Существует классификация CMS, построенной на модели представления данных: модульная, объектная и сетевая.

Модульная модель

Модульной модели представления данных является разделение содержимого сайта (контента) на отдельные модули, которые разделяют по типу содержимого. Каждый модуль отвечает только за свою часть контента. Структура данных зависит от модуля, и вся работа с контентом сосредоточена внутри модуля. Расширивать функциональность можно за счет добавления нового модуля, замены или редактирования существующего кода. Несмотря на очевидную ограниченность модели данных, системы на ее основе самые популярныеблагодаря свое простоте.В модульных CMS-системах есть один общий недостаток — строго фиксированная в пределах модуля структура содержимого, но при необходимости для расширения их функциональности можно воспользоваться внешними модулями. Очевидное преимущество этих систем — возможность получения почти полностью готового к использованию портала за короткое время. Схематично модульную модель изображены на рис. 1 .

Рис. 1 . Схематическое изображение

модульной модели

Объектная модель

Для понимания объектной модели представления данных следует оперировать такими понятиями, как класс и объект. Объект и класс является основой этой модели. Классы представляют построение данных и представляют собой набор атрибутов (строка текста, число, изображение и т.д.). Экземпляры класса (объекты) имеют определенную структуру и могут содержать другие объекты, образуя произвольную иерархическую структуру. Объекты класса могут последовать свойства, сущность и функции объектов, которые в них размещаются. Класс контента не хранит реальных данных — такую ​​информацию содержат объекты.Определив один класс, можно создать множество его представителей (контент-объектов). В CMS-системах данные обычно сохраняются с помощью реляционной или объектной базы данных. Обычно системы, основанные на объектно-ориентировочной модели данных, наиболее функциональные и гибкие, но одновременно и самые сложные.

Рис. 2. Схематическое изображение

объектной модели

Сетевая модель

Сетевая модель представления данных в CMS-системах основывается на теории графов: построение информации представляется в виде узлов со связями между ними. Фундаментом системы может служить как сетевая, так и традиционная реляционная СУБД, на которой основывается сетевая модель описания данных. В реляционных таблицах хранится информация об узлах, их атрибуты и связи между ними. Связь отличается от атрибута тем, что в нем хранится ссылка на другой узел, а в атрибуте — собственно значение. Для получения данных из направленного графа обычно используют рекурсивные процедуры обработки, такие как составление списков узлов, определение атрибутов узла по атрибутам родителя и др.

Рис. 3. Сетевая модель представления данных

Предприятии работаем с моделями данных (или «Почему мы не работаем с таблицами?») / Блог компании 1С / Хабр

В этой статье мы хотим рассказать о том, какая модель работы с данными выбрана в платформе 1С:Предприятия и почему.

Для бизнес-приложений работа с данными — это очень важный архитектурный вопрос. Так или иначе, но вся работа приложения строится вокруг данных. Причем, если в некоторых классах программных систем данные носят вспомогательный характер, то в бизнес-приложениях данные являются основным содержанием решаемых задач.

Здесь (в этой статье) мы говорим не о техническом аспекте хранения и манипулирования данными, а об описании данных как способе проектирования приложения. Почему же данные так важны для бизнес-приложений?

Потому, что они описывают саму предметную область. Какие сущности имеются в бизнесе, как они связаны между собой. Данные очень хорошо описывают и саму решаемую задачу. Ведь при проектировании приложений нас не интересуют абсолютно все данные, а интересуют те данные (и их взаимосвязи), которые тем или иным способом влияют на решаемую задачу (включая некоторый запас развития системы в потенциально интересных направлениях). Например, если мы автоматизируем процесс развития персонала, то нас будет интересовать по сотрудникам образование, история работы. Но мы не будем отражать информацию по размерам одежды и обуви. Но, если, например, мы хотим автоматизировать учет спецодежды, то это становится уже интересным. Хотя, пытливый проектировщик может и тут поставить вопрос. Где развитие персонала, там и мотивация. А где мотивация, там и, возможно, изготовление одежды с фирменной символикой. Здесь видно, что количество данных в природе бесконечно, и искусство моделирования данных во многом определяет искусство проектирования приложений.

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

Сделаем только небольшую оговорку. Под данными здесь понимаются и данные, сопровождающие процессы. То есть, получается, что процессы тоже косвенно выражаются через модель данных.

В платформе 1С:Предприятие есть и механизмы для отражения именно процессов, но это тема отдельной статьи.

Существует несколько традиционных парадигм работы с данными.

Прежде всего – есть классическая реляционная модель. В ней данные описываются в виде реляционных таблиц (обычно хранимых в реляционных DBMS). Эта парадигма хотя и совсем не новая, но вполне актуальная.

Есть объектная парадигма. В ней данные описываются в виде объектов языка программирования и каким-то образом сохраняются в базе данных. Это может быть реляционная или объектная база данных. В первом случае возможности моделирования определяются DBMS, во втором случае — используемым ORM.

Есть еще методики и подходы, которые применяются реже (при создании бизнес-приложений). Например, подход, основанный на слабоструктурированных данных.

Теперь, собственно, о том подходе, который мы выбрали для платформы 1С:Предприятия. Для него нет официально принятого названия. Назовем его «модель типов прикладных объектов». Суть подхода в том, что платформа предлагает разработчику некоторый набор типов прикладных объектов. Каждый тип предназначен для отражения в модели приложения некоторой категории сущностей предметной области. Разработчик приложения при отражении предметной области решаемой задачи в модели приложения должен выбрать подходящие типы объектов и с помощью них описать модель данных. На самом деле при этом он описывает не только модель данных, но и, во многом, модель самого приложения. Но об этом чуть позже.

Что представляет собой тип прикладных объектов?

Это некоторый заложенный в платформу шаблон (можно еще считать его абстрактным классом), определяющий множество различных аспектов работы с сущностью предметной области.

Типы прикладных объектов проявляются и при разработке (в design-time) и при работе системы (в run-time). В design-time это мета-модель описания объектов в метаданных и классы для манипулирования данными в программной модели. В run-time это различные аспекты поведения системы при работе с объектами этого типа. Например, поведение механизма блокировок.

В 1С:Предприятии существует несколько типов прикладных объектов.

Для примера возьмем три типа:

• Справочники
• Документы
• Регистры накопления

Справочники предназначены для отражения в системе некоторой условно постоянной информации (списков сотрудников, товаров, клиентов…).

Документы отражают некоторые события предметной области (продажу, прием сотрудника на работу, перечисление денег в банк). Иногда они называются по названиям печатных форм («платежное поручение», «приказ о приеме на работу», …). Но это только для удобства понимания. По сути, это именно тип события, а не печатной формы.

Регистры накопления предназначены для отражения в приложении некоторой системы учета. Например, учета хранения денежных средств или товаров на складах.

Посмотрим, что все-таки входит в «комплект» возможностей, предоставляемый типами прикладных объектов

Прежде всего, конечно, тип прикладного объекта описывает модель данных и обеспечивает отображение данных на реляционную модель хранения. Но это только небольшая часть того, что он определяет.

Например, для справочника:

• существует несколько стандартных реквизитов (полей), заложенных сразу в платформу (ссылка-идентификатор, код, наименование, ссылка на родителя для иерархического справочника, …)
• можно описать свои (произвольные) реквизиты (поля)
• можно описать табличные части, которые представляют собой тесно связанные сущности (containment) или еще их можно считать вложенными таблицами

Для документа — похоже, но есть стандартный реквизит Дата, отражающий положение события относительно других событий на оси времени, а также признак «Проведен», определяющий, отражается документ в системе учета или является черновиком.

Для регистра накопления поля делятся на измерения, ресурсы и реквизиты. Измерения описывают систему координат модели учета (например, товар, склад), ресурсы – показатели (например, количество, сумма), реквизиты – просто дополнительные поля (не влияющие на модель учета, но комментирующие записи движений).

Почему мы оперируем типами прикладных объектов, а не оперируем, например, просто таблицами (или просто сущностями – entity)?

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

Суть выбранного нами подхода в том (если говорить простыми словами), что в нашем подходе сама система (платформа) «много чего знает» про описанные объекты и «много чего умеет с ними делать». На основании этих знаний и умений система автоматически обеспечивает работу более десятка разных механизмов, работающих прямо или косвенно с этими объектами. То есть, получается, что разработчик приложения выбирает тип объекта и описывает конкретный объект, а платформа, зная тип и описание конкретного объекта, сама обеспечивает множество различных полезных функций и механизмов. Это достигается за счет того, что на уровне типа объекта определена семантика объектов данного типа (назначение объекта «по крупному»), а модель метаданных позволяет уточнить семантику конкретного объекта за счет различных свойств и специализированных моделей, описывающих различные аспекты жизнедеятельности.

Перечислим только некоторые из них:

• Прежде всего, конечно, это создание структур данных для хранения и автоматическое преобразование структуры при изменении модели
• Набор классов в объектной модели для манипулирования данными (чтения, записи, поиска)
• Механизм объектно-реляционного преобразования
• Набор типичных процедур обработки данных. Например, для документов это автоматическая нумерация, для регистра это расчет итогов, получение среза остатков на конкретный момент времени, и т.д.
• Отражение в системе прав. Так как система знает о назначении объекта, то знает и какие права для него будут актуальны
• Визуализация (отражение в интерфейсе). Опять же, зная о назначении и роли объектов, система сама конструирует и команды в интерфейсе приложения для доступа к объектам этого типа, и формы для просмотра и редактирования, и команды для различных действий с объектом.
• Обмен данными. На основании знания семантики данных платформа предоставляет стандартный механизм для асинхронного обмена измененными данными как среди родственных приложений (узлов распределенной базы), так и между разнородными приложениями (написанными как на 1С:Предприятии, так и на других технологиях)
• Объектные и транзакционные блокировки. Для правильного построения системы блокировки нужно знание о назначении данных и о взаимосвязях.
• Механизм характеристик (дополнительных полей, определяемых пользователем)
• Автоматически предоставляемый REST интерфейс (по стандарту OData)
• Выгрузку-загрузку данных в XML, JSON
• Кроме того, автоматически работают такие механизмы как: полнотекстовый поиск, журналирование доступа к данным, и т.д.

На схеме изображены далеко не все механизмы платформы, которые работают на основе прикладных объектов, а только некоторые.

В каком-то смысле типы прикладных объектов пересекаются с аспектно-ориентированным подходом. Так как все перечисленные возможности — это некоторые предопределенные аспекты, в которых отражаются типы прикладных объектов. Можно сказать, что типы прикладных объектов это не просто шаблоны, а параметризованные шаблоны. Параметризация осуществляется за счет набора свойств метаданных. Выбрав значение свойства, разработчик параметризует шаблон выбранного типа прикладного объекта и уточняет тем поведение объекта в конкретном аспекте. Например, он может выбрать тип нумерации документа (в пределах года, квартала, месяца…) и система будет автоматически обеспечивать присвоение и контроль номеров с заданной периодичностью.

Типы прикладных объектов обеспечивают знание о семантике не только самих сущностей, но и о семантике их взаимосвязей. Например, существует стандартная связь между документами и регистрами, отражающая то, как в предметной области события отражаются в модели учета. Определив такую связь, разработчик сразу получает готовую функциональность по совместному времени жизни документа и связанных с ним записей регистра.

Отдельно стоит сказать о важных предметно ориентированных аспектах.

Например, для справочников есть возможность одним флажком включить поддержку иерархии. При этом система обеспечит поддержку иерархических справочников во всем: в пользовательском интерфейсе, в отчетах, в объектной модели.

Установка одного свойства справочника «Иерархический справочник» сразу поддерживает иерархию в пользовательском интерфейсе, в отчетах, в объектной модели.

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

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

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

Получается, что разработчик собирает приложение из объектов выбранных типов, как из деталей конструктора. Причем, если бывают конструкторы с «абстрактными» деталями, то в нашем конструкторе детали уже с «назначением» — колеса, окна, двери…
На основе типа «Справочник» разработчик строит справочники продуктов, сотрудников, валют, клиентов; на основе типа «Документ» — документы «Заказ на покупку», «Счет», «Заказ на продажу» и т.д.

Еще стоит сказать про методологическую ценность такого подхода. Все разработчики оперируют некоторым набором понятий, который помогает им лучше понимать суть приложений, упрощает общение. Открыв незнакомый проект 1С:Предприятия разработчик сразу видит знакомые понятия и может быстро разобраться в том какую роль в системе играет тот или иной объект. Например, чтобы понять суть приложения, стоит посмотреть на состав регистров – обычно она отражает основное назначение приложения. Если открыть структуру таблиц или, тем более, структуру классов незнакомого приложения написанного на инструментах, оперирующих таблицами и классами, то понимания будет существенно меньше.

Но, что еще важно, такой подход сближает язык разработчиков и представителей бизнеса (или аналитиков). Про необходимость наличия такого языка хорошо сказано в книге «Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем» Эрика Эванса. Типы прикладных объектов достаточно быстро становятся понятными не-программистам, и это позволяет обсуждать аналитикам, заказчикам и разработчикам основную функциональность проекта на одном языке. Часто можно встретить представителей бизнеса или аналитиков, которые не владеют программированием, но могут поставить задачу в терминах типов прикладных объектов 1С:Предприятия.

Что еще интересно. Этот подход обеспечивает постоянное развитие системы. Мы добавляем в платформу новые механизмы, и они сразу начинают работать для уже существующих объектов (без усилий разработчика приложений или с минимальными усилиями). Например, недавно мы разработали механизм хранения истории данных (версионирования). Так как система знает в общем виде о семантике данных, то разработчику достаточно поставить флажок, что он хочет хранить историю данных конкретного объекта, и платформа обеспечивает все, что нужно, от хранения истории, до визуализации — отображения пользователю истории изменений в виде различных отчетов. Когда ранее мы разработали механизм стандартного REST интерфейса (на основе стандарта OData), то во всех приложения сразу появился готовый REST интерфейс. Разработчикам ничего не пришлось для этого дорабатывать.

Почему мы не делаем еще и «просто таблицы» (в дополнение к готовым типам прикладных объектов)? Это непростой вопрос. Мы сами себе его периодически задаем.

С одной стороны это кажется заманчивым. Так мы бы закрыли все спорные случаи, когда предметная область не идеально ложится в заготовленный нами набор типов прикладных объектов. Можно было сказать разработчикам – «ну вот тебе просто таблица – и делай в ней все, как сам хочешь». Но с другой стороны это приведет к тому, что все наши стандартные механизмы будут пребывать «в растерянности» — как им обходиться с этими таблицами? Ведь они не будут знать семантику этих данных и не смогут понять, как с ними правильно работать. Ну, то есть с ними можно работать «как-то». Строго говоря, у нас есть такой опыт в части внешних источников. Для внешних источников мы описываем у себя именно таблицы (не указывая предметную направленность). И система с ними работает некоторым универсальным образом – при этом не поддерживается часть функциональности.

Пока мы все-таки стараемся удержаться от введения «просто таблиц», чтобы обеспечить чистоту модели и возможность добавлять новую функциональность, опираясь на знание о семантике всех данных. Если каких-то возможностей не будет хватать, то вначале мы все-таки будем рассматривать то, как можно развить состав типов прикладных объектов. Но, конечно, это вопрос дискуссионный, и мы будем продолжать про него думать.

Таким образом, возможности, которые предоставляет в готовом виде платформа 1С:Предприятия, и то повышение уровня абстракции, которое ценится прикладными разработчиками, во многом опираются именно на набор типов прикладных объектов. Это является одним из наиболее существенных отличий 1С:Предприятия от других средств разработки и одним из главных инструментов, обеспечивающих быструю и унифицированную разработку.

Концептуальная модель базы данных: наглядная диаграмма связи

Содержание статьи:

Концептуальная модель базы данных это

Концептуальная модель базы данных это некая наглядная диаграмма, нарисованная в принятых обозначениях и подробно показывающая связь между объектами и их характеристиками. Создается концептуальная модель для дальнейшего проектирования базы данных и перевод ее, например, в реляционную базу данных. На концептуальной модели в визуально удобном виде прописываются связи между объектами данных и их характеристиками.

Принятые определения в концептуальной базе данных

Для единообразия программирования баз данных введены следующие понятия для концептуальных баз данных:

1. Объект или сущность. Это фактическая вещь или объект (для людей) за которой пользователь (заказчик) хочет наблюдать. Например, Иванов Иван Иванович;
2. Атрибут это характеристика объекта, соответствующая его сущности. Например. Задаем себе вопрос: Какую информацию нужно хранить об Иванове Иване Ивановиче? Ответы на этот вопрос и будут атрибуты объекта Иванов Иван Иванович;
3. Третье понятие в проектировании концептуальной базы данных это связь или отношения между объектами.

Лексически более правильно говорить связь между объектами КБД и отношения между сущностями КБД (концептуальная база данных), но встретить можно самые различные сочетания сущности, объекта, связи и отношения (огрехи переводов).

Концептуальная модель базы данных условные обозначения

Концептуальная модель базы данных: принятые графические обозначения

Диаграмма сущность/отношения (объект/связь) называют ER-диаграммой или EDR (entity-relationship diagram). Сама модель сущность-связь была предложена профессором Peter Pin-Shen Chen (Питер Чен) в 1976 году. Правила написания и условные обозначения  ER-диаграммы называют нотацией. Распространены две основные нотации ER-диаграмм:

• Нотация Питера Чена;
• Нотация  Gordon Everest (Гордона Эверста). Под назаванием Crow’s Foot  или Fork (вилка).

Обозначения ER-диаграммы по Питеру Чену

Чен предложил и это приняли следующие условные обозначения для ER-диаграмм:

• Сущность или объект обозначать прямоугольником;
• Отношения обозначать ромбом;
• Атрибуты объектов, обозначаются овалом;
• Если сущность связана с отношением, то их связь обозначается прямой линией со стрелкой. Необязательная связь обозначается пунктирной линией. Мощная связь обозначается двойной линией.

Каждый атрибут может быть связан с одним объектом (сущностью).

Нотация  Gordon Everest

Gordon Everest ввел новое обозначение связей, которые получили название вилка или воронья лапа. Также он ввел, что объект должен обозначаться прямоугольником с названием типа объекта в виде имени существительного внутри прямоугольника. Причем, это имя должно быть уникальным в пределах создаваемой базы данных.

Атрибуты не выделяются в отдельную фигуру, а вписываются в прямоугольник объекта именем существительным с уточняющим словом.

Связь между объектами обозначается прямой линией. Множественные связи обозначаются вилкой на конце. Сама связь подписывается глаголом, типа «Включает» или «Принадлежит».

концептуальная модель базы данных ERD Fork

Дополнения

Атрибуты в ER диаграмме, могут иметь свои собственные атрибуты (композитный) атрибут.

Как нарисовать ER-диаграмму-советы

Простую ER диаграмму нарисовать достаточно просто.  Другое дело насыщенная, объемная ER диаграмма. Ниже приведены некоторые советы, которые помогут вам построить эффективные ER схемы:

• Определите все объекты в данной системе и определите отношения между этими объектами;
• Объект должен появиться только один раз в определенном месте схемы;
• Определите точное и подходящее имя для каждого объекта, атрибута и отношений в диаграмме. Выберите  простые и понятные слова. Условия, которые просты и знакомы всегда побеждает смутные, технические звучащие слова. Для объектов имена существительные, для связей глаголы (можно с пояснениями). Не забываем про уникальность имен объектов;
• Удалите неявные, избыточные или ненужные отношения между объектами;
• Никогда не подключайте отношения к другим отношениям;
• Используйте цвета, чтобы классифицировать однотипные объекты или выделить ключевые области в диаграмме.

©WebOnTo.ru

Другие статьи раздела: СУБД

Поделиться ссылкой:

Похожие статьи

Модель реляционных данных

в СУБД: концепции, ограничения, пример

• Home

• Testing

  • • Back
    • Agile Testing
    • BugZilla
    • Cucumber
    • 9000 Testing Database Testing
    • Назад
    • JUnit
    • LoadRunner
    • Ручное тестирование
    • Мобильное тестирование
    • Mantis
    • Почтальон
    • QTP
    • Назад
    • SAP
    • 00030003 Центр контроля качества
    • SoapUI
    • Управление тестированием
    • TestLink

• SAP

  • • Назад 9000 4
    • ABAP
    • APO
    • Начинающий
    • Basis
    • BODS
    • BI
    • BPC
    • CO
    • Назад
    • CRM
    • Crystal Reports

    H0003 Crystal Reports

    • QM
    • Заработная плата
    • Назад
    • PI / PO
    • PP
    • SD
    • SAPUI5
    • Безопасность
    • Менеджер решений
    • Successfactors
    • SAP Tutorials
  • 000
  • 9000
  • 9000
  • Назад
  • Apache
  • AngularJS
  • ASP.Net
  • C
  • C #
  • C ++
  • CodeIgniter
  • СУБД
  • JavaScript
  • Назад
  • Java
  • JSP
  • Kotlin
  • Linux
  • Linux
  • Kotlin
  • Linux

  js

  • Perl
  • Назад
  • PHP
  • PL / SQL
  • PostgreSQL
  • Python
  • ReactJS
  • Ruby & Rails
  • Scala
  • SQL

  000

  • SQL

  000

  0003 SQL

  000

  0003 SQL

  000

  • UML
  • VB.Net
  • VBScript
  • Веб-службы
  • WPF