16. Концептуальные модели.

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

16. Концептуальные модели.

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

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

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

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

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

  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

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

Источник: https://webonto.ru/kontseptualnaya-model-bazyi-dannyih/

Лекция 3. Этапы проектирования БД. Концептуальная модель

16. Концептуальные модели.

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

Основные задачи:

1. Обеспечение хранения в БД всей необходимой информации.

2. Обеспечение возможности получения данных по всем необходимым запросам.

3. Сокращение избыточности и дублирования данных.

4. Обеспечение целостности данных (правильности их содержания): исключение противоречий в содержании данных, исключение их потери и т.д.

Рисунок 3.1

Концептуальное (инфологическое) проектирование— построение семантической (смысловой) модели предметной области. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных.

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

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

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

· описание информационных объектов, или понятий предметной области и связей между ними;

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

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

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

На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.

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

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

При проектировании реляционных баз данных обычно выполняется так называемая нормализация.

Рисунок 3.2

Модель «сущность–связь»

Средством моделирования предметной области на этапе концептуального проектирования является модель «сущность–связь». Часто ее называют ER-моделью (Entity – сущность, Relation – связь).

В ней моделирование структуры данных предметной области базируется на использовании графических средств – ER-диаграмм (диаграмм «сущность–связь»).

В наглядном виде они представляют связи между сущностями.

Основные понятия ER-диаграммы – сущность, атрибут, связь.

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

Например, сущность КНИГА характеризуется такими атрибутами, как автор, наименование, цена, издательство, тираж, количество страниц. Конкретные книги являются экземплярами сущности КНИГА. Они отличаются значениями указанных атрибутов и однозначно идентифицируются атрибутом «наименование».

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

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

Клиенты имеют в филиалах счета разных типов – текущие, срочные, до востребования, депозитные, карточные. Филиалы обрабатывают эти счета. Описываемую предметную область назовем БАНК.

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

На ER-диаграмме сущность изображается прямоугольником, в котором указывается ее имя. Например,

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

В рассматриваемой предметной области БАНК можно выделить три связи.

1. МЕНЕДЖЕР – УПРАВЛЯЕТ – ФИЛИАЛ

2. ФИЛИАЛ – ОБРАБАТЫВАЕТ – СЧЕТ

3. КЛИЕНТ – ИМЕЕТ – СЧЕТ

На ER-диаграмме связь изображается ромбом. Например,

Важной характеристикой связи является тип связи (кардинальность). Рассмотрим типы связей 1–3.

Так как менеджер управляет только одним филиалом, то каждый экземпляр сущности МЕНЕДЖЕР может быть связан не более чем с одним экземпляром сущности ФИЛИАЛ. В этом случае связь 1имеет тип «один-к-одному» (1:1). На рисунке 3.3 представлена ER-диаграмма для связи типа 1:1.

Рисунок 3.3 – ER-диаграмма связи 1:1

Так как филиал обрабатывает несколько счетов, а счет обрабатывается только одним филиалом, то каждый экземпляр сущности ФИЛИАЛ может быть связан более чем с одним экземпляром сущности СЧЕТ, а каждый экземпляр сущности СЧЕТ может быть связан не более чем с одним экземпляром сущности ФИЛИАЛ. В этом случае связь 2 имеет тип «один-ко-многим» (1:М). На рисунке 3.4 представлена ER-диаграмма для связи типа 1:М.

Рисунок 3.4 – ER-диаграмма связи 1:М

Так как счет может совместно использоваться несколькими клиентами и клиент может иметь несколько счетов, то каждый экземпляр сущности СЧЕТ может быть связан с несколькими экземплярами сущности КЛИЕНТ и каждый экземпляр сущности КЛИЕНТ может быть связан с несколькими экземплярами сущности СЧЕТ. В этом случае связь 3имеет тип «многие-ко-многим» (М:N). На рисунке 3.5 представлена ER-диаграмма для связи типа М:N.

