ИНФОЛОГИЧЕСКАЯ МОДЕЛЬ ER-МОДЕЛИРОВАНИЕ Назначение информационных систем оперативное

ИНФОЛОГИЧЕСКАЯ МОДЕЛЬ ER-МОДЕЛИРОВАНИЕ

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

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

О проектировании Концептуальное (инфологическое) проектирование — построение семантической модели предметной области. Такая модель создаётся без ориентации на какую-либо конкретную СУБД Термины «семантическая модель» , «концептуальная Семантические отношения - смысловые модель» и «инфологическая модель» являются характеристики информации. синонимами. Концептуальная схема базы данных ПРЕДСТАВЛЯЕТСЯ в виде семантической модели данных Конкретный вид и содержание концептуальной модели базы данных определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграммам.

Концептуальная модель базы описание информационных объектов, или понятий предметной области и связей между ними. описание ограничений целостности, т. е. требований к допустимым значениям данных и к связям между ними. ОФ ОР Т ЛЕЧИТ МЛ ЯЕ

Следующие шаги… У нас – Access, поэтому - реляционная модель данных Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных. Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД. Физическое проектирование — создание схемы базы данных для конкретной СУБД (Access).

Семантическая модель Entity. Relationship (Сущность-Связь) Моделирование предметной области использование графических диаграмм Сущность –реальный или представляемый объект, информация о котором должна сохраняться и быть доступной. Аэропорт Пулково Домодедово

Обзор нотаций Нотация Чена Нотация Мартина Нотация IDEF 1 X Нотация Баркера Подробно см. здесь Мы используем или нотацию Чена или нотацию IDEF 1 X

Нотация Чена

Связи каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА; каждый ПАССАЖИР может иметь один или более БИЛЕТОВ.

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

Экземпляр сущности Конкретный представитель данной сущности. Например, представителем сущности "Сотрудник" может быть "Сотрудник Иванов". Экземпляры сущностей должны быть различимы , т. е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности. Растения

Взаимосвязи между сущностями Отдел <состоит из> нескольких Сотрудников Самолет <перевозит> нескольких Пассажиров. Сотрудник <пишет> разные Отчеты. Связь «Один – ко – многим» Первая сущность - родительская, а вторая дочерняя.

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

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

Зависимые сущности Сотрудник <пишет> разные Отчеты Уникальность такой сущности зависит от значений атрибута внешнего ключа. Дочерняя сущность, уникальность которой зависит от атрибута внешнего ключа, называется зависимой сущностью. Сущность СОТРУДНИК является зависимой сущностью потому, что его идентификация зависит от сущности ОТДЕЛ.

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

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

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

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

Атрибуты сущности Идентифицирующие и описательные атрибуты Составные и простые атрибуты (комбинация нескольких компонентов: Фамилия + Имя + Адрес) Основные и производные атрибуты (значение производного атрибута вычисляется на основе значений других атрибутов: Возраст = Сегодняшняя дата – Дата рождения) Однозначные и многозначные атрибуты

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

Характеристики первичного ключа Первичный ключ - это атрибут (или комбинация атрибутов), который уникально идентифицирует строку. (номера счетов для идентификации кредитных карточек, адреса для идентификации зданий или домов) Уникальные значения: первичный ключ должен уникально идентифицировать каждую строку в таблице. Неинтеллектуальный: первичный ключ не должен иметь смыслового содержания. (Идентификатор клиента 398237 более предпочтителен по сравнению с Майкл Дж. Малоун). Неизменяемость во времени: значение первичного ключа никогда не должно меняться. Одноатрибутность: первичный ключ должен состоять из минимально возможного числа атрибутов. Числовой: легче управлять уникальными значениями, если они являются числовыми.

Связи Связь - это некоторая ассоциация между двумя сущностями. Например, связи между сущностями могут выражаться следующими фразами "СОТРУДНИК может иметь несколько ДЕТЕЙ", "каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ"

Характеристики связей Каждая связь имеет два конца и одно или два наименования. Связь между сущностями характеризуется: типом связи (1: 1, 1: N, N: М) – мощность связи; классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности — обязательный, иначе — необязательный.

Связь ОДИН-К-ОДНОМУ (1: 1) В каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В.

Связь ОДИН-КО-МНОГИМ (1: М) Одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Так как у нас ER-диаграмма Различные типы связей для одной сущности

Связь МНОГИЕ-КО-МНОГИМ (М: М) Каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности

Обязательные и необязательные связи Необязательная связь - связь в которой могут участвовать не все экземпляры сущности. Обязательная (mandatory) связь описывает связь между "независимой" и "зависимой" сущностями. Все экземпляры зависимой ("обязательной") сущности могут существовать только при наличии экземпляров независимой ("необязательной") сущности, т. е. экземпляр "обязательной" сущности может существовать только при условии существования определенного экземпляра "необязательной" сущности.

Чтение связей Каждая связь может быть прочитана как слева направо, так и справа налево. Слева направо: "каждый сотрудник может иметь несколько детей". Справа налево: "Каждый ребенок обязан принадлежать ровно одному сотруднику".

Разделы курсового проекта Введение. Назначение и предметная область. Основные тенденции развития моделируемой организации Проблемы деятельности (кратко) Цели автоматизации, дерево целей, критерии достижения целей (кратко) Границы обследования, границы планируемой автоматизации (зачем автоматизировать, что именно автоматизировать, что это даст)

Разделы курсового проекта Инфологическая модель Организационная структура организации Выявление и описание сущностей и их свойств (атрибутов), определение и описание типов данных для атрибутов обязательно. Выявление всех факторов, действующих в моделируемой системе, и причинно-следственных соотношений (связей) между ними Описание внешних сущностей (кто будет работать с базой и какие данные будут вносится/выбираться) из базы. Построение инфологической модели с использованием ERдиаграмм. Шаг 1: Классификация сущностей Детализация инфологической модели с учетом классификации сущностей. Шаг 2: Выявление первичных и внешних ключей, проверка ограничений целостности

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

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

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

Первый этап ER-диаграммы «Покупатели могут покупать много товаров» «Товары могут продаваться многим покупателям»

Второй этап ER-диаграммы Куда поместить сущности "Накладная" и "Склад" и с чем их связать? Как связаны эти сущности между собой и с сущностями "Покупатель" и "Товар"? Покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара. Каждый покупатель может получить несколько накладных. Каждая накладная обязана выписываться на одного покупателя. Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждый товар, в свою очередь, может быть продан нескольким покупателям через несколько накладных. Кроме того, каждая накладная должна быть выписана с определенного склада, и с любого склада может быть выписано много накладных.

Диаграмма после уточнения

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

Атрибуты сущностей (шаг 2) Наименование покупателя - явная характеристика покупателя. Адрес - явная характеристика покупателя. Банковские реквизиты - явная характеристика покупателя. Наименование товара - явная характеристика товара. (? )Цена товара - похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной? Единица измерения - явная характеристика товара. Номер накладной - явная уникальная характеристика накладной. Дата накладной - явная характеристика накладной. (? )Список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность. (? )Количество товара в накладной - это явная характеристика, но характеристика чего? Это характеристика не просто "товара", а "товара в накладной". (? )Цена товара в накладной - опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же? Сумма накладной - явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную. Наименование склада - явная характеристика склада.

Уточнение 1: Имеется две цены - цена товара в накладной и текущая цена товара. Сущности "Накладная" и "Товар" связаны друг с другом отношением типа много-ко-многим. «Расщепляем» ее на две связи типа один-комногим. Для этого требуется дополнительная сущность. Этой сущностью и будет сущность "Список товаров в накладной".

Сущность "Список товаров в накладной" «Каждая накладная обязана иметь несколько записей из списка товаров в накладной", «каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную", "каждый товар может включаться в несколько записей из списка товаров в накладной", "каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром". Атрибуты "Количество товара в накладной" и "Цена товара в накладной" являются атрибутами сущности " Список товаров в накладной".

Уточнение 2: Аналогично поступим со связью, соединяющей сущности "Склад" и "Товар". Введем дополнительную сущность "Товар на складе". Атрибутом этой сущности будет "Количество товара на складе". Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.

Диаграмма после уточнения

Физический вариант диаграммы

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

Сущности (пример) Базовые сущности: Сотрудники компании Атрибуты контракта Авторы номер, дата подписания Книги участники Контракты Атрибуты книги авторы, название, тираж, дата выхода, цена одного экземпляра, общие затраты на издание, авторский гонорар Атрибуты сотрудников ФИО, табельный номер, пол, дата рождения, паспортные данные, ИНН, должность, оклад, домашний адрес телефоны. Атрибуты авторов ФИО, ИНН (индивидуальный номер налогоплательщика), паспортные данные, домашний адрес, телефоны

ER-диаграмма (Нотация Чена)

Пример 3. Автоматизация процесса продажи билетов на ж. д. вокзале Входные данные: Основному пользователю (продавцу билетов) должна быть предоставлена возможность добавления, удаления, изменения данных, а главное, возможность удобного, расширенного поиска требуемой информации. Часто требуются данные о свободных местах и их типах (купе - плацкарт), а также время прибытия и стоянки поезда на каждой остановке. Некоторым пассажирам может быть предоставлены льготы в связи с их социальным положением или возможность бронирования мест. Иногда требуется информация об обслуживающем персонале. Желательно также предусмотреть возможность автоматизированного подсчета цены билета, в зависимости от выбранных критериев.

Выделим основные сущности. “Поезд”“Вагон” Место”. “Персонал» “Остановки” “справочник льгот” “покупка”.

Нотация Чена

Нотация Баркера

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

Пример выбора информации из базы (Пример продолжение) Лобио по-грузински Ломаную очищенную фасоль, нашинкованный лук посолить, посыпать перцем и припустить в масле с небольшим количеством бульона; добавить кинзу, зелень петрушки, рейган (базилик) и довести до готовности. Затем запечь в духовке. Фасоль стручковая (свежая или консервированная) 200, Лук зеленый 40, Масло сливочное 30, Зелень 10. Выход 210. Калорий 725.

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

Сущности (Пример продолжение) Независимые сущности Блюда, Продукты, Города; Зависимые сущности Состав (связывает Блюда с Продуктами) Поставщики Поставки (связывает Поставщиков с Продуктами) Рецепты Расход

Инфологическая модель

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

Ссылки по теме Учебники http: //citforum. ru/database/case/glava 2_4_3. shtml http: //www. interface. ru/fset. asp? Url=/case/defs 5. htm http: //www. mstu. edu. ru/study/materials/zelenkov/ch_2_4. html http: //www. fnti. kiae. ru/content/data_base. htm Концептуальное моделирование, порождение отношений http: //ftp. csdep. mephi. ru/kiselev/Data%20 Base/Des. Mak/lection 10. htm #_Toc 263574560 Исключающие связи http: //минимулин. рф/shpora-gos-povtas/proektirovanieavtomatizirovannyix-sistem-na-osnove-bd-proektirovanieavtomatizirovannyix-sistem-na-osnove-bd/otobrazhenie-v-erdiagramme-vzaimoisklyuchayushhix-klassov-obektov-i-svyazej. html