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

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

Схема БД

Таблица БД	Атрибут	Тип	Размер	Допустимые значения	Значение по умолчанию
PERSON	Nom FIO Rdate Pol SumD Adr	Autoincrement Alpha Date Alpha Money Alpha	30 1 30	М,Ж	0
FLAT	Adr Skv Nrooms KCategory	Alpha Number Short Alpha	30 1	>=0 0..4 П,Н,К	0 0 Н
TPHONE	Ntel TCategory Adr	Alpha Alpha Alpha	8 1 30	###–#### О,Д,С	О
PROFIT	Id Source Moneys	Autoincrement Alpha Money	20	>=0	0
HAVE_D	Nom Id Comment	Long Integer Long Integer Alpha	30	>0 >0

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

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

Посмотрим, как обстоят дела с проблемами вставки, обновления и удаления в спроектированной РБД и БД Zgrad, состоящей из одного отношения, в котором атрибутами являются свойства всех объектов рассматриваемой ПО (рис.6.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

Рис.6.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 без изменений.

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