Как сделать er диаграмму в access?

31.03.2017

Данная статья является анонсом новой функциональности. Не рекомендуется использовать содержание данной статьи для освоения новой функциональности. Полное описание новой функциональности будет приведено в документации к соответствующей версии. Полный список изменений в новой версии приводится в файле Updates_ru.htm.

Реализовано в версии 1.5.0.1122.

В среде разработки 1C:Enterprise Development Tools (EDT) мы реализовали новый, можно сказать, экспериментальный инструмент. Он, как и дерево объектов конфигурации, предназначен для того, чтобы представить разработчику всё прикладное решение.

Однако для этого он использует другую модель визуализации, в которой структуры данных представляются в виде так называемой ER-диаграммы (Entity Relationship Diagram). Новый инструмент мы назвали схема данных, поскольку ER-диаграмма представляет собой множество прямоугольников, связанных линиями.

Прежде чем рассказать о новом инструменте, нужно сделать небольшое отступление о ER-модели данных вообще. До сих пор эта модель не использовалась 1С:Предприятием, поэтому у вас может возникнуть естественный вопрос, зачем она понадобилась сейчас, и можно ли обойтись без неё.

Зачем в 1С:Предприятии понадобилась ER-модель

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

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

Такая модель удобна для компьютерной обработки, но неудобна для визуального представления разработчику. Особенно неудобна она в случае 1С:Предприятия, где большинство таблиц имеет не абстрактное, а совершенно конкретное прикладное значение.

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

Однако это представление не даёт простого и наглядного понятия о взаимной связи разных объектов между собой.

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

Причём трудоёмкость растёт не только за счёт прямого увеличения времени поиска ссылок среди большого количества объектов. Она растёт и косвенно, за счёт того, что найденные связи необходимо как-то запомнить и визуализировать.

И если таких связей много, встаёт вопрос выбора подходящего внешнего инструмента.

Использование ER-модели (Entity-Relationship Model) как раз решает эту проблему. ER-модель представляет любую структуру данных в виде совокупности сущностей, обладающих атрибутами. Эти сущности взаимодействуют между собой при помощи связей.

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

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

А схема данных это инструмент, позволяющий визуализировать эту модель.

Всё это теоретическое отступление мы написали только ради того, чтобы обратить ваше внимание на две важные вещи.

Во-первых, схема данных это не что-то опциональное, это не «бантик», добавляющий привлекательности среде разработки. Это вполне себе самостоятельный инструмент моделирования предметной области, обладающий своими преимуществами и особенностями.

Во-вторых, схема данных это не аналог и не замена дерева объектов конфигурации. Это ещё один инструмент разработки, но он, можно сказать, имеет свою собственную аудиторию.

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

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

Сценарий 1. Какие объекты конфигурации использует данный объект

Это самый простой сценарий. Например, у вас есть регистр Продажи. Вам нужно узнать, какие объекты конфигурации использует это регистр. То есть, на какие объекты конфигурации ссылаются его реквизиты, измерения и ресурсы.

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

Теперь эта задача решается значительно проще. Вы открываете редактор объекта конфигурации и переходите на закладку Схема данных. Такая закладка есть у всех прикладных объектов конфигурации.

EDT сразу же показывает вам ER-диаграмму. В неё включаются все объекты первого уровня, которые использует регистр Продажи.

На этой схеме данных видно, что регистр Продажи использует документ РасходТовара и справочники Товары и Контрагенты. Эти связи исходят из регистра. Кроме этого на схеме показаны и взаимные связи между самими используемыми объектами (между документом и справочниками).

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

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

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

Закрытой стрелкой обозначается связь с владельцем, а ромбом – с регистратором. Это помогает визуально отличать «техногенные» связи от прикладных.

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

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

Поэтому здесь, в этом месте, не нужно увлекаться наведением «красоты», для этого есть другой сценарий, который мы тоже рассмотрим далее.

Сценарий 2. Разобраться с устройством механизма или подсистемы

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

В этом случае, как и в первом сценарии, вы можете открыть редактор этой подсистемы и перейти на закладку Схема данных. Здесь вы увидите более интересную картину, потому что кроме объектов на этой схеме будут показаны и подчинённые подсистемы.

Подсистемы являются группами объектов. Содержащиеся в них объекты имеют связи с объектами, которые находятся «снаружи». Чтобы посмотреть, как устроена любая из этих подсистем, например подсистема Характеристики, вы можете кликнуть на ней прямо в схеме, и увидите её устройство.

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

Сценарий 3. Документирование

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

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

