Логическая информационная модель

Логическая модель предметной области

Логическая информационная модель

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

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

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

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

Что иллюстрирует логическая модель

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

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

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

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

Пример: Заказ пиццы

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

Основные требования

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

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

3. Для связей должна быть указана кратность (один — многие).

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

Пример: на модель добавлены наименования связей, их размерности и направление чтения.

5. Для сущностей должны быть указаны как минимум основные атрибуты.

Пример: для сущностей указаны основные атрибуты

Основные требования к качеству модели:

1. Модель должна читаться по схеме:

— — .

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

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

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

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

3. Крайне желательно избегать пересечения связей.

4. Расположение объектов модели должно быть таким, чтобы ее удобно было читать.

Есть одно наблюдение — если на модель смотреть приятно, то скорее всего она выполнена качественно.

Рекомендации по разработке

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

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

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

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

Как правило, ответ на этот вопрос вытекает из понимания стоящей перед бизнес-аналитиком задачи.

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

  • Разработка логической модели должна начинаться в момент начала исследования предметной области и заканчиваться тогда, когда завершается выполнение задачи. Это едва ли не единственный артефакт, который разрабатывается на протяжении всего анализа предметной области и определения требований к системе.

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

  • В ходе анализа осуществляется выявление и отображение на модели сущностей и связей.

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

  • По мере проработки модели уточняется состав сущностей и связей, а также определяются атрибуты сущностей.

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

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

Сергей Калинов

Ведущий бизнес-аналитик

EPAM Systems

Источник: http://analyst.by/diagrams/logicheskaya-model-predmetnoy-oblasti

ЭУП

Логическая информационная модель

Цели:
  • ознакомить с этапами проектирования базы данных;
  • ввести понятие информационного объекта;
  • изучить типы связей;
  • изучить методы нормализации отношений;
  • изучить понятие целостности данных.

Можно выделить две фазы жизненного цикла базы данных:

  • проектирование базы данных;
  • эксплуатация базы данных.

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

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

Рис. 1. Этапы проектирования базы данных

  • Анализ предметной области (Системный анализ) и словесное описание информационных объектов предметной области.
  • Информационно-логическое (концептуальное) проектирование – проектирование инфологической модели предметной области в терминах некоторой семантической модели.
  • Логическое проектирование реализации – выбор системы управления базами данных (СУБД) и описание БД в терминах принятой СУБД
  • Физическое проектирование – выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

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

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

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

Цель:

  • Сбор данных (ничего не потерять!);
  • Анализ документов и информационных потоков.

Существует два подхода к выбору состава и структуры предметной области:

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

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

Результат

В результате системного анализа должны быть сформулированы:

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

Информационно-логическое (концептуальное) проектирование. Рассматривается с позиций администратора предприятия.

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

Результат : построение независимой от СУБД информационной структуры путем объединения информационных требований пользователей. Эта структура называется инфологическая (семантическая) модель (ИЛМ).

Логическое проектирование.

Цель:

  • Выбор СУБД;
  • Разработка СУБД-ориентированной схемы данных.

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

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

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

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

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

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

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

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

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

Результатом физического проектирования является полностью готовая к внедрению структура БД.

6.3.2. Информационно-логическое проектирование

При информационно-логическом проектировании используют следующие термины.

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

Информационный объект определенного реквизитного состава и структуры образует класс (тип), которому присваивается уникальное имя (символьное обозначение), например; Студент, Группа, Оценка.

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

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

Пример 1 . На рис. 2 представлен пример структуры и экземпляров информационного объекта СТУДЕНТ.

В информационном объекте СТУДЕНТ ключом является реквизит Номер (№ лич дела), к описательным реквизитам относятся: Фамилия (Фамилия студента), Имя (Имя студента), Отчество (Отчество студента), Дата (Дата рождения), Группа (номер группы, в которой учится студент).

СтруктураНомер Фамилия Имя Отчество Дата Группа
Экземпляры ИнО Студент16493СергеевПетрМихайлович01.01.86111
16593ПетроваАннаВладимировна

Источник: http://eos.ibi.spb.ru/umk/11_15/5/5_R6_T3.html

Логическая информационная модель

Логическая информационная модель

При проектировании программного обеспечения или других инженерных систем выделяют три уровня моделей:

  • концептуальные: отображают предметную область в форме взаимосвязанных объектов без указаний способов их физического хранения; на этом этапе важно выявить номенклатуру участвующих в интересующем разработчиков процессе объектов, процессов и связей; примером такой модели могут служить диаграммы Use Case семейства UML;
  • логические: строятся на основе концептуальной и сосредотачивается на детальном описании объектов, их атрибутов и взаимосвязей; пример — диаграммы классов UML;
  • наконец, физические модели являются материальными воплощениями логических: компьютерными программами, механическими устройствами, экономическими структурами и т.п.

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

