Методика построения информационной модели данных

Содержание

Введение 3
1 Понятие о модели данных 5
2 Информационная модель 6
3 Определение взаимосвязей 9
5 Основные типы моделей и их эквивалентность 15
6 Разработка информационно-логической модели 16
Заключение 18
Список использованных источников 19

Введение

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

Согласно классической теории баз данных, модель данных представляет собой формальную теорию представления и обработки данных при помощи системы управления базами данных (СУБД), в которую включено, три основных аспекта:
1) аспект структуры – это метод описания типа и логической структуры данных, находящихся в базе данных;
2) аспект манипуляции – это метод манипулирования данными в базе данных;
3) аспект целостности – это метод, согласно которому описывается и поддерживается целостность базы данных.[5]
Аспект структуры служит для определения, того что из себя с точки зрения логики представляет база данных. Аспект манипуляции служит для определения способов перехода между различными состояниями базы данных (способы модифицирования данных) и способов которыми, можно извлечь данные из базы данных. Аспект целостности служит для определения средств описаний корректного состояния базы данных.
Модель данных - является абстрактным, самодостаточным, логическим определением объектов, операторов и других элементов, которые в совокупности составляют абстрактную машину при помощи, которой осуществляется доступ пользователя к данным. При этих объектов можно заниматься моделированием структуры данных, а при помощи операторов – моделировать поведение данных.
Основой каждой БД и СУБД является некоторая явная или неявная модель данных. СУБД, которые построены на основе одной и той же модели данных, будут относиться к одному типу. Например, основа реляционной СУБД это реляционная модель данных, основой сетевой СУБД – это сетевая модель данных, основой иерархической СУБД – является иерархическая модель данных и т.д.
Первоначально понятие модели данных считалось синоним такого определения как структура данных в конкретной базе данных.[11]
Долгое время термин «модель данных» не имел формального определения. Одним из первых специалистов, который смог сформулировать достаточно формальное определение этого понятия, является Э. Кодд. В своей статье «Модели данных в управлении базами данных» он описал, что модель данных является комбинацией трёх компонентов:
Коллекция из типов объектов данных, которые образуют собой базовые строительные блоки при помощи, которых строится любая база данных, в соответствии со своей моделью.
Коллекция, состоящая из общих правил целостности, которые ограничивают набор экземпляров только тех типов объектов, которым законным образом можно появиться в любой такой базе данных.
Коллекция операций, которые применяются к экземплярам объектов для проведения выборки и других целей.[7]
2 Информационная модель 
В качестве модели, чтобы представлять экономические объекты, в том числе производственные процессы, более широко стали использовать информационную модель. Информационная модель - является отражением предметной области, представляясь в виде информации. Предметная область является частью реального мира, которую можно исследовать или использовать. Процесс отображения предметной области в информационной технологии происходит при помощи использования следующих моделей:
- концептуальная модель;
- логическая модель;
- математическая модель;
- алгоритмическая модель;
- модель в виде программного кода.[2]
Во время разработки информационной модели нужно обеспечивать принцип системного единства, который служит для обеспечения целостности системы во время взаимосвязей среди отдельных элементов и объектов проектирования, в целом основываясь иерархичностью составляющих промышленное предприятие подсистем.
Используя принцип совместимости можно позволить обеспечение совместного функционирования составных частей, в информационной системе предприятия сохраняя открытость системы в целом.
На рисунке 1  изображено общее содержание понятия модели данных, которое сложилось к настоящему времени.
Рисунок 1 - Общее содержание понятия модели данных
Объектами информационной модели называются сущности реального мира взятие из предметной области. Свойствами объектов (сущностей) называют атрибуты. Сущности вступают во взаимосвязь друг, с другом используя свои атрибуты. Эти три компонента информационной модели представляют собой субъективные средства нужные для описания модели, благодаря которым после проведения определенной формализации данных можно изобразить внешнюю схему данных БД информационной системы.[3]
Во время создания информационной модели надо определить концептуальные требования ряда пользователей. Концептуальные требования могут быть определены и для выполнения некоторых задач (приложений), которые разработчик не планирует реализовывать в ближайшее время.
В концептуальной модели представляются объекты и их взаимосвязь без указания способа их физического хранения. Таким образом, можно понять, что концептуальная модель это, по сути, модель предметной области. Процесс проектирования концептуальной модели основан на анализе, решаемых на конкретном предприятии задач по обрабатыванию данных. В концептуальную модель можно включить описания объектов и их взаимосвязь, если они представляют интерес в рамках рассматриваемой предметной области и могут быть выявлены в ходе анализа данных.[9]
Процесс проектирования концептуальной модели базы данных:
- Проведение анализа данных, а именно сбор основных данных (объекты, взаимосвязь между объектами).
Определение первоначальных данных:
- Заявки, которые поступают на определённый период.
- Договора, которые заключают с поставщиками на определённые виды товара.
- Поставщики, к которым могут относиться организации или физические лица, с которыми можно заключить договор на поставку товара.
- Заказчики, к которым могут в основном относятся магазины, а также предприятия и организации, которые подают заказ на приобретение тех или иных товаров.
- Счета, которые надо вести на этапе заключения договором с поставщиком, а также с заказчиком.
- Накладные, которые создаются во время получения заказа от заказчика, и во время его отгрузки.
- Справки, к которым относится процесс получения/выдачи различных справок, как заказчику, так и поставщику.
- Товар, который должен присутствовать согласно заявке и договору с поставщиком.
3 Определение взаимосвязейВо взаимосвязи происходит процесс отображения или связи между двумя множествами данных. Взаимосвязь бывает типа «один к одному», типа «один ко многим» и типа «многие ко многим».[7]
Например, заказчик заказывает и покупает товар на сайте впервые, то должна быть произведена первичная регистрация с указанием данных и сведений о сделанных заказах. Если заказчиком производится повторный заказ, происходит осуществление регистрации только данного заказа. Не зависимо от того, сколько раз данным заказчиком производились заказы, он будет иметь при себе уникальный идентификационный номер своего заказа (уникальный ключ заказа). В информацию о каждом заказчике входят такие данные как наименование заказчика, его адрес, телефон, номер факса, фамилия, имя, отчество, признак юридического лица и различные примечания. Таким образом, свойством объекта Заказчик будет являться «уникальный ключ заказчика» и «наименование заказчика».
Следующим, представляющим для нас интерес, объектом будет - Товар. Этот объект будет иметь свойство «уникальный ключ товара» и «наименование товара».
Второй рассматриваемый нами объект - Поставщик. Его свойствами будут являться «уникальный ключ поставщика» и «наименование поставщика».
Третий рассматриваемый объект - Заказчик. Его свойствами будут являться «уникальный ключ заказчика» и «наименование заказчика».
Взаимосвязь «один к одному» (между двумя типами объектов).
Представим, что в определенный момент времени одному заказчику можно сделать только один заказ. В таком случае между объектами Заказчик и Товар будет установлена взаимосвязь «один к одному».
Взаимосвязь «один ко многим» (между двумя типами объектов).
Если определенный момент времени одному заказчику можно стать произвести заказ нескольких товаров, при этом несколько заказчиков не могут стать обладателями одного товара (на условии, если заказчик не претендует на часть товара). Взаимосвязь «один ко многим» является наиболее используемой во время разработки реляционной базы данных.
В ходе обращения к записям определенного заказчика нам предоставляется доступ к списку всех его сделанных покупок и сведения, которые записаны и хранятся в объекте Товар.
Взаимосвязь «один к одному» (между двумя свойствами).
Предположим, что ключ (номер) магазина это его уникальным идентификатор, то есть он не должен изменяться при последующем поступлении заказов. Если наравне с номером магазина в базе данных будет храниться и другой уникальный идентификатор (к примеру, адрес), то между этими двумя уникальными идентификаторами будет существовать взаимосвязь «один к одному».
Взаимосвязь «один ко многим» (между двумя свойствами).
Имя поставщика и его номер совместно существуют в базе данных. Поставщиков, у которых могут быть одинаковые имена может быть довольно много, но все они будут иметь разные номера. Каждому поставщику будет присвоен его уникальный номер. Что будет означать, что каждому определенному номеру поставщика будет соответствовать только одно имя.
Свойства, которые включаются в состав БД в рассматриваемой модели, приведены в таблице 1.
Таблица 1 - Свойства и первичные ключи объектов информационной модели.
Объект Первичный ключ Свойства
ТОВАР Уникальный ключ товара Уникальный ключ товара
Наименование товара
ЗАКАЗЧИК Уникальный ключ заказчика Уникальный ключ заказчика
Наименование заказчика
Юридическая принадлежность
Ф.И.О. руководителя
Адрес
Телефон/факс
Наименование товара
Количество товара
Предполагаемая цена
ПОСТАВЩИК Уникальный ключ поставщика Уникальный ключ поставщика
Наименование поставщика
Юридическая принадлежность
Ф.И.О. руководителя
Адрес
Телефон/факс
Наименование товара
Количество товара
Дата изготовления
Акцизная марка
Расшифровка штрих-кода
Срок годности
Вес Брутто
Вес Нетто
Цена за единицу
Суммарная цена
Вид упаковки
Способ доставки
СЧЕТА Номер счёта Номер счёта
Дата продажи
Наименование поставщика
Адрес поставщика
Юридическая принадлежность п.
Наименование заказчика
Адрес заказчика
Юридическая принадлежность з.
Наименование товара
Количество товара
Сумма
НДС
Сумма к оплате
ДОГОВОР Номер договора Номер договора
Дата заключения
Номер счёта
Наименование поставщика
Адрес поставщика
Юридическая принадлежность
Наименование товара
Количество товара
Сумма
НДС
НАКЛАДНЫЕ Номер накладной Номер накладной
Дата накладной
Пометка об оплате
Номер счёта
Наименование заказчика
Адрес заказчика
Юридическая принадлежность
Наименование товара
Количество товара
Сумма
НДС
4 Нормализация информационной модели
Привести модель к уровню нормальной формы является основной задачей во время построения реляционной БД. В ходе процесса нормализации элементов данные группируются в разные таблицы, представляя собой объекты и их взаимосвязь. Основой теории нормализации является то, что определенные наборы таблиц могут обладать лучшими свойствами во время включения, модификации и удаления данных, чем остальные наборы таблиц, при помощи которых представляются те же самые данные.[5]
Процесс нормализации информационной модели проходит в ходе нескольких этапов.
Данные, которые представляются в виде двумерных таблиц, представляют собой первую нормальную форму реляционной модели данных. Первым этапом нормализации является образование двумерной таблицы, в которой содержатся все необходимые свойства для информационной модели с выделением ключевых свойств. В результате, может получиться весьма внушительная таблица, которая будет содержать в себе очень разнородную информацию. В ходе этого случая могут наблюдаться такие аномалии как включение, обновление и удаление данных, так как во время выполнения этих действий нужно уделять внимание данным (вводить и следить за тем, чтобы они не стёрлись), которые не имели никакого отношения к текущим действиям.[11]
Если все возможные ключи отношения содержат по одному свойству, то это отношение задано во второй нормальной форме, так как в этом случае все свойства, не являющиеся первичными, полностью зависят от возможных ключей. Если ключи состоят более чем из одного свойства, отношение, заданное в первой нормальной форме, может не быть отношением во второй нормальной форме. Приведение отношений ко второй нормальной форме заключается в обеспечении полной функциональной зависимости всех свойств от ключа за счет разбиения таблицы на несколько, в которых все имеющиеся свойства будут иметь полную функциональную зависимость от ключа этой таблицы. В процессе приведения модели ко второй нормальной форме в основном исключаются аномалии дублирования данных.
Отношение задано в третьей нормальной форме, если оно задано во второй нормальной форме и каждое свойство этого отношения, не являющийся первичным, не транзитивно зависит от каждого возможного ключа этого отношения.[5]
Транзитивная зависимость выявляет дублирование данных в одном отношении. Если А, В и С - три свойства одного отношения и С зависит от В, а В от А, то говорят, что С транзитивно зависит от А. Преобразование в третью нормальную форму происходит за счет разделения исходного отношения на два.
Таблица 2 - Свойства и первичные ключи измененных или добавленных объектов информационной модели.
Объект Первичный ключ Свойства
ТОВАР Уникальный ключ товара Уникальный ключ товара
Уникальный ключ поставщика
Уникальный ключ заказчика
Наименование товара
Дата изготовления
Акцизная марка
Расшифровка штрих-кода
Срок годности
Вес Брутто
Вес Нетто
Цена за единицу
Суммарная цена
Вид упаковки
ЗАКАЗЧИК Уникальный ключ заказчика Уникальный ключ заказчика
Наименование заказчика
Юридическая принадлежность
Ф.И.О. руководителя
Адрес
Телефон/факс
Предполагаемая цена
ПОСТАВЩИК Уникальный ключ поставщика Уникальный ключ поставщика
Наименование поставщика
Юридическая принадлежность
Ф.И.О. руководителя
Адрес
Телефон/факс
СЧЕТА Номер счёта Номер счёта
Дата продажи
Уникальный ключ товара
НДС
Сумма к оплате
ДОГОВОР Номер договора Номер договора
Дата заключения
Уникальный ключ поставщика
НАКЛАДНЫЕ Номер накладной Номер накладной
Уникальный ключ заказчика
Пометка об оплате
Дата накладной
Табличная с определёнными связями, окончательная концептуальная модель.
ТОВАР Уник. ключ поставщика Уник. ключ заказчика Наименование товара Дата изготовления Акцизная марка Расшиф. Штрих-кода ЗАКАЗЧИК Срок годности ПОСТАВЩИК
Уник. ключ заказчика Вес Брутто Уник. ключ поставщика
Наименов. Заказчика Вес Нетто Наименов. поставщика
Юрид-ская. принад. Цена за единицу Юрид-ская. принад.
Ф.И.О. руководителя Суммарная цена Ф.И.О. руководителя
Адрес Вид упаковки Адрес
Телефон/факс Уник. ключ товара Телефон/факс
Предполагаемая цена Номер договора
Номер накладной Дата заключения
Пометка об оплате Дата накладной СЧЕТА Уник. ключ товара Номер счёта Дата продажи НДС Сумма к оплате Концептуальная модель переносится затем в модель данных, совместимую с выбранной СУБД. Возможно, что отраженные в концептуальной модели взаимосвязи между объектами окажутся впоследствии нереализуемыми средствами выбранной СУБД. Это потребует изменения концептуальной модели. Версия концептуальной модели, которая может быть обеспечена конкретной СУБД, называется логической моделью.
Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среды хранения. Логическая модель данных может быть реляционной, иерархической или сетевой.[12]
С другой стороны, любая информационная модель данных определяется средствами поддержки модели данных, реализуемыми СУБД.
5 Основные типы моделей и их эквивалентностьНаличие в СУБД определенной, допустимой структуры данных приводит к понятию баз структурированных данных, то есть данные в таких БД должны быть представлены как совокупность взаимосвязанных элементов. В настоящее время для баз структурированных данных различают три основных типа логических моделей данных в зависимости от характера поддерживаемых ими связей между элементами данных - сетевую, иерархическую и реляционную.[5]
Рисунок 2  иллюстрирует особенности каждой модели данных. При сопоставлении моделей следует помнить, что все они теоретически эквивалентны.
Рисунок 2 - Основные типы моделей данных
6 Разработка информационно-логической моделиДля этого на первом этапе выделяются информационные объекты и устанавливаются связи между ними. Информационный объект представляет собой описание некоторой сущности предметной области - реального объекта, процесса, явления или события. Информационный объект образуется совокупностью логически взаимосвязанных реквизитов, представляющих качественные и количественные характеристики сущности. Информационные объекты можно выделить на основе описания предметной области путем определения функциональных зависимостей между реквизитами. Для каждого информационного объекта определяются ключевые реквизиты, которые и указываются в информационно-логической модели. Также в модели выделяются одно-многозначные связи между объектами.[9]
В качестве информационных объектов приняты основные структурные элементы производственного процесса - характеристика и состав выпускаемой продукции, использующиеся технологические процессы, оборудование, перечень основных подразделений предприятия, сотрудников с учетом их должностей и другие данные.
Связи между объектами информационно-логической модели характеризуются однозначными, одно-многозначными и много-многозначными отношениями и для их реализации в модель включены как объекты-справочники, так и дополнительные объекты-связки: операции в технологическом процессе, детали в изделии и др.
Заключение

В ходе выполнения данной работы была решена проблема построения информационной модели данных. В данном проекте была проанализирована предметная область и на этой основе были реализованы поставленные задачи.
В заключение хотелось бы сказать, что в деловой или личной сфере часто приходится работать с данными из разных источников, каждый из которых связан с определённым видом деятельности. Для координации всех этих данных необходимы определённые знания и организационные навыки. Существует много веских причин перевода существующей информации на компьютерную основу. Использование клиент-серверных технологий позволяют сберечь значительные средства, а главное и время для получения необходимой информации, а также упрощают доступ и ведение, поскольку они основываются на комплексной обработке данных и централизации их хранения.
В данном проекте были выполнены следующие цели и задачи:
рассмотрена методика построения информационной модели данных;
рассмотрено понятие о модели данных;
охарактеризована информационная модель;
определена взаимосвязь моделей;
охарактеризована нормализация информационной модели;
рассмотрены основные типы моделей и их эквивалентность;
рассмотрена разработка информационно-логической модели.
Цель и задачи решены и достигнуты.
Список использованных источников

Андреев А.Г., Новые технологии Windows 2013 / под ред. А.Н. Чекмарева – СПб.: БХВ – Санкт-Петербург, 2017 г., – 592 С.
Брэгг Р., Безопасность сети на основе Windows Server 2010, СПб.: Питер, 2017 г., - 672 С.
Велихов А.В., Компьютерные сети: Учебное пособие по администрированию локальных и объединенных сетей, М.: Новый издательский дом, 2018 г., - 366 С.
Гук М. Аппаратные средства локальных сетей. Энциклопедия - СПб.:Питер, 2018. - 576 с.
Дейт К. Дж. Введение в системы баз данных, 8-е издание.: Пер. с англ. - М.: Издательский дом "Вильямс", 2015. - 1328 с.: ил.
Закер К., Планирование и поддержка сетевой инфраструктуры Microsoft Windows Server 2003, М.: Русская Редакция, 2017 г., - 544 С.
Информатика. Базовый курс. Учебник для Вузов/под ред. С.В. Симоновича, - СПб.: Питер, 2018
Кульгин М. Технологии корпоративных сетей. Энциклопедия - СПб.:Питер, 2017. - 704 с.
Мельников Д.А. Информационные процессы в компьютерных сетях. Протоколы, стандарты, интерфейсы, модели… - М.: КУДИЦ-ОБРАЗ, 2017. - 256 с.
Олифер В.Г., Олифер Н.А. Компьютерные сети. Принципы, технологии, протоколы. Учебник для вузов. 2-е изд - СПб.: Питер-пресс, 2018 г., – 864 С.
Пушников А.Ю. Введение в системы управления базами данных: Учебное пособие/Изд-е Башкирского ун-та. - Уфа, 2016. - 246 с.
Теория систем и системный анализ в управлении организациями: справочник/ - М.: Финансы и статистика, 2017