Для такой задачи вам не нужно использовать закладку Схема данных, которая есть у редакторов объектов конфигурации. Нужно создать отдельный файл схемы данных, который вы сможете затем сохранить в своём проекте. Сделать это можно с помощью меню Файл – Создать – Прочие…

Например, вы разрабатываете механизм работы с пользователями, и для его документирования хотите использовать схему данных. Тогда вы самостоятельно формируете схему, перетаскивая в неё из навигатора 1С:Предприятие нужные вам объекты. Например, справочник Пользователи.

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

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

1. После этого, скорее всего, схема примет не очень красивый вид.

Чтобы сделать её «читабельной» вы можете не перетаскивать объекты мышью, а использовать команду Автоматическое расположение. Она заново расположит объекты в схеме, не меняя их размеров.

• Если вам нужны другие объекты, зависящие от показанных, вы снова можете воспользоваться контекстным меню. Добавьте, например, справочник Склады, на который ссылается реквизит документа Склад:
• В схеме появится справочник Склад.

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

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

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

Для редактирования схемы данных есть довольно широкие возможности. Вы можете двигать линии связей.

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

1. Линии связей можно изгибать, добавляя в них точки изгиба, или наоборот, выпрямлять, удаляя эти точки.
2. Если вы «перемудрили» со связями, или не получается хорошо расставить их вручную, вы можете воспользоваться командой Автоматическое построение связей.
3. Эта команда, не изменяя размеры и положение объектов, построит связи заново.

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

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

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

Источник: https://wonderland.v8.1c.ru/blog/skhema-dannykh/

Методологии построения ER—диаграмм

В настоящее время существуют разнообразные методологий (нотации) построения ER—модели.

1 Методология Питера Чена. В 1976 году Питером Ченом была предложена семантическая модель «сущность—связь» — ER—модель, которая в настоящее время стала самой распространенной.

• Соглашения, используемые при изображении диаграммы:
• — классы объектов отображаются прямоугольником, свойства эллипсами, связи ромбами;
• — уникальный идентификатор (первичный ключ) отображается в виде эллипса, обведенного двойной линией;
• — мощность связи «один» отображается линией, «много» — линией со стрелкой.
• Особенности этой методологии:
• — метод позволяет показать связь между двумя, тремя и более классами объектов (сущностями);
• — связь может иметь собственные атрибуты;
• — нет возможности отображения взаимоисключающих связей и непереносимости связей;
• — взаимоисключающие связи неявно реализуются в виде супертипов и подтипов;
• — нельзя выразить опциональность атрибутов и связей.
• На рисунке 6 приведен пример фрагмента ER—диаграммы в методологии Питера Чена.
• Рисунок 6 — Пример фрагмента ER—диаграммы в методологии Питера Чена
• На диаграмме отображены следующие бизнес—правила предприятия: «каждому заказу, имеющему такие свойства как номер и дата, должна соответствовать одна или более позиций заказа, имеющая такие свойства, как номер, цену за единицу товара, количество товара»; с другой стороны – «каждая позиция товара должна относиться к одному и только одному заказу».

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

2 Методология IDEF1. Используется в CASE—средствах ERwin, Design/IDEF. В методологии используются следующие соглашения:

1. — каждому классу объектов присваивается уникальное имя и номер;
2. — обязательная связь отображается сплошной линией, необязательная – пунктирной;
3. — мощность связи «один» отображается линией, «много» – точкой;

— связь может дополнительно определяться с помощью указания мощности (типа) связи. Мощность может принимать следующие значения: N – ноль, один или более (принимается по умолчанию); Z – ноль или один, P – один или более.

— свойства класса объектов отображаются в виде списка имен внутри блока, отображающего класс объектов;

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

• Пример представления ER—диаграммы в методологии IDEF1 приведен на рисунке 7.
• Рисунок 7 — Пример представления ER—диаграммы в методологии IDEF1.
• На рисунке 7 отображена та же ситуация в предметной области, что и на рисунке 6.

3 Методология Ричарда Баркера. Используемые в методологии элементы: класс объектов, свойство класса объектов, уникальные идентификаторы, опциональность свойств, мощность (тип), опциональность и переносимость связей, уникальность объектов из связей, супертипы, подтипы, арки.