Рисунок 1. Пример логической модели. Автор24 — интернет-биржа студенческих работ

Ничего непонятно?

Попробуй обратиться за помощью к преподавателям

Элементы логической модели

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

  1. сущности: описывают объекты предметной области, и субъекты, воздействующие на нее;
  2. атрибуты: свойства объектов и субъектов;
  3. связи: взаимоотношения между сущностями;
  4. свойства связей: правила и ограничения этих взаимоотношений.

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

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

Рисунок 2. Элементы линии для обозначения связей на диаграмме. Автор24 — интернет-биржа студенческих работ

Замечание 1

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

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

Рисунок 3. Обозначение взаимоисключающих связей. Автор24 — интернет-биржа студенческих работ

В примере о заказе пиццы можно предусмотреть сущность «Позиция заказа» с атрибутом «Количество» и соотнести ее с сущностями «Клиент» и «Сорт пиццы».

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

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

Основные требования к логической модели

Существуют критерии, в соответствии с которыми можно оценить полноценность логической модели:

  1. она должна содержать все значимые сущности и связи;
  2. все они должны быть поименованы в терминах предметной области;
  3. связи должны быть отмечены кратностью (например, один — многие);
  4. для каждой связи следует указать направление чтения;
  5. для каждой сущностей должны быть перечислены основные атрибуты.

Модель должна читаться следующим образом:

[Сущность 1] — [Связь] — [Сущность 2]

Возвращаясь к рассмотренному примеру, можно сказать, что сущность «Клиент» связана с сущностью «Заказ» отношением «может оформлять».

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

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

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

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

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

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

Источник: https://spravochnick.ru/informatika/informacionnaya_model/logicheskaya_informacionnaya_model/

ИНФОРМАЦИОННО-ЛОГИЧЕСКАЯ МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ

Логическая информационная модель

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

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

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

Каноническая информационно-логическая модель. Реквизитный состав каждого информационного объекта должен отвечать требованиям нормализации данных.

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

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

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

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

в нем отсутствуют группы, множественные элементы, что обеспечивает простое отображение в реляционную таблицу.

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

Информационный объект – это информационное описание некоторой сущности предметной области, которая определяется рядом качественных и количественных характеристик, которые представлены соответствующими реквизитами-признаками и реквизитами-основаниями.

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

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

Структура информационного объекта. Состав реквизитов информационного объекта определяет его структуру. Каждый информационный объект с определенной структурой образует класс (вид) объекта, которому можно присвоить уникальное имя, например ГРУППА, ПРЕДМЕТ, ПРЕПОДАВАТЕЛЬ, КАФЕДРА, или символические обозначения типа TOV, SKLAD, POST.

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

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

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

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

Документ Название реквизита Имя реквизита Функциональные зависимости
Справочник товаров     Код товара   Наименование   Цена за единицу   Единица измерения   KODT   NAIM   CENA     EI

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

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

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

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

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

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

Требования нормализации. В один информационный объект реквизиты включаются в соответствии с требованиями третьей нормальной формы реляционной модели:

q информационный объект должен содержать уникальный идентификатор-ключ (простой или составной);

q все описательные (неключевые) реквизиты должны быть взаимно независимы;

q все реквизиты, входящие в составной ключ, должны быть также взаимно независимы;

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

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

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

Не нашли то, что искали? Воспользуйтесь поиском:

Источник: https://studopedia.ru/3_84909_informatsionno-logicheskaya-model-predmetnoy-oblasti.html

Информационная модель данных, ее состав (концептуальная, логическая и физическая модели)

Логическая информационная модель

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

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

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

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

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

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

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

Обязательная связь «ЗАМЕЩАЕТ» существует, например, меж­ду двумя объектами СОТРУДНИК и ДОЛЖНОСТЬ в предметной области кадровой информационной системы.

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

В то же время связь «ЗАМЕЩАЕТСЯ» между типами объектов СОТРУДНИК и ДОЛЖНОСТЬ является факультативной, поскольку могут существовать вакантные должности.

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

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

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

Поэтому с каждым моментом времени можно сопоставить некоторое состояние предметной области.

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

Процесс создания информационной модели начинается с опре­деления концептуальных требований будущих пользователей БД.

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

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

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

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

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

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

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

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

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

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