Рисунок 3.5 – ER-диаграмма связи M:N

Рассмотрим понятие класс принадлежности сущности.

Если каждый экземпляр сущности А связан с экземпляром сущности В, то класс принадлежности сущности А является обязательным. Этот факт отмечается на ER-диаграмме черным кружочком, помещенным в прямоугольник, смежный с прямоугольником сущности А.

Если не каждый экземпляр сущности А связан с экземпляром сущности В, то класс принадлежности сущности А является необязательным. Этот факт отмечается на ER-диаграмме черным кружочком, помещенным на линии связи возле прямоугольника сущности А.

В качестве примера на рисунке 3.6 изображены возможные ER-диаграммы для связи М:N c учетом класса принадлежности сущности.

Рисунок 3.6 – ER-диаграммы связи М:N с учетом

класса принадлежности сущности

На ER-диаграмме 1 класс принадлежности обеих сущностей необязательный.

На ER-диаграмме 2 класс принадлежности сущности КЛИЕНТ обязательный, а сущности СЧЕТ необязательный.

На ER-диаграмме 3 класс принадлежности сущности КЛИЕНТ необязательный, а сущности СЧЕТ обязательный.

На ER-диаграмме 4класс принадлежности обеих сущностей обязательный.

Предположим, что в рассматриваемой предметной области БАНК класс принадлежности всех четырех сущностей является обязательным. Тогда ER-модель предметной области БАНКбудет иметь вид, представленный на рисунке 3.7.

Каждая из четырех сущностей приведенной ER-модели может быть описана своим набором атрибутов (рис. 3.8).

ER-модель в совокупности с наборами атрибутов сущностей может служить примером концептуальной модели предметной области или концептуальной схемы базы данных.

В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в автоматизированном проектирования реляционных баз данных.

Рисунок 3.7 – Пример ER–модели предметной области БАНК

МЕНЕДЖЕР ФИЛИАЛ
Номер менеджера (НМ) Номер филиала (НФ)
Стаж работы (СТАЖ) Адрес филиала (АДР_Ф)
Специальность (СПЕЦ)
КЛИЕНТ
СЧЕТ Номер клиента (НК)
Номер счета (НС) Ф.И.О. клиента (ФИО_К)
Тип счета (ТИП) Социальное положение (СОЦ)
Остаток на счете (ОСТ) Адрес клиента (АДР_К)

Рисунок 3.8 – Наборы атрибутов сущностей предметной области Банк

Примечание. Ключевые атрибуты выделены жирным шрифтом.

http://www.site-do.ru/db/db4.php — пример концептуальной модели

http://www.site-do.ru/db/db5.php — преобразование в реляционную (до процесса нормализации)

Источник: https://studopedia.su/1_796_lektsiya--etapi-proektirovaniya-bd-kontseptualnaya-model.html

Что такое концептуальная модель?

16. Концептуальные модели.

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

В этих целях используется различная документация, графики, спецификация, диаграммы и так далее.

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

Значение термина

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

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

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

Основные задачи

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

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

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

Концептуальная модель преследует следующие цели:

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

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

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

Разработка концептуальной модели

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

Источник: https://FB.ru/article/144365/chto-takoe-kontseptualnaya-model

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

16. Концептуальные модели.

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

  • Концептуальный -► концептуальная модель
  • Логический -► логическая модель
  • Физический -► физическая модель

Концептуальный уровень моделирования

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

Базовый элемент концептуальной модели: бизнес-сущность или бизнес-объект.

Примеры бизнес-сущностей:

  • клиент (как вариант, клиент-ФЛ, клиент-ЮЛ),
  • продукт (как вариант, товар, услуга),
  • сделка (как вариант, заказ),
  • контракт.

Концептуальная модель, как правило,  представлена в документах класса ГЛОССАРИЙ (примечание: это может быть как местная wiki, так и разрозненные главы типа «Глоссарий»  в различных документах компании).

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