1. Используются следующие соглашения:
2. — класс объектов отображается в виде четырехугольника с закругленными углами. Имя класса объектов указывается внутри четырехугольника, это имя существительное в единственном числе, отображенное заглавными буквами;
3. — свойства записываются внутри четырехугольника, отображающего класс объектов строчными буквами, это имя существительное в единственном числе;
4. — четырехугольник, отображающий класс объектов, можно увеличивать до любых размеров, четырехугольники могут быть разных размеров;
5. — опциональность свойств помечается: обязательное свойство – звездочкой (*), необязательное – кружочком (о);
6. — уникальный идентификатор помечается #, если уникальных идентификаторов несколько, тогда каждый помечается номером, указанным в скобках, например, # (1), #(2);
7. — обязательная связь помечается сплошной линией, необязательная – пунктирной;
8. — тип (мощность) связи «один» помечается линией, «много» — «вороньей лапой».
9. Более сложные элементы, используемые в ER—диаграмме, построенной по методологии Ричарда Баркера, рассмотрим далее в примерах.
10. Шаблоны моделирования

Любая рассматриваемая предметная область имеет свои особенности. Но в тоже время обладает и общими для всех предметных областей элементами.

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

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

Таким образом, многие ситуации можно смоделировать, применяя существующие шаблоны. Рассмотрим шаблоны моделирования на примере построения фрагментов ER − диаграмм по методологии Ричарда Баркера.

1 Моделирование семейного положения.

Ситуацию предметной области, описанную следующими предложениями: «каждое ФИЗИЧЕСКОЕ ЛИЦО (мужского пола) может являться супругом другого ФИЗИЧЕСКОГО ЛИЦА (женского пола)» и, с обратной стороны, «каждое ФИЗИЧЕСКОЕ ЛИЦО (женского пола) может являться супругой другого ФИЗИЧЕСКОГО ЛИЦА (мужского пола)», можно смоделировать, используя рекурсивную связь. Это связь между объектами одного класса объектов. Такая связь может обладать всеми свойствами, присущими любой другой связи. Пример приведен на рисунке 8. На рисунке изображена рекурсивная связь, имеющая с обеих сторон одинаковый тип — «один», и опциональность «необязательная». На представленной ER—диаграмме отображены и названия связей, рассматриваемая методология изображения ER—диаграмм позволяет это сделать.

• Рисунок 8 — Пример рекурсивной связи
• 2 Моделирование иерархии данных. Иерархия данных наблюдается, если в модели предметной области присутствует:
• — произвольное число иерархий классов объектов;
• — одинаковые свойства у классов объектов, входящих в иерархию;
• — связи между такими классами объектов одинаковые.
• На рисунке 9 представлен фрагмент ER—диаграммы, выполненный по методологии Ричарда Баркера и отображающий пример иерархии данных.
• Рисунок 9 — Пример иерархии данных

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

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

Однако, такое представление имеет некоторый недостаток – при добавлении ещё одного уровня иерархии, например, добавления структурной единицы «Лаборатория» в подчинение какой—либо кафедре потребует добавления ещё одного класса объектов в модель, то есть любое изменение в организационной структуре предприятия потребует корректировки модели.

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

1. Замена иерархии данных рекурсивной связью осуществляется по следующему алгоритму:
2. — создается один класс объектов, содержащий свойства, присущие каждому классу объектов в иерархии данных;
3. — классу объектов присваивается общее имя (в иерархии подчинения подразделений предприятия это может быть, например, класс объектов с именем «СТРУКТУРНАЯ ЕДИНИЦА ПРЕДПРИЯТИЯ»);
4. — создается дополнительный класс объектов, который будет отображать название для отличия каждого узла иерархии данных, например, класс объектов «ТИП СТРУКТУРНОЙ ЕДИНИЦЫ ПРЕДПРИЯТИЯ».
5. Как вывод, необходимо сделать следующие замечания:
6. — шаблон имеет один недостаток: классы объектов, находящиеся на всех уровнях иерархии должны иметь одинаковые свойства;
7. — иерархия, смоделированная как рекурсивная связь, должна быть необязательной в обоих направлениях. Обязательная ветвь, направленная вверх или вниз, создает бесконечную иерархию, не имеющую применения в реальном мире;
8. — если при преобразовании модели предметной области происходит слияние частей диаграммы в одну, то необходимо найти в предметной области класс объектов «ТИП», который позволит отобразить уникальность каждой части
9. Пример использования шаблона, моделирующего иерархию данных, приведен на рисунке 10.
11. Рисунок 10 – Пример использования шаблона для моделирования иерархии данных.

3 Разрыв связей M:M. Наличие связи M:M в ER — диаграмме допустимо, но необходимо помнить, что это признак не адекватного отображения предметной области, она не дообследована. Надо пытаться найти класс объектов (сущность), который разорвет такую связь. Как правило, это какой—то документ, или позиция документа.

