Пример инфологической модели

С.Ф. Сафаров

БАЗЫ ДАННЫХ

Учебно-методическое пособие по изучению курса
(для бакалавров направлений подготовки «Прикладная математика», «Бизнес-информатика», «Экономика»)

Новочеркасск

ЮРГПУ (НПИ)

2016

УДК 512.8 (076.5)

ББК 32.973.26

С 217

Рецензент – канд. техн. наук, доцент И.В. Шкуропадский

Сафаров С.Ф.

С 217 Базы данных: учебно-методическое пособие по изучению курса (для бакалавров направлений подготовки «Прикладная математика», «Бизнес-информатика», «Экономика») / С.Ф. Сафаров; Южно-Российский государственный политехнический университет (НПИ) имени М.И. Платова. - Новочеркасск: ЮРГПУ (НПИ), 2016. – 52 с.

Пособие содержит учебно-методические материалы по курсу «Базы данных »: краткое изложение основ теории Базы данных, примеры решения типовых задач, библиографический список.

Пособие предназначено для использования в учебном процессе бакалаврами, обучающимися по направлениям 01.03.04 Прикладная математика, 38.03.05 Бизнес-информатика, 38.03.01 Экономика.

УДК 512.8 (076.5)

ББК 32.973.26

Ó Южно-Российский государственный политехнический университет (НПИ) имени М.И. Платова, 2016

СОДЕРЖАНИЕ

ВВЕДЕНИЕ. 4

ТЕМА 1. ОСНОВНЫЕ ПОНЯТИЯ И ТЕРМИНЫ ТЕОРИИ БАЗ ДАННЫХ 6

1.1. Модели данных. 6

1.2. Классификация баз данных по принципу обработки данных. 7

1.3. Виды моделей данных. 8

ТЕМА 2. ИНФОЛОГИЧЕСКАЯ МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ" 10

2.1. Основные понятия. 10

2.2. Виды связи. 11

2.3. Классификация сущностей. 13

2.4. Первичные и внешние ключи. 14

2.5. Ограничения целостности. 17

2.6. Пример инфологической модели. 18

ТЕМА 3. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ.. 21

3.1. Понятие реляционной базы данных. 21

3.2. Цели проектирования. 22

3.2. Нормальные формы.. 26

3.3. Процесс нормализации. 27

3.4. Процесс проектирования реляционных баз данных. 29

3.5 Инфологическая модель «таблица-связь». 30

ТЕМА 4. АЛГЕБРА ОТНОШЕНИЙ (РЕЛЯЦИОННАЯ АЛГЕБРА). 31

4.1. Основные понятия. 31

4.2. Оператор переименования атрибутов. 32

4.3. Оператор объединения. 32

4.4. Оператор пересечения. 33

4.5. Оператор вычитания. 34

4.6. Декартово произведение. 34

4.7. Выборка. 35

4.8. Проекция. 35

4.9. Оператор соединения. 35

4.10. Операция деления. 37

ТЕМА 5. ЯЗЫК СТРУКТУРИРОВАННЫХ ЗАПРОСОВ (SQL). 37

5.1. Оператор выборки. 37

5.2. Совокупные характеристики. 40

5.3. Вложенные вопросы. 42

5.4. Соединение таблиц. 42

5.5. Реализация реляционной алгебры средствами SQL. 43

5.6. Операторы вставки, изменения и удаления данных. 44

5.7. Индексы в базах данных: назначение, влияние на производительность 45

5.8. Хранимые процедуры в базах данных. 46

ТЕМА 6. РАЗРАБОТКА ПРИЛОЖЕНИЙ ДЛЯ РАБОТЫ С БД.. 47

6.1. Технологии доступа к данным. 47

6.2. Компоненты доступа к данным. 48

БИБЛИОГРАФИЧЕСКИЙ СПИСОК.. 51

ВВЕДЕНИЕ

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

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

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

Применение ЭВМ для ведения[1]и обработки данных обычно приводит к еще большему разделению данных и интерпретации. ЭВМ имеет дело главным образом с данными как таковыми. Большая часть интерпретирующей информации вообще не фиксируется в явной форме.

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

Активная деятельность по отысканию приемлемых способов обобщения непрерывно растущего объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых "Системы управления базами данных" (СУБД).

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

База данных – поименованная совокупность взаимосвязанных данных, находящихся под управлением СУБД.

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

СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представление о таких понятиях, как:

· физическое размещение в памяти данных и их описаний;

· механизмы поиска запрашиваемых данных;

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

· способы обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;

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

ТЕМА 1. ОСНОВНЫЕ ПОНЯТИЯ
И ТЕРМИНЫ ТЕОРИИ БАЗ ДАННЫХ

Модели данных

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

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

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

Предметная область (часть реального мира, отражаемая в базе данных)

Инфологическая модель данных (обобщенное, непривязанное к каким-либо ЭВМ и СУБД, описание предметной области)

