Логическая модель базы данных это кратко

Обновлено: 04.07.2024

Логические модели данных.

Иерархические, сетевые, реляционные модели данных.

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

Преимущества и недостатки

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

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

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

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

Итак, модель данных – модель логического уровня проектирования БД. Ее можно рассматривать как сочетание трех компонентов ( слайд 2 ):

1. Структурный компонент, т.е. набор правил, по которым может быть построена БД.

2. Управляющий компонент, определяющий типы допустимых операций с данными (сюда относятся операции обновления и извлечения данных, а также операции изменения структуры БД).

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

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

Существуют три основных типа логических моделей данных на основе записей ( слайд 3 ):

- реляционная модель данных ( relational data model );

- сетевая мо дель данных ( network data model );

- иерархическая модель данных ( hierarchical data model ).

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

11.2. Реляционная модель данных

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

11.3. Сетевая модель данных

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

Самой популярной сетевой СУБД является система IDMS / R фирмы Computer Associates .

11.4. Иерархическая модель данных

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

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

11.5. Преимущества и недостатки моделей

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

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

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

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

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

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

11.6. Документальные системы и интеграция моделей

Приведенные выше положения разрабатывались и действительно широко используются для баз данных хорошо структурированной информации. Однако уже сегодня одной из важнейших проблем становится обеспечение интеграции неоднородных информационных ресурсов, и в частности слабоструктурированных данных. Необходимость ее решения связывается со стремлением к полноценной интеграции систем баз данных в среду Web-технологий. При этом уже недостаточно простого обеспечения доступа к базе данных традиционным способом “из-под” HTML-форм. Нужна интеграция на модельном уровне. И в этом случае проблема семантической интероперабельности информационных ресурсов сводится к задаче разработки средств и технологий, предусматривающих явную спецификацию метаданных для ресурсов слабоструктурированных данных на основе традиционных технологий моделирования из области баз данных.

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

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

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

Этап 2-й. Логическое проектирование – развитие концептуального представления БД с учетом принимаемой модели (иерархической, сетевой, реляционной и т.д.).

Этап 3-й. Физическое проектирование – развитие логической модели БД с учетом выбранной целевой СУБД.

Концептуальное и логическое проектирование вместе называют также инфологическим или семантическим проектированием.

ERD были впервые предложены П. Ченом в 1976 г. Основные элементы ERD перечислены ниже .

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

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

Атрибут (столбец, поле) – свойство сущности или связи.

Большинство современных CASE-средств моделирования данных, как правило, поддерживает несколько графических нотаций построения информационных моделей. В частности система ERwin фирмы Computer Associates поддерживает две нотации: IDEF1X и IE (англ. Information Engineering – информационное проектирование). Данные нотации являются взаимно-однозначными, т. е. переход от одной нотации к другой и обратно выполняется без потери качества модели. Отличие между ними заключается лишь в форме отображения элементов модели.

При использовании любого CASE-средства вначале строится логическая модель БД в виде диаграммы с указанием сущностей и связей между ними. Логической моделью называется универсальное представление структуры данных, независимое от конечной реализации базы данных и аппаратной платформы. На основании полученной логической модели переходят к физической модели данных. Физическая модель представляет собой диаграмму, содержащую всю необходимую информацию для генерации БД для конкретной СУБД или даже конкретной версии СУБД. Если в логической модели не имеет значения, какие идентификаторы носят таблицы и атрибуты, тип данных атрибутов и т. д., то в физической модели должно быть полное описание БД в соответствии с принятым в ней синтаксисом, с указанием типов атрибутов, триггеров, хранимых процедур и т. д. По одной и той же логической модели можно создать несколько физических. Например, ERwin 4.0 позволяет на основании логической модели сформировать физические более, чем для 20 популярных СУБД (ORACLE, Informix, DB2, MS SQL Server, Access, Foxpro, Paradox и т. д.). На основании физической модели можно сгенерировать либо саму БД или DDL-скрипт 1 , который, в свою очередь, может быть использован для генерации БД.

Перечисленный выше порядок действий называется прямое проектирование БД (Forward Engineering DB). CASE-средства позволяют выполнять также обратное проектирование БД (Reverse Engineering DB), т.е. на основании системного каталога БД или DDL-скрипта построить физическую и, далее, логическую модель данных.

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

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

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

Далее рассматривается процедура прямого проектирования с использованием методологии IDEF1X. Методология IDEF1 была разработана Т. Рэмеем. В настоящее время на основе IDEF1 создана ее новая версия – методология IDEF1X, которая в 1981 г. принята ICAM в качестве федерального стандарта США.

1 Data Definition Language – язык определения данных, подмножество языка SQL.

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

Ниже рассматривается последовательность шагов при концептуальном проектировании.

1. Выделение сущностей.

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

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

· должна иметь уникальное имя, и к одному и тому же имени должна всегда применяться одна и та же интерпретация;

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

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

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

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

Рис. 7.1. Сущности

2. Определение атрибутов.

Выявленные атрибуты могут быть следующих видов:

· однозначный – содержит только одно значение для одного экземпляра сущности (например, у кривой в плане может быть только одно значение радиуса, угла поворота, возвышения наружного рельса и т. д.);

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

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

· неключевой (описательный) – не входит в первичный ключ;

· обязательный – при вводе нового экземпляра в сущность или редактировании обязательно указывается допустимое значение атрибута, т. е. оно после редактирования не может быть неопределенным (NOT NULL).

После определения атрибутов задаются их домены (области допустимых значений), например:

· наименование участка – набор из букв русского алфавита длиной не более 60 символов;