Например, связь «многие ко многим» между классами объектов «ПОСТАВЩИК» и «ТОВАР» («каждый ПОСТАВЩИК может поставлять много ТОВАРОВ» и «каждый ТОВАР может поставляться разными ПОСТАВЩИКАМИ») может быть разорвана с помощью таких классов объектов, как «ПОЗИЦИЯ НАКЛАДНОЙ», «ПОЗИЦИЯ ПРАЙС — ЛИСТА», «ПОЗИЦИЯ ДОГОВОРА» и другие. На рисунке 11 приведен пример разрыва связи М:М.

В роли поставщика в примере выступает юридическое лицо.

Рисунок 11 — Разрыв связи М:М

Необходимо отметить, что классы объектов, разрывающие связь М:М, как правило, содержат свойства, значения которых динамически меняется. Это такие свойства, как «количество», «цена».

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

Например, класс объектов «ВРАЧ» и класс объектов «ПАЦИЕНТ» созданы для отображения разных ролей человека – один лечит, другой лечится. В случае если врач становится пациентом, то информация о нем должна быть также отображена и в классе объектов «ПАЦИЕНТ». Возникает ситуация информационного дублирования.

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

• Пример неправильного моделирования ролей приведен на рисунке 12, правильного – на рисунке 13.
• Рисунок 12 — Неправильное моделирование ролей
• Рисунок 13 — Правильное моделирование ролей

На рисунке 12 классы объектов «ПОСТАВЩИК» и «ПОТРЕБИТЕЛЬ» выделены отдельно.

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

Правильным моделированием ситуации будет выделение одного класса объектов «ЮРИДИЧЕСКОЕ ЛИЦО», а роли «поставщик» и «потребитель» отобразить в виде соответствующих связей (рисунок 13).

Примеры предметных областей, где необходимо моделировать роли, приведены в таблице 9.

Таблица 9 — Примеры моделирования ролей.

Предметная область	Неправильное моделирование	Правильное моделирование
Купля—продажа, поставка товара	Классы объектов: ПОКУПАТЕЛЬ, ПРОДАВЕЦ, ПОСТАВЩИК	Классы объектов: ЮРИДИЧЕСКОЕ ЛИЦО или ФИЗИЧЕСКОЕ ЛИЦО. Связи (роли): покупает, продает, поставляет
Образовательное учреждение, обучение	Классы объектов: АБИТУРИЕНТ, СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, АСПИРАНТ	Классы объектов: ФИЗИЧЕСКОЕ ЛИЦО, РАБОТА ФИЗИЧЕСКОГО ЛИЦА, ОБУЧЕНИЕ ФИЗИЧЕСКОГО ЛИЦА, ТИП ОБУЧЕНИЯ ФИЗИЧЕСКОГО ЛИЦА, ТИП ПЕРЕМЕЩЕНИЯ ФИЗИЧЕСКОГО ЛИЦА. Связи (роли): сдает документы, работает, обучается.
Документооборот	Классы объектов: ВХОДЯЩИЙ ДОКУМЕНТ, ИСХОДЯЩИЙ ДОКУМЕНТ, ПРИКАЗ, РАСПОРЯЖЕНИЕ	Классы объектов: ДОКУМЕНТ, ПОЗИЦИЯ ДОКУМЕНТА, ТИП ДОКУМЕНТА, ТИП ПЕРЕМЕЩЕНИЯ ДОКУМЕНТА. Связи (роли): относится (к типу)

На рисунке 14 приведен фрагмент ER—диаграммы, отображающей предметную область «Управление персоналом».

Класс объектов «ПОЗИЦИЯ ПРИКАЗА О ПЕРЕМЕЩЕНИИ» отображает сведения о перемещениях сотрудников (физических лиц) на предприятии, класс объектов «ВИД ПЕРЕМЕЩЕНИЯ» — виды кадровых перемещений – прием, перевод, увольнение и тому подобное.

Между классами объектов «ПРИКАЗ О ПЕРЕМЕЩЕНИИ» и «ПОЗИЦИЯ ПРИКАЗА О ПЕРЕМЕЩЕНИИ» присутствуют три связи, две из них – моделируют роли:

