Базы Данных Лекции

Основные принципы организации баз данных

1. Понятие базы данных

К организации данных в системах автоматизированной обработки информации возможны два подхода:

1.Каждый пользователь системы создает наборы данных, необходимых для решения его задач, и пишет программы обработки данных. Например, в рамках ВУЗа различные подразделения (деканат, отдел кадров, бухгалтерия и т.п.) могут создать свои подсистемы, предназначенные для решения определенных задач.

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

Первый из подходов имеет ряд недостатков:

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

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

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

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

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

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

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

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

называется Системой Управления Банком Данных (СУБнД).

2. Требования, предъявляемые к БД

Правильно спроектированная БД должна удовлетворять следующим требованиям:

1.Минимальная избыточность. Непротиворечивость.

2.Целостность данных.

3.Независимость данных.

4.Возможность ведения (добавления и удаления) и актуализации (корректировки, модификации) данных.

5.Безопасность и секретность.

6.Высокая производительность. Минимальные затраты.

2

7. Соблюдение стандартов.

1.Минимальная избыточность означает то, что данные в БД не должны дублироваться. Избыточность данных, если она существует, влечет две опасности:

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

различных местах машинной памяти хранятся противоречивые данные. Возникновение противоречивости чрезвычайно опасно для БД.

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

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

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

Существуют специальные методы и приемы обеспечения целостности.

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

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

5.Безопасность и секретность означает защиту данных от несанкционированного доступа, преднамеренного и непреднамеренного разрушения данных, хищения данных. Система защиты должна иметь:

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

только с теми данными, которые необходимы для решения его задач, остальные данные должны быть для него "невидимыми";

-средства, обеспечивающие секретность данных.

Подобные средства содержатся в СУБД или разрабатываются системным программистом.

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

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

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

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

3

3. Уровни представления данных в БД

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

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

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

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

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

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

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

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

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

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

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

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

4

Лицо или группа лиц, ответственных за всю БД в целом, за систему защиты и за все уровни представления данных называется Администратором Базы Данных (АБД).

4. Языки баз данных

Основная часть СУБД, используемая программистом, это Язык Данных (ЯД). Существует следующие основные типы ЯД:

ЯОД - язык описания данных, ЯМД - язык манипулирования данными, ЯЗ - язык запросов.

ЯОД обязательно есть в любой СУБД, на нем описывается схема БД.

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

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

5. Логическая структура данных

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

Различают два понятия: тип объекта и экземпляр объекта.

Любой объект описывается следующей триадой: <Имя объекта, Свойства объекта, Значения свойств>

Тип объекта характеризуется первыми двумя компонентами триады. Для свойств устанавливаются имена. Например, имя объекта - СТУДЕНТ, свойства объекта: ФИО, ГРУППА, СРЕДНИЙ БАЛЛ и т.п.

Втеории БД понятие "тип объекта" часто заменяют понятием "СУЩНОСТЬ". Следует помнить, что эти понятия относятся к предметной области.

ВСУБД понятию "тип объекта" соответствует "тип записи", при этом имя объекта часто рассматривается как имя записи. Свойства объекта являются полями записи, каждое поле имеет имя соответствующего свойства.

Конкретные значения свойств определяют конкретный экземпляр объекта данного типа. Например: ФИО - Иванов И.И., ГРУППА - 037, СРЕДНИЙ БАЛЛ - 4,5.

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

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

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

5

5 Основные понятия реляционной модели данных

Реляционная модель была предложена американским математиком Е. Коддом в 1970 г. Это единственная из моделей БД, основанная на специальном разделе математики - теории отношений. Математическая обоснованность позволила сформулировать, достаточно строгие правила построения модели, обеспечивающие ее работоспособность. Языки данных, основанные на математическом аппарате теории отношений, позволяют составлять любые запросы к БД и выполнять разнообразные операции манипулирования данными.

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

Проиллюстрируем вышесказанное небольшим примером.

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

Впредметной области можно выделить два объекта: ПОСТАВЩИК и ИЗДЕЛИЕ. Каждый из объектов характеризуется рядом вполне определенных свойств. Анализ возможных запросов к БД и задач обработки данных позволяет установить, какие именно сведения о каждом из объектов следует хранить в БД.

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

ПОСТАВЩИК (П#, Имя поставщика, Город) ИЗДЕЛИЕ (И#, Наименование, Вес)

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

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

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

М

ПОСТАВЩИК ИЗДЕЛИЕ.

М

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

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

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

Создадим связующую таблицу ПОСТАВКИ (П#, И#, Количество).

7

Рассмотренная модель содержит три тернарных отношения (три таблицы с тремя столбцами).

6. Основные операции над отношениями

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

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

Пусть имеются два отношения: отношение с именем R и отношение с именем S. Каждое из отношений имеет арность 2 (бинарные отношения). Отношение R состоит из атрибутов А1 и А2, отношение S - из атрибутов А2 и А3.

Сцепление отношений.

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

Сцеплением отношений R и S называется новое отношение R*S, состоящее из кортежей <x, y, z>, для которых кортеж <x, y> принадлежит R, а <y, z> принадлежит S.

Пример 1.

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

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

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

Вобщем случае, если отношение R имеет арность m, а отношение S - арность n , то R*S будет иметь арность m+n-1.

Можно выполнить сцепление отношения с множеством.

Пусть множество М является одноэлементным и содержит одно значение {b} из того же домена, что и значения атрибута А2 отношения R. Тогда результатом операции сцепления будет отношение R*M, состоящее из тех кортежей отношения R, у которых значение атрибута А2 равно b.

Иными словами, в результате сцепления таблицы R с константой b из таблицы R оказались выбранными стоки, содержащие в столбце А2 значение b (см. Пример 1). Если в

9

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

Известно 5 нормальных форм (НФ) отношений. Нормализация выполняется поэтапно. Сначала отношение приводится к первой НФ (1НФ), затем - ко 2НФ и т.д. вплоть до 5НФ. Однако для устойчивой работы БД часто оказывается достаточным, если ее

отношения находятся в 3НФ.

Между формами существует следующая связь. Если отношение находится в 3НФ, то это значит, что оно уже находится во 2НФ и 1НФ.

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

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

В рассмотренной нами выше предметной области о поставках на предприятие изделий поставщик П1 поставляет в определенных количествах изделия И1, И2 и И3, поставщик П2 - изделия И1 и И2, а поставщик П3 - изделие П4. Отобразим эти данные в таблице ПОСТАВКИ 1. Такой вид таблицы типичен для многих документов. Так, например, в одну колонку таблицы часто помещают фамилию, имя и отчество человека или адрес, содержащий почтовый индекс, город, улицу, номер дома, номер квартиры.

Номера поставщиков П# уникальны, и этот атрибут можно принять в качестве первичного ключа отношения.

Можно заметить, что в отношении ПОСТАВКИ 1 значения ключа П# идентифицирует сразу несколько значений не ключевых атрибутов И# и Кол, что недопустимо. (В таблице на пересечении, например, строки П1и столбца И# содержится несколько значений номеров изделий ). Это отношение находится не в 1НФ.

Преобразуем отношение так, чтобы устранить этот недостаток. В преобразованном отношении ПОСТАВКИ первичный ключ - составной П# И# и каждое значение первичного ключа идентифицирует единственное значение не ключевого атрибута Кол. Это отношение находится в 1НФ.

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

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

10

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

Отметим, что у этого отношения первичный ключ составной - П# И#.

Рассмотрим следующую ситуацию. Пусть ведутся переговоры о поставках с новым предприятием Победа, расположенном в городе Тамбове. Требуется включить в таблицу сведения об этом предприятии и сведения о тарифе по доставки грузов с этого предприятия. Мы не сможем этого сделать. Это предприятия еще ничего не поставляет и код поставляемых изделий неизвестен, т.е. И# =0, а у составного первичного ключа ни одна из компонент не может быть нулевой. В этом и состоит аномалия включения.

Если же какое-либо предприятие, например, Заря перестанет поставлять нам изделия, то для него И# =0. Из таблицы придется исключить все сведения об этом предприятии, в том числе и те, которые мы хотели бы сохранить. В этом состоит аномалия удаления.

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

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

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

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

В таблицу ПОСТАВЩИК1 выделим атрибуты П#, Имя поставщика, Город, Тариф. Ключ этого отношения - П#. В таблицу ПОСТАВКИ выделим атрибуты П#, И#, Кол. Здесь