Связи – это ассоциирование двух или же более сущностей. Если назначением БД было только хранение только отдельных, не связанных между собой массивов данных, то ее структура была бы простой.
Но одно с основных требований к выполнению организации базы данных –обеспечение возможности отыскания сущностей по значениям иных, для чего необходимо как-то установить между ними связи.
Так как в реальных БД нередко содержатся тысячи сущностей, то между ними теоретически может быть установлено миллионы связей. Наличие такого множества имеющихся связей и определяет всю сложность инфологических моделей.
Инфологическая модель также применяется на 2-м этапе проектирования БД, то есть после описания предметной области, после этапа постановки задания.
Процесс проектирования длительный, также он требует обсуждений с самим заказчиком, со специалистами по определенной предметной области. Наконец, в разработке серьезных корпоративных ИС проект БД является тем фундаментом, где строится в целомвся система, ивопрос о кредитовании проекта решается часто экспертами банка на базе именно грамотно сделанного предварительного проекта БД.
Следовательно, вся инфологическая модель должна в себя включать такое формализованное описание нужной предметной области, которое и будет «читабельно» не лишь для специалистов по БД, но и стороннего человека.
И такое описание должно быть емким, чтоб можно было оценивать глубину и всю корректность проработки БД, и конечно, оно не должно привязываться к конкретной СУБД. [19]
Непосредственный выбор СУБД – это отдельная задача и для корректного решения необходимо иметь также проект, который вовсе не привязан к конкретной СУБД.
Инфологическое моделирование прежде всего связывается с попыткой представления уровня семантики, то есть такого смыслового содержания для предметной области, которое используется в модели БД.
Реляционная модель данных (МД) в силу своей простоты, лаконичности не позволяет отображать семантику, то есть сам смысл предметной области остается за рамками классической реляционной модели.
Ранние, так называемые, теоретико-графовые модели в намного большей степени, чем традиционная реляционная модель, отображали уровень семантики предметной области. Они также в явном виде определяли разные иерархические связи между многими объектами предметной области.
Вся проблема представления семантики интересовала давно разработчиков, и в 1970-х годах было предложено сразу несколько моделей данных, которые назывались семантическими моделями.
К таким моделям можно отнести также модель «сущность—связь», что была предложена Ченомв 1975 году, семантическую МД, предложенную Хаммером и Мак-Леономв 1980 г., функциональную модель данных Шипмана, что также созданную в 1980 году, и целый ряд других моделей.
У всех моделей имелись свои положительные или отрицательные стороны, но практическое испытание временем выдержала лишь первая. И в данный момент именно модель Чена «EntityRelationship», стала стандартом при инфологическом моделировании БД.
Общепринятым стало также сокращенное название ER-модель, а большинство современных CASE-средств могут содержать инструментальные средства для характеристики данных в формализме данной модели. Кроме того, были разработаны методы для автоматического преобразования проекта БД с ER-модели в традиционную реляционную, при этом само преобразование выполняется в модель, соответствующую СУБД. [20]
Все CASE-системы используют развитые средства для документирования процесса разработки базы, автоматические генераторы отчетов имеют возможность подготовить отчет о состоянии проекта БД и подробное описание объектов БД.
В настоящий момент еще не существует единой системы обозначений в ER-модели и CASE-системы используют графические нотации, но освоив одну, можно легко понять иные.
Как и любая модель, «сущность – связь» имеет сразу несколько базовых понятий, что образуют исходные кирпичики, с которых строятся более сложные объекты.
Эта модель согласуется в наибольшей степени с концепцией объектно-ориентированного моделирования, которая в данный момент несомненно является основной для разработки сложного программного обеспечения.
Основными в ER-модели являются следующие базовые понятия:[12]
Сущность, с использованием которой моделируется целый класс однотипных объектов. Каждая сущность имеет имя, что является уникальным в пределах системы. Поскольку сущность соответствует классу однотипных объектов, предполагается, что в исследуемой системе существует целое множество экземпляров сущности.
Объект, для которого соответствует понятие сущности, также имеет свой набор атрибутов – характеристик, что определяют свойства этого представителя класса.
Существует 3 разновидности связей в базах данных:
– «один-ко-многим»;
– «многие-ко-многим»;
– «один-к-одному».
Отношение под названием «один-ко-многим» также имеет место, когда для одной записи таблицы может соответствовать сразу несколько записей в другойтаблице.[6]
Связь под названием "один-ко-многим" является очень распространенной для таких реляционных БД.
В распространенной нотации структуры БД IDEF1X отношение под названием «один-ко-многим» будет изображаться путем соединения таблиц специальной линией, которая на стороне в дочерней таблицезаканчивается кружком или другим символом.
Поля, что входят в первичный ключ в данной ТБД, расположены всегда вверху и отделены от иных полей линией.
Рисунок 4 – Пример связи (1:М)
Отношение под названием «один-к-одному» также имеет место, когда для одной записи в одной таблице соответствует только одна запись в другой таблице.
Рисунок 5 – Пример связи (1:1)
Данное отношение применяют, если не хотят, чтоб таблица БД не разрасталась от второстепенной информации.[14]
Отношение типа «многие-ко-многим» используется, когда:
– записи в родительской таблице соответствуют больше одной записи в другой таблице;
– записи в дочерней может соответствовать больше, чем одна запись в родительской.
Например, каждый студент изучает несколько предметов. Каждая дисциплина может изучаться несколькими студентами.
Рисунок 6 – Пример связи (М:М)
Многие СУБД не поддерживают связи под названием «многие-ко-многим» на уровнях индексов или ссылочной целостности. [2]
Также считается, что все связи «многие-ко-многим» можно заменять на одну или же более связей типа «один-ко-многим».
К примеру (рисунок 7):
Рисунок 7 – Пример конвертации связи
Рассмотрим связь «один-ко-многим», что наиболее часто встречается в БД. Как можно заметить, родительская и дочерняя таблицы связаны между собой с помощью поля «Шифр группы» (рисунок 8).
Рисунок 8 – Пример связывания таблиц
Возможны 2 вида изменений, что приведут к утере связи между записями:
– изменение значения поля в записях родительской таблицы без дальнейшего изменения значений для полей связи в записях дочерней таблицы;[16]
– изменение значения поля в одной с записей дочерней таблицы без изменения значения полей связи для родительской и дочерней таблицы.
Рисунок 9 – Изображение понятия целостности
В данных случаях наблюдается нарушение целостности БД, поскольку информация становится недостоверной. То есть, нужно блокировать действия, что нарушают целостность связей для таблиц, которую называют также ссылочной целостностью.
Чтобы предотвратить потерю ссылочной целостности, используется механизм каскадных изменений.
Во втором
разделе курсовой работы рассмотрены основные понятия инфологического
моделирования, приведены определения модели «сущность-связь», а также подробно
рассмотрены основные связи между таблицами БД.
Проведем описание предметной области под названием «Компьютерная сеть».
Определим предполагаемые сущности, которые применяются в базе данных.
– Компьютеры локальной сети;
– Справочник администратора;
– Рабочие станции, сервера;
– Пользователи.
Компьютерной сетьюназывается совокупность персональных компьютеров (ПК), которые могут осуществлять друг с другом взаимодействие при помощиразного коммуникационного оборудования или же ПО.
Компьютерные сети создаются такжедля доступа к так называемым общесистемным ресурсам (информационным, программным, аппаратным), которые являются распределенные в этой сети.
Также по территориальному признаку сети можно разделить на:
– локальные;
– региональные;
– глобальные.
Компьютерную сеть представляютнекоторой многослойной моделью, которая состоит с:
– сетевые приложения;
– операционные системы;
– коммуникационное оборудование;
– компьютеры.
В компьютерных ЛВС используются самые разнообразные типы компьютеров.
Компьютеры, а также их характеристики всегда определяют специальные возможности для сетей.
К коммуникационному оборудованию относятся:
– сетевые адаптеры;
– сетевые кабели;
– модемы;
– промежуточная аппаратура сетей.
Заметим, что ктакой промежуточной аппаратуре для современных компьютерных сетей входят:
- трансиверы;
- маршрутизаторы;
- репитеры;
- мосты;
- коммутаторы;
- концентраторы;
- шлюзы.
Для обеспечения взаимодействия программно-аппаратных комплексов для ЛВС приняты единые правила, которые определяют разные алгоритмы передачи данных всетях.
В качестве стандарта были приняты специальныесетевые протоколы, что могут определять взаимодействие ПК в сетях.
Администратор сети выполняет такие функции:
-хранит и готовит резервныекопий всей информации, а также ее проверка или уничтожение;
-установка, конфигурирование необходимых обновлений ОС и другого ПО;
-конфигурирование или установка нового ПО и аппаратного обеспечения;
-поддержкав актуальном состоянии и создание учетных записей пользователей сети;
-устранение неполадок в ЛВС;
-планирование, а также непосредственное проведение работ по расширению ЛВС предприятия;
-документирование действий пользователей сети и другие.
Средствадля автоматизированногопроектированиявконцептуальноймоделипривлекаютксебевнастоящеевремябольшойинтересичасто применяются впроцессеразработкиструктурБДиинтерфейсов пользователядля непосредственногодоступак ним.
Причинойприменения реляционных БД являетсято, чтоиспользованиевподавляющембольшинстветолько реальныхразработокБД вспиральноймоделижизненногоцикла(ЖЦ) программногообеспечения,чтопредусматриваеттакже последовательноесозданиесразу несколькихверсийПО.
Каждаяследующаяверсиявсебявключаетпредыдущую(возможно, инеполностью), а также являетсяответомнаразные замечанияили корректировки пользователя,полученныенепосредственно врезультатетестирования.
Основнаяидеядля применениясредствавтоматизированногопроектированияБДзаключаетсявтом,чтопроцессыручногокодированияначинаютсятолькопослеполного окончанияпроцессапроектирования.
Настадиивыполнения проектированиясхемаБДиинтерфейспользователябазеданныхсоздаютсяпрактически автоматически,исходятолько сописанияконцептуальноймодели,при использованииразных CASE-средств.
Конечно,разработанныйтакимобразоминтерфейснебудетзаконченнымпрограммнымпродуктом,хотяонпозволяетзаказчикамоценитьвозможностипродуктаивнестинекоторые коррективы.
Толькопослеполного одобрениязаказчиком всегорабочегопрототипаразработчикприступаеткручномукодированию, то есть ксозданиюзаконченногоприложения.
Напрактикеочень частоCASE-средстваиспользуютсяприсозданиисхемыБДввидеER-диаграммилигенерацииструктурБДдляконкретнойСУБД.
Также, послеполученияотзаказчикавсех измененийразработчикивносятв модель соответствующиеисправленияв модель"сущность–связь"игенерируютзановоструктурыбазданных.
Стоит отметить, что средстваавтоматическойгенерациидля интерфейсовБД используютсяреже.
Вданноевремяпрактическикаждыйс производителейСУБДпредлагаетсобственныйпродуктавтоматизированногопроектирования.Кпримеру,OracleDesigner (Oracle) илиPowerDesinger (Sybase), а также многиедругие.
Разные демонстрационныеверсииуказанныхпрограммныхпродуктовможнобесплатно загрузитьссоответствующихофициальных сайтов.
Кромеэтого,нарынкетакже представленырешенияи 3-хфирм,непроизводящихСУБД.
– AllFusion Process Modeler идругие.
Созданиедиаграммыпод названием "сущность–связь"осуществляетсяпри использованииAllFusionERwinDataModeler,а дальнейшеемоделирование,включаяполную генерациюпрограммногокодадля созданияБДпроизводитсяпри применениипрограммыпод названием AllFusionProcessModeler, пример интерфейса которого показан на рисунке 10.
Рисунок 10 – Интерфейс программы
Создавнагляднуюмодель«сущность – связь»можнооптимизироватьструктуруопределенной БДидобитьсядля нееполногосоответствиятребованиямилизадачаморганизации.
Также визуальноемоделированиеповышаетуровень создаваемойбазыданных,а также продуктивностьискоростьразработки.[8]
Рассмотрим сущности, которые будут используются для выполнения хранения информации в БД:
– Программноеобеспечение – для хранения информации о программном обеспечении рабочих станций и серверов сети;
– Пользователи – для использования данных о разных пользователях;
– Рабочие станции – для сохранения данных о параметрах всех рабочих станций;
– Справочники администратора – для описания данных о работе компьютерной сети.
БД также может использоваться администратором для проведения учета с пользователями, инвентаризации средств ЛВС.