1. — «каждый ПРИКАЗ О ПЕРЕМЕЩЕНИИ должен быть подписан одним сотрудником, являющимся начальником отдела кадров, о чем есть соответствующая информация в классе объектов ПОЗИЦИЯ ПРИКАЗА О ПЕРЕМЕЩЕНИИ», начальник отдела кадров может подписывать много приказов»;
3. Рисунок 14 — Пример моделирования ролей
4. — «каждый ПРИКАЗ О ПЕРЕМЕЩЕНИИ должен быть подписан одним сотрудником, являющимся руководителем предприятия, о чем есть соответствующая информация в классе объектов «ПОЗИЦИЯ ПРИКАЗА О ПЕРЕМЕЩЕНИИ», руководитель предприятия может подписывать много приказов».

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

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

Источник: https://cyberpedia.su/14x5d46.html

Создание ER-Диаграмм

• Краткая теория вопроса
• Информационная система (ИС) — программно-аппаратный комплекс, предназначенный для хранения и обработки информации о какой-либо предметной области.
• Процесс создания ИС делится на ряд этапов. Обычно выделяют следующие этапы создания ИС:

• — формирование требований к системе (анализ),
• — проектирование,
• — реализация,
• — тестирование,
• — ввод в действие,
• — эксплуатация и сопровождение.

Важнейшим компонентом любой информационной системыявляется База данных (БД). База данных (Data Base) – структурированный, организованный набор данных, объединенный в соответствии с некоторой выбранной моделью и описывающий характеристики какой-либо физической или виртуальной системы.

Именно БД позволяет эксплуатировать ИС, выполнять ее текущее обслуживание, модифицировать и развивать её при модернизации предприятия (организации) или  изменении информационных потоков, законодательства и форм отчетности предприятия (организации).

Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются модели: организации, требований к ИС, проекта ИС, требований к приложениям и т. д.

Проектирование ИС охватывает три основные области:

• —проектирование объектов данных (создание моделей данных), которые будут реализованы в базе данных;
• —проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
• —учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т. п.

Модель – искусственный объект,представляющий собой отображение (образ) системы и её компонентов.

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

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

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

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

В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER — Entity-Relationship) — ERD.

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

Базовые понятия ERD

Сущность (таблица, отношение) — это представление набора реальных или абстрактных объектов (людей, вещей, мест, событий, идей, комбинаций и т. д.

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

Каждая сущность в модели изображается в виде прямоугольника с наименованием.

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

Экземпляр сущности (запись, кортеж)- это конкретный представитель данной сущности.

Атрибут сущности (поле, домен) — это именованная характеристика, являющаяся некоторым свойством сущности.

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

Каждая связь может иметь один из следующих типов связи:

Один-к-одному, многое-ко-многим, один-ко-многим.

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

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

При разработке ER-моделей необходимо обследовать предметную область (организацию, предприятие) и выявить:

1) Сущности, о которых хранятся данные в организации (предприятии), например, люди, места, идеи, события и т.д., (будут представлены в виде блоков);

1. 2) Связи между этими сущностями (будут представлены в виде линий, соединяющих эти блоки);
2. 3) Свойства этих сущностей (будут представлены в виде имен атрибутов в этих блоках).
3.   Задача: разработать информационную систему «Контингент студентов института».
4. Необходимо: изучить предметную область (образовательное учреждение) и процессы, происходящие в ней.

Для этого обследуем объект: знакомимся с нормативной документацией, опрашиваем работников института, изучаем существующий документооборот института, анализируем ситуацию  и т.п.

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

Краткая постановка задачи: главная задача системы – сбор и обработка информации об основных участниках учебного процесса: студентах и преподавателях, формирование необходимых печатных форм (документов), используемых преподавателями в период зачётной недели и экзаменационной сессии, генерация сводных отчётов по результатам сессии для работников деканатов, института. При разработке системы следует учитывать, что она основывается на документации, поступающей из приёмной комиссии, деканатов и других подразделений института. Информация об успеваемости студентов должна накапливаться и храниться в течение всего периода обучения. В системе должен использоваться справочник специальностей и дисциплин (предметов), изучаемых студентами.

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

1. — Хранить информацию о студентах и их успеваемости.
2. — На факультетах по определённой специальности печатать экзаменационные ведомости и другие документы.

Выделим все существительные в этих предложениях — это предполагаемые сущности и проанализируем их:

• —  Студент — явная сущность.
• —  Успеваемость — явная сущность.
• —  ? Факультет — нужно выяснить один или несколько факультетов в институте? Если несколько, то это — предполагаемая  новая сущность.
• — ? Специальность — нужно выяснить одна или несколько специальностей на факультете? Если несколько, то  это — ещё одна сущность.
• — Предмет — предполагаемая  сущность.

На первоначальном этапе моделирования данных информационной системы явно выделены две основные сущности: Студент и Успеваемость.

Критерием успеваемости является наличие отметки о сдачи экзаменов.

