Зависимость атрибутов:

Функциональная – каждому значению атрибута А соответствует в точности одно значение В: АB (частичная – зависимость неключевого атрибута от части составного ключа, полная – от всего ключа).

Транзитивная – если выполняется условие: АB и ВС

Многозначная – каждому значению А соответствует мн-во В.

Проектирование БД методом НФ – итерационный процесс – последовательное уточнение на основе предыдущего.

1НФ – все атрибуты атомарны (это исходное отношение);

Перевод отношений в следующую НФ осуществляется декомпозицией без потерь.

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

3НФ – каждый ключевой атрибут нетранзитивно зависит от первичного ключа.

БКНФ – отсутствуют зависимости атрибутов составного ключа от неключевых атрибутов.

СУБД: Access (фирмы Microsoft), Approach (Lotus), Paradox (Borland)

Основные функции субд:

• Определение данных (опред-ть какая именно инф б хр-ся в БД, задать св-ва данных, их тип, а также указать как эти данные связ м/у собой);

• Обработка данных (данные м обраб-ся самыми разл-ми спос. М выбирать  поля, фильтровать и сорт-ть данные. М объединить данные с др, связ-й с ними, инф-й и выч-ть итоговые знач-я);

• Управление данными (м указать, кому разрешено знакомиться с данными, коррект-ть их имя, добавлять новую инф-цию. М также опред правила коллект доступа).

Входящие в состав СУБД ср-ва совместно вып-ют след ф-ции:

• Описание данных;

• Первичный ввод, пополнение;

• Удаление устаревшей информации;

• Корректировка данных;

• Упорядочение (сортировка);

• Поиск по некоторым признакам;

• Подготовка и генерация отчетов;

• Защита и разграничение прав доступа;

• Резервное сохранение и восстановление;

• Интерфейс с юзером.

Всякая туфта 1: Реляционные бд.

Наиболее распростр-ми в практике явл-ся реляц-е БД. Название “реляц-я” (англ relation – отнош-я) связано с тем, что каждая запись в табл сод-т инф-цию, относящуюся только к одному конкр объекту.

Объект (или сущность) - это нечто существующее и различимое, т.е. объектом м назвать то “нечто”, для кот-го  назв и способ отличать 1 подобный объект от др. Н/р, каждая школа - это объект. Объектами также явл-ся чел, класс в шк, события, произвед искусства и т.д. Конкр-й объект в группе подобных объектов назыв экземпляром объекта.

Атрибут (или данное) - это некот-й показатель, кот-й хар-ет некий объект и принимает для конкр-го экземпл объекта некот-е числ-е, текстовое или иное знач.

Н/р, возьмем в кач набора объектов классы шк. Число уч-в в классе - это данные, приним-е числ знач. Назв класса (10А, 11Б) - это данное принем-е текст-е знач.

Атрибут некот-го набора объектов сам м.б. набором объектов, имеющие собств-е атрибуты. Н/р, атрибутом лица (как экземпляра набора объектов “лица”) явл вуз, кот-й это лицо окончило (ПГПУ, ПГТУ и т.д.). С др стороны, конкр-й вуз - это экземпляр набора объектов “Вузы” и хар-тся множ-м данных: фам-й ректора, адресом, специализацией и т.д. Наконец, ректор в свою очередь является экземпляром набора объектов “Лица”. Т.о., возн-т возм-ть установл связи м/у экземплярами объектов из разных наборов.

Всякое отнош д иметь свое имя. Пусть есть отнош с назв-м “Альбом группы”, т.е. вся табл 1 - это есть отнош “Альбом группы”. В этом случае стр-ра БД, сост-я из 1-й табл, запишется так: Альбомы группы (назв альб, год вып, тип, фирма) -это будет схемой отнош-я. Одна строка этой таблицы - это кортеж (запись), атрибут — это заголовок столбца табл. Элем-ты данных, из кот-х сост каждая запись, назыв полями. Поскольку во мн записях имеются одни и те же поля (с разл знач-ми), полям удобно дать уникал имена. Ключ или первичный ключ - это атрибут, однозн опред-щий кортеж, т.е. столбец с уникальн записями. Ключ м сост из неск-х атрибутов. С пом внешн ключа устанавл-ся связи м/у отнош-ми.

Ч/з связь установл-ю м/у общими полями, м узнать: сколько альб вып группа; в каком году было вып max кол-во альб и т.п.

Реляц-е БД удобны еще и тем, что для получ ответов на разл запросы  разраб-й мат-й аппарат, кот-й назыв исчисл-м отнош-й или реляц-й алгеброй. Ответы на запросы получ-ся путем “разрезания” и “склеивания” таблиц по строкам и столбцам. При этом ясно, что ответы тоже будут иметь форму таблиц.

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

М.Д. - термин, впервые введ-й в 70-е годы основопол-м теории БД Джонном Коддом, в соврем трактовке отображ-т совок-ть правил порожд-я стр-р данных в БД, последов-ти их изменения.

МД или их еще наз-т логич стр-ры данных бывают: 1. Реляц, 2.Иерархич, 3.Сетевая, 4.Объектно-ориентир - она объединяет 2 модели - реляц-ю и сетевую и исп-ся для крупных БД.

Стр-ра - это что-то опред образом упоряд-е. Н/р, чем отлич куча кирпича от стены, выложенной из того же кирпича? Куча не имеет стр-ры, если ее перемешать, то она все равно останется кучей. А стена - это стр-ра слова построенная из кирпича, если стр-ру разрушить, то стены не будет. Совок взаимосв-х данных назыв инф-й стр-рой или стр-рой данных.

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

Реляционная модель - это табл-я организ-я данных. Предп-м мы хотим собрать инф-ю про альбомы музык групп. Пусть имеется инф-я о нек-х альбомах 1965,Led Zeppelin 4, Lp, Help!, Atlantic, 1971, Lp(England), EMI, 1970, Flush Gordon, Parlophone, 1980, Led Zeppelin 3, Soundtrack, Lp, Atlantic.

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

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

Помимо свед указ-х в атрибутах, табл-я организация данных позв-т получить дополнит инф. К прим, нетрудно узнать (в предполож, что наша табл1 заполнена данными):

какая группа вып-ла > альбомов за опред период; число альб дан гр;

Иерар-я модель данных.

Описанную стр-ру данных м предст себе как дерево, ствол кот-го - это набор объектов. На стволе мы видим самый крупный узел - группу. Из этого узла растут ветви - альбомы. От ветки альбом Happy Nation исходят 3 ветви, каждая из кот-х заканч “листочком” - песней.

Важно отметить, что в дереве, м/у верх и ниж объектами задано отнош “один ко многим” (т.е. одной группе соотв-т много альбомов, одному альбому соотв мн песен).

Несмотря на то, что в атрибутах, описыв-х песню, нет назв альбома, глядя на дерево по линиям связи м сказать какая песня  альбому. Благодаря линиям связи м опред принадл-ть альбома группе. Из данной иерархич стр-ры м узнать: в каком альб > песен; число альбомов выпущ-х группой; есть ли в альб-х одинак песни и т.д.