Даталогическая модель данных (описание предметной области на языке конкретной СУБД)

Физическая модель данных (описание хранимых данных)

БД

Рис. 1.1. Уровни моделей данных

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

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

1.2. Классификация баз данных
по принципу обработки данных

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

Централизованная база данных. При использовании этой технологии база данных располагается на одном компьютере, который может работать автономно или с поддержкой сети. Такие базы данных являются наиболее распространенными в настоящее время. Для этой технологии возможны два способа обработки данных:

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

Клиент-сервер. В основе этой концепции лежит идея о том, что помимо хранения файлов базы данных, центральный сервер должен выполнять основную часть обработки данных. Пользователи обращаются к центральному серверу с помощью специального языка структурированных запросов (SQL, Structured Query Language), на котором описывается список задач, выполняемых сервером. Запросы пользователей принимаются сервером и порождают в нем процессы обработки данных. В ответ пользователь получает уже обработанный набор данных. Между клиентом и сервером передается не весь набор данных, как это происходит в технологии файл-сервер, а только данные, которые необходимы клиенту. Запрос пользователя длиной всего в несколько строк способен породить процесс обработки данных, затрагивающий множество таблиц и миллионы строк. В ответ клиент может получить лишь несколько чисел. Технология клиент-сервер позволяет избежать передачи по сети огромных объемов информации, переложив всю обработку данных на центральный сервер. Кроме того, рассматриваемый подход позволяет избежать конфликтов изменений одних и тех же данных множеством пользователей, которые характерны для технологии файл-сервер. Технология клиент-сервер реализует согласованное изменение данных множеством клиентов, обеспечивая автоматическое соблюдение целостности данных. Эти и некоторые другие преимущества сделали технологию клиент-сервер очень популярной. К недостаткам этой технологии можно отнести высокие требования к производительности центрального сервера. Чем больше клиентов обращается к серверу, и чем больше объем обрабатываемых данных, тем более мощным должен быть центральный сервер.

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

Виды моделей данных

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

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

В настоящее время для обработки данных разработано множество различных моделей данных. Однако обычно говорят о трех основных моделях:

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

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

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

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

ТЕМА 2. ИНФОЛОГИЧЕСКАЯ МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ"

Основные понятия

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

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

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

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

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

Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть «студент», а экземпляром – «Иванов», «Петров» и т.д.

Атрибут – поименованная характеристика сущности.

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

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

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

Виды связи

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

Связь – ассоциирование двух или более сущностей.

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

Между двумя сущностями А и В возможны три вида связей:

1) Связь «один-к-одному» (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

АВ

Пример 2.1. Между сущностями «муж» и «жена» в России существует связь вида «один-к-одному», так как мужчина может состоять в браке не более чем с одной женщиной и наоборот, женщина может состоять в браке не более чем с одним мужчиной.

брак

муж

жена

2) Связь «один-ко-многим» (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В:

АВ

Пример 2.2. Между сущностями «комната» и «студент» существует связь вида «один-ко-многим», так как комната в общежитии может пустовать, в ней может жить один или несколько студентов.

Назначение

комната

студент

3) Связь «многие-ко-многим» (М:N): каждому представителю сущности А соответствуют 0, 1 или несколько представителей сущности B и наоборот - каждому представителю сущности В соответствуют 0, 1 или несколько представителей сущности А

АВ

Пример 2.3. Между сущностями «студент» и «преподаватель» существует связь вида «многие-ко-многим», так как у одного студента ведут занятия несколько преподавателей, которые преподают разные дисциплины и у преподавателя на занятиях присутствует много студентов.

Назначение

студент

преподаватель

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

1) Множество связей между одними и теми же сущностями.

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

Дипломный руководитель

Преподаватель

студент

лектор

2) Тренарные связи.

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

Назначение

Преподаватель

студент

Задание

3) Связи более высоких порядков, семантика (смысл) которых иногда очень сложна.

В приведенных примерах для повышения иллюстративности рассматриваемых связей не показаны атрибуты сущностей и ассоциаций во всех ER-диаграммах.

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

Классификация сущностей

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

Стержневая сущность (стержень) – это независимая сущность.

В рассмотренных ранее примерах стержни – это "студент", "преподаватель", "комната" и другие, названия которых помещены в прямоугольники.

Ассоциативная сущность (ассоциация) – это связь вида "многие-ко-многим" между двумя или более сущностями или экземплярами сущности.

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

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

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

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

Существование характеристики полностью зависит от характеризуемой сущности: женщины лишаются статуса жен, если умирает их муж.

Обозначающая сущность (обозначение) – это связь вида "многие-к-одной" или "один-к-одному" между двумя сущностями и отличается от характеристики тем, что не зависит от обозначаемой сущности.

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

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

Первичные и внешние ключи

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

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

Внешний ключ создается в сущностях, ссылающихся на другие сущности по правилам (рис.2.1):

· Если сущность С связывает сущности А и В, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В.

· Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.

Обозначение

другие поля

ВК