Сразу возникает очевидная связь между сущностями — «студент сдаёт несколько экзаменов » и «экзамены сдаются каждым студентом». Явная связь Один-ко-многим. Первый вариант диаграммы выглядит так:

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

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

 Разработанный выше пример ER-диаграммы является примером концептуальной диаграммы, не учитывающей особенности конкретной СУБД. На основе данной концептуальной диаграммы можно построить физическую диаграмму, которая будут учитывать такие особенности СУБД, как допустимые типы,  наименования полей и таблиц, ограничения целостности и т.п.

1. Для преобразования  концептуальной модели в физическую необходимо знать, что:
2. —   Каждая сущность в ER-диаграмме представляет собой таблицу базы данных.
3. —  Каждый атрибут становится колонкой (полем) соответствующей таблицы.
4. —   В некоторых таблицах необходимо вставить новые атрибуты (поля), которых не было в концептуальной модели — это ключевые атрибуты родительских таблиц, перемещённыхв дочерние таблицы для того, чтобы обеспечить связь между таблицами посредством внешних ключей.
5. Выводы:
6. —Семантическое моделирование данных основывается на технологии определения значения данных через их взаимосвязи с другими данными.

—  В качестве инструмента семантического моделирования используются различные варианты (нотации) диаграмм сущность-связь — (Entity-Relationship). Нотация — система условных обозначений, принятая в какой-либо области знаний или деятельности.

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

После создания концептуальной модели данных переходим к созданию физической модели средствами конкретной СУБД, а именно СУБД ACCESS. Для этого переходим к выполнению Практического задания №2

Приглашайте друзей на мой сайт

С карты, с баланса сотового, из Кошелька

Источник: http://inf-teh-lotos.ru/sozdanie-er-diagramm

Методика построения еr — диаграммы для базы данных

В данной работе рассмотрено создание ER – диаграммы на примере детского магазина.

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

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

Комплекс задач этого этапа состоит в выявлении общих информационных объектов и связей между ними. Результаты инфологического проектирования могут быть выражены в виде инфологической или концептуальной модели, которая представляет структуру данных. Для построения концептуальной модели используется метод моделирования «Сущность — связь» или ER-диаграмма.

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

Работа продавца-консультанта — это процесс, который можно разделить на следующие этапы:

• поиск нужного товара;
• формирование списка товаров;
• добавление информации о покупателях;

Информационные процессы этапов представлены в виде таблицы (Таблица 1. ).

Таблица 1. Информационные процессы этапов

Этап	Информационные процессы
1. поиск нужного товара	— поиск товара на складе посредством побуквенного ввода названия товара, фирмы изготовителя или цене в поле поиска;
2. формирование списка товаров	— вывод выбранных товаров в отдельную таблицу;
3. оформление документов клиента	— сохранение информации в базу данных;
4. оформление продажи	— выбор количества продаваемого товара;

После изучения предметной области и анализа структуры системы были определены объекты. Список сущностей и связей представлены в таблицах 2 и 3.

Таблица 2. Перечень сущностей предметной области

Название	Ключ сущности	Атрибуты сущности
Детский магазин	Код_магазина	Название Адрес Телефон Почта ФамилияИО_владельца Адреса_магазинов Город Страна
Сотрудники	Код_сотрудника	Должность ФамилияИО_сотрудника Паспортные данные Дата_рождения Пол Образование Телефон Дата_устройства Город Почта Код_магазина
Поставщики	Код_поставщика	Адрес Телефон Страна Почта Категория_товара Фирма_товара Дата_поставки Количество
Покупатели	Код_покупателя	ФамилияИО_покупателя Паспортные_данные Город Телефон Адрес Почта Постоянный_клиент
Заказы	Код_заказа	ФамилияИО_заказчика Название_товара Количество Дата заказа Стоимость_заказа Код_доставки
Товары	Код_товара	Артикул Категория Название Размер Материал В_наличии(шт) Заказано/ожидается Изображение Цена(шт) Количество Код_поставщика Код_типа Код_магазина

Таблица 3. Перечень связей между сущностями

№	Связь
1	Поставщики ПОСТАВЛЮТ Товары
2	Товары СОСТОЯТ Типы
3	Товары НАХОДЯТСЯ Магазин
4	Магазин РАБОТАЮТ Сотрудники
5	Сотрудники ОФОРМЛЯЮТ Заказы
6	Заказы ДЕЛАЮТ Клиенты

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

Рисунок 1. ER-диаграмма.

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

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