Наилучшая нотация для концептуального уровня – подборка элементов из слоя Business и Motivation методологии Archimate.

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

Фокус моделирования: 

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

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

  • при создании BI-систем
  • при создании модели данных интеграционной платформы.

В отдельных случаях приходится поддерживать концептуальную модель двух видов:

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

Логический уровень моделирования

Логическая модель является уточнением и детализацией концептуальной модели. Но это лишь с одной стороны.  На построение логической модели также влияет:

  • тип планируемой СУБД, которая будет воплощать модель
  • класс проектируемой системы: операционная (транзакционная) или аналитическая (BI)
  • исторически сложившияся трактовка предметной области вендором системы

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

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

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

Важное замечание.

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

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

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

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

Базовый элемент логической модели: сущность (в ООП — класс).

Для проектирования реляционных баз данных используется нотация ERD. Рамками этой нотации фактически и задаётся логический уровень моделирования.

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

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

Примеры сущностей (классов):

  • клиент  -► party + customer + customer_profile + person
  • продукт  -► продукт + предложение продукта + price plan
  • заказ  -► order, order_item

Фокус моделирования: 

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

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

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

Важное замечание.

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

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

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

Каждый вендор информационной системы имеет логическую модель своей системы даже если он и не раскрывает ее своим клиентам.

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

Например, в системе автоматизации продаж клиент может быть представлен как PARTY, в ERP-системе той же компании как КОНТРАГЕНТ, а системе биллинга той же компании, как АБОНЕНТ.

Физический уровень моделирования

Физический уровень – это уровень таблиц для реляционных моделей данных.

Базовый элемент физической модели: таблица.

Примеры таблиц:

  • клиент   -► table_1
  • продукт  -► table_2 
  • сделка -► table_3

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

Фокус моделирования

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

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

Источник: https://frameworx.ru/SID/datamodelling.html

Лекция 16. Концептуальные модели данных

16. Концептуальные модели.

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

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

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

Типы структур данных

Среди широкого множества определений, обозначающих типы структур данных, наиболее распространена терминология CODASYL (Conference of DAta SYstems Language) — международной ассоциации по языкам систем обработки данных, созданной в 1959 г.

В соответствии с этой терминологией используют пять типовых структур (в порядке усложнения):

1. элемент данных;

2. агрегат данных;

3. запись;

4. набор;

5. база данных.

Дадим краткие определения этих структур.

Элемент данных — наименьшая поименованная единица данных, к которой СУБД может адресоваться непосредственно и с помощью которой выполняется построение всех остальных структур данных.

Агрегат данных — поименованная совокупность элементов данных, которую можно рассматривать как единое целое. Агрегат может быть простым или составным (если он включает в себя другие агрегаты).

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

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

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

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

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

Отметим, что структуры БД строятся на основании следующих основных композиционных правил:

1. БД может содержать любое количество типов записей и типов наборов;

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

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

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

Рассмотренные типы структур данных могут быть представлены в различной форме — графовой; табличной; в виде исходного текста языка описания данных конкретной СУБД.

Операции над данными

Операции, реализуемые СУБД, включают селекцию (поиск) данных и действия над ними.

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

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

1. найти следующее данное (запись);

2. найти предыдущее данное;

3. найти п-еданное;

4. найти первое (последнее) данное.

Этот тип селекции называют селекцией посредством текущей селекции, в качестве которой используется индикатор текущего состояния, автоматически поддерживаемый СУБД и, как правило, указывающий на некоторый экземпляр записи БД.

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

1. ВОЕННО-УЧЕТНАЯ СПЕЦИАЛЬНОСТЬ = 200100;

2. ВОЗРАСТ > 20;

3. ДАТА < 19.04.2002 и т.п.

Булево условие отбора формируется путем объединения простых условий с применением логических операций, например:

Источник: https://studopedia.ru/8_157464_lektsiya--kontseptualnie-modeli-dannih.html

Uchebnik-free
Добавить комментарий