Стержень

другие поля

ПК

Ассоциация

ПК ассоциации

ВК1

ВК2

ВК3

другие поля

Сущность1

другие поля

ПК

Сущность2

другие поля

ПК

Сущность3

другие поля

ПК

Рис.2.1. Связь между первичными (ПК) и внешними (ВК) ключами в обозначении (сверху) и ассоциации (снизу)

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

Пример 2.6. ER-диаграмму брачных отношений можно представить в следующем виде (рис. 2.2).

брак

муж

жена

№

Фамилия

Имя

Отчество

год рождения

№

Фамилия

Имя

Отчество

год рождения

№муж

№жен

дата регистрации

№записи

Рис. 2.2. ER-диаграмма брачных отношений

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

Пример 2.7. Если ЗАГС регистрирует браки с учетом национальностей мужчины и женщины, то для брачных отношений можно составить ER-диаграмму, представленную на рис. 2.3.

брак

муж

жена

№

Фамилия

Имя

Отчество

год рождения

№

Фамилия

Имя

Отчество

год рождения

№муж

№жен

дата регистрации

№записи

национальность

№

наименование

№нац

Рис. 2.3 ER-диаграмма брачных отношений с учетом национальностей

Для учета национальностей в этом примере введена стержневая сущность «Национальность». Сущности «муж» и «жена» являются обозначающими относительно «национальности», поэтому в них необходимо ввести внешний ключ «№нац» для связи со стержневой сущностью (см. рис. 2.1).

Для каждого внешнего ключа необходимо решить три вопроса:

1). Может ли данный внешний ключ принимать неопределенные значения (NULL-значения)? Иначе говоря, может ли существовать некоторый экземпляр сущности данного типа, для которого неизвестна целевая сущность, указываемая внешним ключом?

2). Что должно случиться при попытке удаления целевой сущности, на которую ссылается внешний ключ? Существует три возможности:

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

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

· установление(relation). При удалении экземпляра стержневой сущности во внешних ключах, ссылающихся на этот экземпляр, устанавливается NULL-значение. Этот метод неприменим, если внешние ключи не могут принимать NULL-значения.

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

· каскадирование(cascading). При изменении значения первичного ключа стержня меняются также все внешние ключи, ссылающиеся на этот экземпляр;

· ограничение(restrict). Можно изменить значения лишь тех экземпляров первичных ключей, на которые не ссылается ни один внешний ключ;

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

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

Пример 2.8. Для ER-диаграммы, приведенной на рис.2.3, исходя из логических рассуждений целесообразно для внешних ключей ввести следующие ограничения:

· «№нац» – ограничение при удалении, каскадирование при обновлении;

· «№муж» и «№жен» - каскадирование при удалении и обновлении.

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

Ограничения целостности

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

Целостность данных может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1,2,3,4,5,6,7).

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

Выделяют три группы правил целостности:

1. Целостность по сущностям.

2. Целостность по ссылкам.

3. Целостность, определяемая пользователем.

Правила целостности, общие для любых реляционных баз данных.

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

2. Значение внешнего ключа должно либо:

· быть равным значению первичного ключа цели;

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

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

· уникальность тех или иных атрибутов;

· диапазон значений (экзаменационная оценка от 2 до 5);

· принадлежность набору значений (пол "М" или "Ж").

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

· название атрибута;

· его тип (например: целочисленный, текстовый длиной в 20 символов и т.д.);

· возможность хранения пустых значений (значений NULL);

· значение, присваиваемое полю по умолчанию.

· признак того, что поле является первичным ключом таблицы;

· признак уникальности значений поля;

· ограничения, накладываемые на значения поля;

· признак того, что поле является внешним ключом таблицы.

Пример инфологической модели

Рассмотрим инфологическую модель типа «сущность-связь» базы данных «Клиент».

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

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

С помощью них было решено хранить в базе информацию:

– о клиентах (наименование, полное наименование, руководство и контактные лица, почтовый и электронные адреса);

– видах деятельности (например, производство строительных материалов);

– типах деятельности (например, производство, посредничество, торговая деятельность и т.д.);

– городах и регионах.

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

1. Сущность «Клиент». Атрибутами являются:

· «№» – первичный ключ сущности. Уникальное ненулевое целочисленное поле.

· «Наименование» – ненулевое текстовое поле (100 символов), в котором будет храниться краткое наименование клиента, например «ЮРГТУ»;

· «Полное наименование» – текстовое поле (250 символов), в котором будет храниться полное наименование клиента, например «Южно-Российский государственный технический университет (Новочеркасский политехнический институт)»;

· «Почтовый индекс» – текстовое поле (6 символов);

· «Адрес» – ненулевое текстовое поле (50 символов), в котором будет храниться информация об улице, номере дома и офиса клиента;

· «Примечание» – текстовое поле (1000 символов), в котором будет храниться дополнительная информация о клиенте.

2. Сущность «Населенный пункт». Ее атрибутами являются: