Инфологическое моделирование. Модель ER сущность-связь

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

Использование разного рода БД стало реальностьюблагодаря современным ПК, а также устройствам для долгосрочного сбережения данных, которые способны обрабатывать большие объемы ПО, а также позволяет использовать только самую нужную информацию, которая может хранится в долгосрочнойпамяти,ее преобразовывая в нужные для проектирования БД формы.Впервые понятие «базаданных» начало использоваться в далеком1960 году.

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

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

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

В работе будут выполнены такие задачи:

– рассмотреть источники литературы по данной тематике;

– выполнить описание основных понятий и терминов теории реляционных баз данных;

– дать характеристику типам баз данных;

– рассмотреть и описать предметную область для выполнения процесса инфологического моделирования;

– на практике создать модель «сущность - связь» и описать основные ее параметры.

Объект работы – теория БД и СУБД;

Предмет работы – инфологическое моделирование.

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

1.ОСНОВЫТЕОРИИБД

1.1.Понятие БД иее основных компонентов

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

– для БД характерным являетсяввод в базу информации одни раз иее многократное применение;

– введенная информацияприменяетсядлярешенияпроблем,а также обеспечивается многоцелевое использование;

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

– всебазыданных могут также иметь свойство модельности(структурированности,что описывает рассматриваемуюобласть);

– базыпозволяют установить самый минимальный надобный уровень для исключения избыточности информации (такие данныенедублируются);

– в БД может обеспечиваться использование всех возможных инструментовпредставленияданных;[9]

– в БД также обеспечивается управление ресурсами, одновременная поддержкаданных с разных источников.

Припостроении базы необходимоучитывать,что они бывают:

– фактографические;

– смешанные;

– документальные.

Длядокументальных баз источниками данных являются обычные документы.

Перечень всех атрибутов, для такогослучая, перечислять вовсе нетрудно.

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

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

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

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

– о товарах запериод;

– опроизводственных ресурсах; [1]

– о наличии запасов;

– очисленностиперсонала и прочее.

Различаютследующиевидыформ, которые используются в БД:

– дляхранения;

– для регистрации;

– отчетные;

– для обследований.

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

Также размножение уже заполненнойформывкомпьютереможносделать при непосредственном использования копирующегоустройства.[10]

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

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

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

– длину поля;

– тип поля;

– процентналичияатрибута;

– вычисляемость;

– частота применения.

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

При этом определяются:

– ключи обращения;

– количество используемыхсущностей;

– процентобновления данных;

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

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

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

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

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

Информационная база при своем функционировании должнаудовлетворятьтаким требованиям:

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

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

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

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

Перечислим одни из главнейшихвидов записей:[14]

– научная документация;

– технологическаядокументация;

– данныеучета;

– использование конструкторских расчетов;

– данныефинансовойотчетности;

– сертифицированные конструкторскиеразработки;

– производственные собственности;

– патенты;

– бухгалтерская документация;

– вычисление зарплаты;

– тексты контрактов;

– отчетность;

– протоколы собранийакционеров;

– информация по выполнениюпланов.

Все такие используемые данные можно разделитьна большие 2 группы:[10]

– первичные – статистические данные;

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

Спонятием баз данных тесно повязаны терминыбанкаданныхисистем дляуправления БД. Первое понятие собою характеризует некоторую разновидность ИС,вкоторойреализовываются функциидляцентрализованногохранения, накоплению обрабатываемойинформации.[15]

Банк данных состоитскомпонентов:[4]

– администраторов;

– словаряданных;

– СУБД;

– базы данных;

– вычислительнойсистемы;

– обслуживающегоперсонала.

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

Логическая структура таких данных хранится вБД и имеет название модели храненияданных.[5]

1.2.ВидыБД и СУБД

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

Кмногим популярным моделям относятся:

– реляционные;

– иерархические;

– сетевые.

Стоит заметить, что появилисьтакиемодели, которые позже стали активно внедряться:

– многомерные;

– объектно-ориентированные;

– постреляционные.

В нынешнее время разрабатываютсявсевозможныесистемы, которыесчитаются комбинацией уже известных,что расширяют базовые.Вихчисле:

– объектно-реляционные;

– семантические;

– дедуктивно-объектно-ориентированные;

– концептуальные;

– ориентированные.[14]

Некоторыес них могут служить также дляинтеграции БД,языковпрограммирования(ЯП) высокого уровня.В БД также часто поддерживаются одновременносразу нескольких моделей.

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

Рисунок 1 – Иерархическая модель базы

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

Рисунок 2 – Структура сетевых баз

Реляционная модельбылапредложенаЭдгаромКоддомв 1980 г.и базируется напонятияхотношения.

Рисунок 3 – Структура реляционной базы

В первом разделе работы детально рассмотрены самые основные понятия и определения по теории БД, проведена общепринятая и современная классификация баз данных.

2.ИНФОЛОГИЧЕСКОЕ МОДЕЛИРОВАНИЕБД

2.1.Принципы инфологического моделирования

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

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

Необходимо также различать такие определения, кактип сущности, экземпляр сущности.

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

Экземпляры сущности относятся к конкретной вещи в определенном наборе. К примеру, типом сущности может являться ГОРОД, а экземпляром – Варшава, Киев и т.п.[3]

Атрибут– это поименованная характеристика для сущности. Его наименование также должно быть уникальным в конкретномвиде сущности, но может также быть одинаковым для разных типов сущностей (к примеру, ЦВЕТ может определять для многих сущностей: АВТОМОБИЛЬ, ДЫМ, СОБАКА и т.д.).

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

В другом контексте такой атрибут может выступать и как самостоятельная сущность. К примеру, для автомобильного завода понятие «цвет» – это только атрибут для продукта производства, но для лакокрасочной фабрики– тип сущности.[1]

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

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

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

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

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

Инфологическая модель также применяется на 2-м этапе проектирования БД, то есть после описания предметной области, после этапа постановки задания.

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

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

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

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

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

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

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

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

К таким моделям можно отнести также модель «сущность—связь», что была предложена Ченомв 1975 году, семантическую МД, предложенную Хаммером и Мак-Леономв 1980 г., функциональную модель данных Шипмана, что также созданную в 1980 году, и целый ряд других моделей.

У всех моделей имелись свои положительные или отрицательные стороны, но практическое испытание временем выдержала лишь первая. И в данный момент именно модель Чена «EntityRelationship», стала стандартом при инфологическом моделировании БД.

Общепринятым стало также сокращенное название ER-модель, а большинство современных CASE-средств могут содержать инструментальные средства для характеристики данных в формализме данной модели. Кроме того, были разработаны методы для автоматического преобразования проекта БД с ER-модели в традиционную реляционную, при этом само преобразование выполняется в модель, соответствующую СУБД. [20]

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

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

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

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

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

Основными в ER-модели являются следующие базовые понятия:[12]

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

Объект, для которого соответствует понятие сущности, также имеет свой набор атрибутов – характеристик, что определяют свойства этого представителя класса.

Существует 3 разновидности связей в базах данных:

– «один-ко-многим»;

– «многие-ко-многим»;

– «один-к-одному».

Отношение под названием «один-ко-многим» также имеет место, когда для одной записи таблицы может соответствовать сразу несколько записей в другойтаблице.[6]

Связь под названием "один-ко-многим" является очень распространенной для таких реляционных БД.

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

Поля, что входят в первичный ключ в данной ТБД, расположены всегда вверху и отделены от иных полей линией.

Рисунок 4 – Пример связи (1:М)

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

Рисунок 5 – Пример связи (1:1)

Данное отношение применяют, если не хотят, чтоб таблица БД не разрасталась от второстепенной информации.[14]

Отношение типа «многие-ко-многим» используется, когда:

– записи в родительской таблице соответствуют больше одной записи в другой таблице;

– записи в дочерней может соответствовать больше, чем одна запись в родительской.

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

Рисунок 6 – Пример связи (М:М)

Многие СУБД не поддерживают связи под названием «многие-ко-многим» на уровнях индексов или ссылочной целостности. [2]

Также считается, что все связи «многие-ко-многим» можно заменять на одну или же более связей типа «один-ко-многим».

К примеру (рисунок 7):

Рисунок 7 – Пример конвертации связи

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

Рисунок 8 – Пример связывания таблиц

Возможны 2 вида изменений, что приведут к утере связи между записями:

– изменение значения поля в записях родительской таблицы без дальнейшего изменения значений для полей связи в записях дочерней таблицы;[16]

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

Рисунок 9 – Изображение понятия целостности

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

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

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

3.ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ ИНФОЛОГИЧЕСКОГО МОДЕЛИРОВАНИЯ

3.1. Описание предметнойобласти

Проведем описание предметной области под названием «Компьютерная сеть».

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

– Компьютеры локальной сети;

– Справочник администратора;

– Рабочие станции, сервера;

– Пользователи.

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

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

Также по территориальному признаку сети можно разделить на:

– локальные;

– региональные;

– глобальные.

Компьютерную сеть представляютнекоторой многослойной моделью, которая состоит с:

– сетевые приложения;

– операционные системы;

– коммуникационное оборудование;

– компьютеры.

В компьютерных ЛВС используются самые разнообразные типы компьютеров.

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

К коммуникационному оборудованию относятся:

– сетевые адаптеры;

– сетевые кабели;

– модемы;

– промежуточная аппаратура сетей.

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

- трансиверы;

- маршрутизаторы;

- репитеры;

- мосты;

- коммутаторы;

- концентраторы;

- шлюзы.

Для обеспечения взаимодействия программно-аппаратных комплексов для ЛВС приняты единые правила, которые определяют разные алгоритмы передачи данных всетях.

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

Администратор сети выполняет такие функции:

-хранит и готовит резервныекопий всей информации, а также ее проверка или уничтожение;

-установка, конфигурирование необходимых обновлений ОС и другого ПО;

-конфигурирование или установка нового ПО и аппаратного обеспечения;

-поддержкав актуальном состоянии и создание учетных записей пользователей сети;

-устранение неполадок в ЛВС;

-планирование, а также непосредственное проведение работ по расширению ЛВС предприятия;

-документирование действий пользователей сети и другие.

3.2.ПостроениеER-диаграммы

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

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

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

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

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

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

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

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

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

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

Вданноевремяпрактическикаждыйс производителейСУБДпредлагаетсобственныйпродуктавтоматизированногопроектирования.Кпримеру,OracleDesigner (Oracle) илиPowerDesinger (Sybase), а также многиедругие.

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

Кромеэтого,нарынкетакже представленырешенияи 3-хфирм,непроизводящихСУБД.

– AllFusionERwinData Modeler;

– AllFusion Process Modeler идругие.

Созданиедиаграммыпод названием "сущность–связь"осуществляетсяпри использованииAllFusionERwinDataModeler,а дальнейшеемоделирование,включаяполную генерациюпрограммногокодадля созданияБДпроизводитсяпри применениипрограммыпод названием AllFusionProcessModeler, пример интерфейса которого показан на рисунке 10.

Ð ÐµÐ·ÑƒÐ»ÑŒÑ‚Ð°Ñ‚ Ð¿Ð¾ÑˆÑƒÐºÑƒ Ð·Ð¾Ð±Ñ€Ð°Ð¶ÐµÐ½ÑŒ Ð·Ð° Ð·Ð°Ð¿Ð¸Ñ‚Ð¾Ð¼ "allfusion erwin data modeler"

Рисунок 10 – Интерфейс программы

Создавнагляднуюмодель«сущность – связь»можнооптимизироватьструктуруопределенной БДидобитьсядля нееполногосоответствиятребованиямилизадачаморганизации.

Также визуальноемоделированиеповышаетуровень создаваемойбазыданных,а также продуктивностьискоростьразработки.[8]

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

– Программноеобеспечение – для хранения информации о программном обеспечении рабочих станций и серверов сети;

– Пользователи – для использования данных о разных пользователях;

– Рабочие станции – для сохранения данных о параметрах всех рабочих станций;

– Справочники администратора – для описания данных о работе компьютерной сети.

БД также может использоваться администратором для проведения учета с пользователями, инвентаризации средств ЛВС.

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

– Сущность Пользователи имеет такие атрибуты:

· Код пользователя;

· Телефон;

· ФИО;

· Адрес.

– Сущность ПО имеет атрибуты:

· Название;

· Год выпуска;

· Лицензия;

· Стоимость.

– Сущность Рабочие станции имеет атрибуты:

· Номер РС;

· Процессор;

· ОЗУ;

· HDD;

· Видеокарта.

– Сущность Справочник для администратора использует такие атрибуты:

· № п/п;

· РС;

· Пользователь;

· ПО;

· Начало сеанса;

· Конец сеанса.

Для каждой сущности выделим ключевое поле:

– Сущность Пользователи имеет следующее ключевое поле: Код пользователя;

– Сущность ПО имеет следующее ключевое поле: Код ПО;

– Сущность Рабочие станции имеет следующее ключевое поле: Номер РС;

– Сущность Справочник администратора имеет следующее ключевое поле: № п/п.

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

Овал: Название Построим информационно-логическую модель для БД (рисунок 11):

Рисунок 11 – ER – модель

Опишем созданные связи между сущностями.

В созданной модели присутствуют 4 главные сущности, которые связаны с помощью связи типа «один-ко-многим».

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

Аналогично можно объяснить и остальные связи.

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

ЗАКЛЮЧЕНИЕ

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

Современные крупные проекты для ИС характеризуются, как правило, такими понятиями:

– сложностью описания, что требуют тщательного моделирования и выполнения анализа данных;

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

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

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

– рассмотрены источники использованной литературы по данной тематике;

– выполнено описание основных понятий и терминов теории реляционных баз данных;

– дана характеристика типам баз данных;

– рассмотрена и описана предметная область для выполнения процесса инфологического моделирования;

– на практике создана модель «сущность - связь» и описать основные ее параметры.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. АгальцовВ.П.Базыданных.В2-хтомах.Т.1.Локальныебазыданных:Учебник/В.П.Агальцов.–М.:ИДФОРУМ,НИЦИНФРА-М,2013.–352c.

2. АгальцовВ.П.Базыданных.В2-хтомах.Т.2.Распределенныеиудаленныебазыданных:Учебник/В.П.Агальцов.–М.:ИДФОРУМ,НИЦИНФРА-М,2013.–272c.

3. БезручкоВ.Т.,Информатикакурслекций/В.Т.Безручко.–М.:ИД."Форум":ИНФРА–М.2013–432.с.

4. ГолицынаО.Л.Базыданных/О.Л.Голицына,Н.В.Максимов,–И.И.Попов.-М.:Форум,2016.352c.

5. ГолицынаО.Л.Базыданных:Учебноепособие/О.Л.Голицына,Н.В.Максимов,И.И.Попов.-М.:Форум,2016.–400c.

6. Интернеттехнологиивэкономике:Учебникподред.АбдиксеваН.М.:–М.:ИД."Форум":ИНФРА–М.2014–448с.

7. Информатика:Учебник/ПодредакциейВ.М.Мартю.–2015.–880с.

8. ИсаевГ.Н.Моделированиеинформационныхресурсов:Учебноепособие.–М.:Альфа–М:ИНФРА–М.2014–224с.

9. КарповаИ.П.Базыданных:Учебноепособие/И.П.Карпова.-СПб.:Питер,2013.–240c.

10. КирилловВ.В.Введениевреляционныебазыданных./В.В.Кириллов,Г.Ю.Громов.–СПб.:БХВ-Петербург,2014.–464c.

11. КошелевВ.Е.БазыданныхвACCESS2007:Эффективноеиспользование/В.Е.Кошелев.–М.:Бином-Пресс,2014.–592c.

12. КузинА.В.Базыданных:Учебноепособиедлястудентоввысш.учеб.заведений/А.В.Кузин,С.В.Левонисова.–М.:ИЦАкадемия,2014.–320c.

13. ЛивенаС.В.Материалыбазыданных"Пакеткадровика"/С.В.Ливена.–М.:ИНФРА-М,2015.–51c.

14. ОнковЛ.С.Компьютерныетехнологиивобразовании:Учебноепособие.–М.:ИД."Форум":ИНФРА–М.2014–224с.

15. ПироговВ.Ю.Информационныесистемыибазыданных:организацияипроектирование:Учебноепособие/В.Ю.Пирогов.–СПб.:БХВ-Петербург,2014.–528c.

16. РаневскаяМ.А.Компьютерныетехнологиивдизайне.–М.:ИД."Форум":ИНФРА–М.2014–304с.

17. РубальскаяО.Н.Информатика.СамоучительнаСD:Учеб.пособие.–М.:ИД."Форум":ИНФРА–М. 2015. – 224с.

18. СветловН.М.Информационныетехнологииуправленияпроектами:Учеб.пособие.–М.:ИД."Форум":ИНФРА–М.2014–232с.

19. СимоновВ.А.ПроектированиебазданныхвСУБДMySQL:Учебноепособие.–М.:ИД."Форум":ИНФРА–М.2014–160с.

20. ТитовВ.М.,Информатикадляэкономистов:учебник/В.М.Титов.–М.:ИД."Форум":ИНФРА–М.2013–448с.

Инфологическое моделирование. Модель ER сущность-связь

Инфологическое моделирование. Модель ER сущность-связь

Похожие работы на - Инфологическое моделирование. Модель ER сущность-связь