Для каждого столбца вы указываете формат и размер данных. Строки (записи) таблицы соответствуют экземплярам объекта и генерируются при загрузке таблицы.

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

В Access можно создать схему данных, визуально представляющую логическую структуру базы данных. Определение отношений «один ко многим» в этой схеме должно соответствовать построенной модели данных. Появление схемы данных практически совпадает с графическим представлением информационно-логической модели. В таблицах 4 и 5 показаны структуры объектов «Товары» и «Сотрудники».

Аналогично можно получить и другие таблицы базы данных.

Таблица 4. Структура таблицы «Товары»

Ключевое поле	Название поля	Тип поля
Ключ	Код_товара	Счетчик
Артикул	Текстовый
Категория	Текстовый
Название	Текстовый
Размер	Числовой
Материал	Текстовый
В наличии(шт)	Текстовый
Заказано/Ожидается	Текстовый
Изображение	Поле объекта OLE
Цена(шт)	Денежный
Количество	Числовой
Код поставщика	Числовой
Код типа	Числовой
Код магазина	Числовой

Таблица 5. Структура таблицы «Сотрудники»

Ключевое поле	Название поля	Тип поля
Ключ	Код_сотрудника	Счетчик
Должность	Текстовый
ФИО сотрудника	Текстовый
Паспортные данные	Числовой
Дата рождения	Дата/время
Пол	Текстовый
Образование	Текстовый
Телефон	Числовой
Фотография	Поле объекта OLE
Дата устройства	Дата/время
Город	Текстовый
Почта	Текстовый
Код магазина	Числовой

Используя правила перевода ER — диаграмму на логическую схему можно завершающую схему — логическую схему данных (рис. 2)

Рисунок 2. Логическая схема базы данных.

Таким образом, в данной работе подробно рассмотрено получение ER — диаграммы и логической схемы на примеры детского магазина.

Источник: https://novainfo.ru/article/14504

Рисунки и диаграммы Access

При помощи второго способа размещают рисунки, которые связаны с конкретными записями, например, база данных содержит информацию по сотрудникам и этот элемент позволяет выводить фотографию конкретного сотрудника при изменении записей. Задание 1. Поместите окно ввода в форме “Заказ с полем со списком” на выпуклый прямоугольник. Для этого выберите инструмент Прямоугольник и разместите его на необходимую область формы. При этом прямоугольник может перекрыть элементы формы. Далее сделайте прямоугольник прозрачным, выбрав Свойства — Тип фона — Прозрачный или выбрать пункт На задний план в пункте меню Формат. Затем выберите Свойство Оформление / Приподнятое. Отмечу также, что прямоугольник залить цветом, используя Свойство / Цвет фона. 2. Добавьте логотип на одну из форм. Логотип создайте самостоятельно, например, в графическом редакторе Paint. Мастер диаграмм Удобным механизмом анализа и представления данных являются диаграммы. Распишу процесс построения диаграммы распределения по категориям цены товаров для таблицы ТОВАР. 1. Создаем запрос “Категории и цены товаров” по таблицам ТОВАР и КАТЕГОРИЯ ТОВАРА, содержащий поля Значение и Цена, отсортированные по полю Значение. 2. Используя созданный запрос, создаем форму “Диаграмма: Количество товаров по категориям”. Для этого на Ленте Создание в разделе Формы выберем Пустая форма и откроем ее в конструкторе, затем в Элементах управления найдем пиктограмму Вставить диаграмму нажмем на нее и выберем место на форме куда хотим ее вставить и автоматически откроется окно Создание диаграммы, выберем таблицу и запрос. В нашем случае это будет запрос Категории и цены товаров. Выберем поле Значение. В качестве формы диаграммы выберем Объемная круговая. Теперь введем заголовок диаграммы: Число товаров каждой категории и кнопкой Готово запустим построение диаграммы. Получим требуемую диаграмму. 3. На полученной диаграмме есть названия категорий, но нет численных значений. Вызовем программу Microsoft Graph, которая собственно и создала нашу диаграмму. Для этого необходимо перейти в режим Конструктора и вызвать программу двойным щелчком по светлому полю на диаграмме. В верхней строке меню теперь представлены пункты меню приложения Microsoft Graph. Выберем пункты Диаграмма / Параметры диаграммы… / Подписи данных / Значение. Нажмем кнопку ОК. Теперь цифры числа записей данной категории появятся. При необходимости их можно переместить в нужные места. Если хотим, можем вывести проценты. Задание 1. Создайте диаграмму Количество товаров по категориям (создание описано выше). 2. Для того же запроса “Категории и цены товаров” создайте столбчатую диаграмму значений средней цены товаров по категориям. В качестве полей диаграммы возьмем оба поля запроса. Выберем тип диаграммы Гистограмма. Далее в процессе диалога с мастером дважды щелкнем левой кнопкой мыши по кнопке Сумма_Цена. Откроется окно выбора функции, выберем Avg. Название кнопки теперь поменяется на Среднее_Цена Дадим диаграмме название Средняя цена товаров по категориям. 3. Создать для этого же запроса вертикальную столбцовую диаграмму (Гистограмму) “Число товаров”, показывающую количество товаров по категориям. 4. Замените на предыдущей круговой диаграмме вывод чисел на вывод процентов. 5. Создайте круговую диаграмму “Категория покупателей – количество товаров”, показывающую количество товаров, приобретенных каждым покупателем. диаграмма» width=»293″>В данной лабораторной работе рассмотрим использование рисунков и диаграмм в СУБД Access.

Рисунки

В режиме конструктора форм СУБД Access имеется возможность использования графических элементов Линия и Прямоугольник. Данные элементы позволяют акцентировать внимание на определенных частях формы.

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

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

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

Задание

1. Поместите окно ввода в форме “Заказ с полем со списком”  на выпуклый прямоугольник. Для этого выберите инструмент Прямоугольник и разместите его на необходимую область формы. При этом прямоугольник может перекрыть элементы формы. Далее сделайте прямоугольник прозрачным, выбрав Свойства — Тип фона — Прозрачный или выбрать пункт На задний план в пункте меню Формат. Затем выберите Свойство Оформление / Приподнятое. Отмечу также, что прямоугольник залить цветом, используя Свойство / Цвет фона.
2. Добавьте логотип на одну из форм. Логотип создайте самостоятельно, например, в графическом редакторе Paint.

Мастер диаграмм

Удобным механизмом анализа и представления данных являются диаграммы. Распишу процесс построения диаграммы распределения по категориям цены товаров для таблицы ТОВАР.

1. Создаем запрос “Категории и цены товаров” по таблицам ТОВАР и КАТЕГОРИЯ ТОВАРА, содержащий поля Значение и Цена, отсортированные по полю Значение.
2. Используя созданный запрос,  создаем форму “Диаграмма: Количество товаров по категориям”. Для этого на Ленте Создание в разделе Формы выберем Пустая форма и откроем ее в конструкторе, затем в Элементах управления найдем пиктограмму Вставить диаграмму нажмем на нее  и выберем место на форме куда хотим ее вставить и автоматически откроется окно Создание диаграммы, выберем таблицу и запрос. В нашем случае это будет запрос Категории и цены товаров. Выберем поле Значение. В качестве формы диаграммы выберем Объемная круговая. Теперь введем заголовок диаграммы: Число товаров каждой категории и кнопкой Готово запустим  построение диаграммы. Получим требуемую диаграмму.
3. На полученной диаграмме есть названия категорий, но нет численных значений. Вызовем  программу Microsoft Graph, которая собственно и создала нашу диаграмму. Для этого необходимо перейти в режим Конструктора и вызвать программу двойным щелчком по светлому полю на диаграмме. В верхней строке меню теперь представлены пункты меню приложения Microsoft Graph. Выберем пункты Диаграмма / Параметры диаграммы… /  Подписи данных / Значение. Нажмем кнопку ОК. Теперь цифры числа записей данной категории появятся. При необходимости их можно переместить в нужные места. Если хотим, можем вывести проценты.

Задание

1. Создайте диаграмму Количество товаров по категориям (создание описано выше).
2. Для того же запроса “Категории и цены товаров” создайте столбчатую диаграмму значений средней цены товаров по категориям. В качестве полей диаграммы возьмем оба поля запроса. Выберем тип диаграммы Гистограмма. Далее в процессе диалога с мастером дважды щелкнем левой кнопкой мыши по кнопке Сумма_Цена. Откроется окно выбора функции, выберем Avg. Название кнопки теперь поменяется на Среднее_Цена Дадим диаграмме название Средняя цена товаров по категориям.
3. Создать для этого же запроса вертикальную столбцовую диаграмму (Гистограмму) “Число товаров”, показывающую количество товаров по категориям.
4. Замените  на предыдущей круговой диаграмме вывод чисел на вывод процентов.
5. Создайте круговую диаграмму  “Категория покупателей – количество товаров”, показывающую количество товаров, приобретенных каждым покупателем.

Лабораторная работа Access

Источник: http://aermolenko.ru/2012/03/risunki-i-diagrammy-access/