· радиус кривой – положительное число не более 4 цифр.

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

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

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

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

· альтернативные ключи (alternative key) – потенциальные ключи, которые не выбраны в качестве первичного ключа.

Если некий атрибут (набор атрибутов) присутствует в нескольких сущностях, то его наличие обычно отражает наличие связи между экземплярами этих сущностей. В каждой связи одна сущность выступает как родительская, а другая – в роли дочерней. Это означает, что один экземпляр родительской сущности может быть связан с несколькими экземплярами дочерней. Для поддержки этих связей обе сущности должны содержать наборы атрибутов, по которым они связаны. В родительской сущности это первичный ключ. В дочерней сущности для моделирования связи должен присутствовать набор атрибутов, соответствующий первичному ключу родительской. Однако здесь этот набор атрибутов уже является вторичным ключом. Данный набор атрибутов в дочерней сущности принято называть внешним ключом (foreign key).

Рассмотрим пример. Пусть имеется таблица, содержащая сведения о студенте, со следующими столбцами:

· номер пенсионного страхового свидетельства (НПСС);

· дата выдачи паспорта;

· организация, выдавшая паспорт.

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

· номер пенсионного страхового свидетельства;

Если в сущности нет ни одной комбинации атрибутов, подходящей на роль потенциального ключа, то в сущность добавляют отдельный атрибут – суррогатный ключ (искусственный ключ, surrogate key). Как правило, тип такого атрибута выбирают символьный или числовой. В некоторых СУБД имеются встроенные средства генерации и поддержания значений суррогатных ключей (например, MS Access).Также стоит отметить, что некоторые разработчики вместо поиска потенциальных ключей и выбора из них первичного в каждую сущность добавляют искусственный атрибут, который в дальнейшем и используют в качестве первичного ключа.

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

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

· размер ключа в байтах должен быть как можно короче;

· тип домена ключа – числовой. При выборе символьных атрибутов в ключ часто возникают проблемы с вводом ошибочных значений (путают регистр букв; добавляют лишние пробелы; используют буквы, пишущиеся на разных языках одинаково). В числовых атрибутах вероятность ошибки при вводе значения меньше;

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

Рис. 7.2. Сущности

3. Определение связей.

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

Среди них выделяются только те связи, которые необходимы для удовлетворения требований к разработке БД.

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

· именем – указывается в виде глагола и определяет семантику (смысловую подоплеку) связи;

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

· обязательностью: обязательная (при вводе нового экземпляра в дочернюю сущность заполнение атрибутов внешнего ключа обязательно и для введенных значений должен существовать экземпляр в родительской сущности) и необязательная (заполнение атрибутов внешнего ключа в экземпляре дочерней сущности необязательно или введенным значениям не соответствует экземпляр в родительской сущности);

o кватернарная и т.д.

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

Внешний вид связи на диаграммах IDEF1X указывает на ее мощность, тип и обязательность (табл. 7.1).

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

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

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

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

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

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

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

Цель:

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

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

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

Результат

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

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

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

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

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

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

Цель:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Номер

Фамилия

Имя

Отчество

Дата

Группа

Экземпляры ИнО Студент

Рис. 2. Пример структуры и экземпляров информационного объекта

В терминах реляционной модели ИЛМ – это совокупность взаимосвязанных таблиц, в которых хранятся данные о предметной области. В дальнейшем, будем пользоваться понятием таблицы, как элемента ИЛМ.

6.3.3. Связи между таблицами

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

Связи между таблицами имеют один из трех типов:

один-к-одному (1:1);
один-ко-многим (1:М);
многие-ко-многим (М:М).

Предположим, у вас есть две таблицы – ТабА и ТабВ.

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

Рис. 3. Реляционная модель

Связи могут быть обязательными и необязательными .

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

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

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

При графическом изображении ключевая связь помечается словом “key”.

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

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

Рис. 4. Связи между таблицами

6.3.4. Нормализация отношений

Понятие нормализации отношений

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

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

Целью разработки любой базы данных является хранение и использование информации о какой-либо предметной области. Для реализации этой цели имеются следующие инструменты:
1. Реляционная модель данных - удобный способ представления данных предметной области.
2. Язык SQL - универсальный способ манипулирования такими данными.

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

Логическая модель данных
Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий - "сотрудник", "отдел", "проект", "зарплата". Примеры взаимосвязей между понятиями - "сотрудник числится ровно в одном отделе", "сотрудник может выполнять несколько проектов", "над одним проектом может работать несколько сотрудников". Примеры ограничений - "возраст сотрудника не менее 16 и не более 60 лет".

Логическая модель данных является начальным прототипом будущей базы данных. Она строится в терминах информационных единиц, но без привязки к конкретной СУБД. Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь).

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

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

Элементы модели "сущность-связь"
В реальном проектировании структуры базы данных применяются другой метод - так называемое, семантическое моделирование. Семантическое моделирование представляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship).

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

Атрибут сущности – это именованная характеристика, являющаяся некоторым свойством сущности.
Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными).
Примерами атрибутов сущности "Сотрудник" могут быть такие атрибуты как "Табельный номер", "Фамилия", "Имя", "Отчество", "Должность", "Зарплата" и т.п.
Атрибуты изображаются в пределах прямоугольника, определяющего сущность:

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

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

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

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

Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней.

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

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

Создание инфологической и логической моделей базы данных
Разработка информационно-логической модели реляционной БД начинается с рассмотрения необходимых для её создания информационных объектов.

Таблица "Студенты"

Таблица "Преподаватели"

Выбор типа данных, содержащихся в полях БД Access, осуществляют с помощью следующей таблицы.

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

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

Читайте также: