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

 

3. ПОНЯТИЕ ИНФОРМАЦИОННОГО ОБЪЕКТА 
 

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

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

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

 

4. НОРМАЛИЗАЦИЯ ОТНОШЕНИЙ

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

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

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

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

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

• Первая  нормальная форма

 

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

     Например, отношение Студент = (Номер, Фамилия, Имя, Отчество, Дата, Группа) наводится в первой нормальной форме.

• Вторая  нормальная форма

 

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

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

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

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

     В случае составного ключа вводится понятие  функционально полной зависимости.

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

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

• Третья нормальная форма

 

     Понятие третьей нормальной формы основывается на понятии нетранзитивной зависимости.

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

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

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

 

     5. ТИПЫ СВЯЗЕЙ

 
 

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

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

     Связь один к одному (1:1) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот.

     При связи один ко многим (1:М) одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А. Графически данное соответствие имеет вид.

     Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В и наоборот.

 

6. МОДЕЛИ ДАННЫХ

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

 

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

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

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

     Сетевые модели также создавались для  мало ресурсных ЭВМ. Это достаточно сложные структуры, состоящие из «наборов» – поименованных двухуровневых деревьев. «Наборы» соединяются с помощью «записей-связок», образуя цепочки и т.д. При разработке сетевых моделей было выдумано множество «маленьких хитростей», позволяющих увеличить производительность СУБД. Но существенно усложнивших последние. Прикладной программист должен знать массу терминов, изучить несколько внутренних языков СУБД, детально представлять логическую структуру базы данных для осуществления навигации среди различных экземпляров, наборов, записей и т.п. Один из разработчиков операционной системы UNIX сказал: «Сетевая база – это самый верный способ потерять данные».

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

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

6.2 Проектирование модели данных

6.2.1 Этапы проектирования данных

 

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

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

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

     Т.е. говорят, что мы имеем дело с реальностью, описанием (представлением) реальности и с данными, которые отражают это представление.

     Данные, используемые для описания предметной области, представляются в виде трехуровневой схемы (так называемая модель ANSI/SPARC):

     

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

     Отсюда  вытекают основные этапы, на которые  разбивается процесс проектирования базы данных информационной системы:

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

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

     По  окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели «сущность-связь».

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

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

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

6.2.2 Представление данных с помощью модели «сущность-связь»

     Назначение  модели

 

     Прежде, чем приступать к созданию системы  автоматизированной обработки информации, разработчик должен сформировать понятия о предметах, фактах и событиях, которыми будет оперировать данная система. Для того, чтобы привести эти понятиях той или иной модели данных, необходимо заменить их информационными представлениями. Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель «сущность-связь» (entity-relationship model, ER-model).