7.8. Описание логической структуры бд на языке субд (схема бд)

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

Схема БД

Отношение (файл)	Атрибут (поле)	Тип	Длина	Размер дробной части
PERSON	Nom	N	4	0
	FIO	C	15
	Rdate	D	8
	Pol	C	1
	SumD	N	15	0
	Adr	C	10
FLAT	Adr	C	10
	. . ..	. . .	. . .
HAVE_D	Nom	N	4	0
	Source	C	10
	Money	N	10	0
TPHONE	Ntel	C	7
	. . .	. . .	. . .
	Adr	C	10
PROFIT	. . .	. . .	. . .	. . .

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

7.9. Сравнение спроектированной рбд с однотабличной бд

Посмотрим, как обстоят дела с проблемами вставки, обновления и удаления в спроектированной РБД и БД Zgrad, состоящей из одного отношения, в котором атрибутами являются свойства всех объектов рассматриваемой ПО (рис.4.1).

Nom	FIO	Rdate	Pol	Adr	Ntel	. . .	Source	Mo-ney	SumD
1	Иванов И.И.	11.03.78	м	801-12	531-5894	. . .	Работа1	150	350
1	Иванов И.И.	11.03.78	м	801-12	531-5894	. . .	Работа2	200	350
2	Петрова П.П.	01.12.79	ж	05-321	Нет	. . .	Стипендия	100	250
2	Петрова П.П.	01.12.79	ж	05-321	Нет	. . .	Работа1	150	250
3	Иванова И.И.	14.04.30	ж	801-12	531-5894	. . .	Пособие	50	250
3	Иванова И.И.	14.04.30	ж	801-12	531-5894	. . .	Пенсия	200	250
4	Ильин Ф.П.	25.06.70	м	901-323	534-9900	. . .	Работа1	300	300
5	Иванов И.И.	23.10.28	м	801-12	531-5894	. . .	Пенсия	300	300

Рис.7.1. Однотабличная база данных Zgrad.

Проблема вставки

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

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

Проблема обновления

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

В спроектированной РБД эта проблема обновления не возникает: при изменении адреса Петровой П.П. обновляться будет атрибут Adr в одном кортеже отношения PERSON и возможно появится новый кортеж с описанием адреса и характеристик квартиры в отношении FLAT, если в РБД не было сведений об этой квартире.

Неявная избыточность в отношении Zgrad обнаруживается в том, что один и тот же номер телефона имеют все жители, живущие в одной квартире. Например, номер телефона для квартиры с адресом 801-12 появляется в сочетании с фамилиями трех жителей. Допустим, Иванов И.И. 1978 года рождения известит чиновника, ведущего базу данных, о том, что его номер телефона изменен на 531-55-33, забыв при этом сообщить о других жильцах квартиры. Если чиновник изменит номер телефона только в тех строках, которые содержат телефонный номер Иванова И.И. 1978 года рождения, то правильный номер телефона в квартире с адресом 801-12 будет фактически утерян, поскольку в отношении Zgrad будут присутствовать два различных телефонных номера для одной квартиры.

В спроектированной РБД описанная проблема обновления не возникает: при изменении номера телефона у Иванова И.И. 1978 года рождения, проживающего по адресу 801-12 (сведения из отношения PERSON), изменится только кортеж <5315894, ..., 801-12> в отношении TPHONE (в кортеже обновляется номер телефона, установленного в квартире 801-12).

Проблема удаления

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

В спроектированной РБД проблема удаления не возникает: для удаления сведений об источнике доходов у Ильина, номер которого равен 4, следует удалить кортеж <4, Работа, 300000> из отношения HAVE_D. После этого сведения о существовании Ильина остаются в отношении PERSON без изменений.

Итак, спроектированная РБД не создает проблем вставки, обновления и удаления при работе с ней.