Информационные данные любого пользователя в БД должны быть независимы от всех других пользователей, т. е. не должны ока­зывать влияния на существующие внешние модели. Это первый уровень независимости данных.

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

Это положение отражает второй уровень независи­мости данных.

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

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

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

Иерархическая модельпозволяет строить базы данных с древо­видной структурой. В них каждый узел содержит свой тип данных (сущность).

На верхнем уровне дерева в этой модели имеется один узел — «корень», на следующем уровне располагаются узлы, связан­ные с этим корнем, затем узлы, связанные с узлами предыдущего уровня и т. д.

, причем каждый узел может иметь только одного предка (рис. 1.2).

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

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

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

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

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

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

Кроме того, для таких моделей характерна сложность реализации системы управления базами данных (СУБД). Реляционная модель(от англ. relation — отношение) была разра­ботана в начале 70-х годов Коддом. Простота и гибкость модели привлекли к ней внимание разработчиков.

В 80-х годах она получи­ла широкое распространение, и реляционные СУБД оказались про­мышленным стандартом.

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

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

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

В отличие от столбцов строки не имеют имен, порядок их сле­дования в таблице не определен, а количество логически не ограни­чено.

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

Его значение изменяется при удалении строк из таблицы. Логически среди строк не существует «первой» и «последней».

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

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

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

Отношения ре­ляционной модели связаны между собой. Связи поддерживаются внешними ключами.

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

Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором та же сово­купность столбцов является первичным ключом.

В приведенном примере на рис. 1.4 отношение «СОТРУДНИК» ссылается на отношение «ОТДЕЛ» через название отдела.

Схема реляционной таблицы (отношения)представляет собой со­вокупность имен полей, образующих запись таблицы:

НАЗВАНИЕ ТАБЛИЦЫ (Поле 1, Поле 2, …, Поле п).

Например, для таблиц на рис. 1.4 имеем следующие схемы таблиц:

СОТРУДНИК (№ пропуска, Фамилия, Должность, Название отдела,

Телефон);

ОТДЕЛ {Название отдела, Расположение отдела, Назначение отдела).

Курсивом в схемах таблиц показаны первичные ключи.

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

Доминирование реляционной модели в современных СУБД оп­ределяется:

1) наличием развитой теории (реляционной алгебры);

2) наличием аппарата сведения других моделей данных к реля­ционной модели;

3) наличием специальных средств ускоренного доступа к ин­формации;

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

Типы взаимосвязей в модели: «один к одному», «один ко многим», «многие ко многим»

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

Связь «один к одному» означает, что каждому экземпляру пер­вого объекта (А) соответствует только один экземпляр второго объ­екта (В) и наоборот, каждому экземпляру второго объекта (В) соот­ветствует только один экземпляр первого объекта (А).

Связь «один ко многим» характеризуется тем, что каждому эк­земпляру одного объекта (А) может соответствовать несколько эк­земпляров другого объекта (В), а каждому экземпляру второго объ­екта (В) может соответствовать только один экземпляр первого объ­екта (А).

Связь «многие ко многим» означает, что каждому экземпляру одного объекта (А) могут соответствовать несколько экземпляров второго объекта (В) и наоборот, каждому экземпляру второго объек­та (В) могут соответствовать тоже несколько экземпляров первого объекта (А).

Пример 1.1.Рассмотрим совокупность следующих информаци онных объектов:

СТУДЕНТ (Номер студента, Фамилия И.О., Дата рождения. Номер группы);

СТИПЕНДИЯ (Номер студента. Размер стипендии);

ГРУППА (Номер группы, Специальность);

ПРЕПОДАВАТЕЛЬ (Код преподавателя, Фамилия И.О., Должность).

Информационные объекты СТУДЕНТ и СТИПЕНДИЯ связаны отношением «один к одному», так как каждый студент может иметь только одну стипендию, и каждая стипендия может быть назначена только одному студенту.

Информационные объекты ГРУППА и СТУДЕНТ связаны от­ношением «один ко многим», так как одна группа может включать много студентов, и в то же время каждый студент может обучаться только в одной группе.

Информационные объекты СТУДЕНТ и ПРЕПОДАВАТЕЛЬ связаны отношением «многие ко многим», так как один студент мо­жет обучаться у многих преподавателей, и один преподаватель мо­жет обучать многих студентов.

Источник: https://studopedia.su/10_13293_informatsionnaya-model-dannih-ee-sostav-kontseptualnaya-logicheskaya-i-fizicheskaya-modeli.html

Booksm
Добавить комментарий