По определению в отношении не может содержаться два идентичных кортежа. Многие реляционные СУБД допускают хранение файлов данных идентичных записей. Если в каком-либо приложении хранение идентичных записей недопустимо, программист должен позаботься об этом лично.
Пример: реляционной базы данных.
Таблица 6.3 «Поставщик»
№ поставщика
Название поставщика
Город
Нормаль
Н.Новгород
Красная Этна
Н.Новгород
Уралмаш
Екатеринбург
Нормаль
Москва
Таблица 6.4 «Деталь»
№ детали
Название детали
Болт 17
Шпильки
Гайка 22
Гайка 10
Таблица 6.5 «Поставщик – Деталь»
№ поставщика
№ детали
Количество
БД содержит три типа информации.
· Информация о поставщиках деталей на предприятие (таблица 6.3):
номер поставщика;
наименование детали;
название города.
· Информация о деталях, используемых на предприятии (таблица 6.4):
номер детали;
наименование детали.
· Информация о номере и количестве поступления деталей от каждого поставщика (таблица 6.5)
Каждое отношение храниться в отдельном файле. Структура файла, хранящего отношение проста, то есть все записи имеют одинаковый формат.
Первичный ключ -есть атрибут или набор атрибутов, значение которых однозначно указывают на конкретный кортеж отношения. Первичный ключ должен быть минимальным набором атрибутов. Число отношений в БД и конкретные атрибуты, приписываемые каждому отношению определяются в процессе проектирования БД, который может быть довольно продолжительным. После проектирования создание БД средствами СУБД может пойти достаточно быстро.
В таблице 6.6 описаны типы данных для атрибутов БД «Поставщики и детали».
Таблица 6.6 Типы Атрибутов.
Атрибуты
Тип
Пном
Числовой (3)
Пназ
Символьный(16)
Гор
Символьный(15)
Дназ
Символьный(10)
Штук
Числовой (5)
Дном
Числовой (5)
Отношения и первичные ключи:
Поставщик (Пном, Пназ, Гор)
Деталь (Дном, Дназ)
Поставщик-Деталь (Пном, Дном, Штук)
Результатом проектирования является концептуальная модель БД.
Наиболее важными целями проектирования являются:
· Хранение всех необходимых данных в БД, т.е. централизация данных;
· Исключение избыточности данных;
· Уменьшение количества отношений в БД;
· Нормализация отношений для решения проблем, связанных с обновлением или удалением данных.
Первым шагом в процессе проектирования является определение перечня атрибутов (столбцов), которые должны храниться в БД.
На втором шагепринимается решение о том, сколько будет отношений и какие атрибуты будут храниться в каких отношениях.
Необходимо различать дублирование данных и дублирование с избыточностью:
Пример:
Таблица 6.7 Пример дублирования данных.
Табельный номер
Номер лаборатории
В таблице 6.7 Числа 12 и 17
дублируются, но не избыточны.
Таблица 6.8 Пример избыточного дублирования данных
В таблице 6.8 телефон лаборатории, как видно, дублируется, и это уже избыточное дублирование.
Третий шаг – устранение избыточности. Полученный файл после устранения избыточности следует считать неудовлетворительным. Во-первых, пустых полей в файле следует избегать, в такой структуре хранения для записей необходимо иметь процедуру поиска. Во-вторых, могут возникнуть серьезные проблемы с удалением информации. Если удалить работника 287, то исчезнет и соответствующий номер лаборатории.
Лучший способ устранения – разбиение отношения
«Служащий – лаборатория – телефон» (таблица 6.8) на два:
«Лаборатория – телефон» (таблица 6.9)
«Служащий – лаборатория» (таблица 6.10)
Таблица 6.9 «Лаборатория-телефон»
Таблица 6.10 «Служащий-лаборатория»
Номер лаборатории
Телефон лаборатории
Табельный номер
Номер лаборатории
2-17
4-41
Разбиение отношений на два или несколько – рабочая процедура проектирования.
Разбиение отношения на два или более приводит к увеличению числа файлов, хранящихся в БД, что порождает проблемы по обработке данных, в данном случае – замедление.
Некоторые отношения порождают серьезные проблемы по удалению и обновлению информации. Проектировщик БД должен уметь находить такие отношения и «нормализовать» их. Нормализация осуществляется путем разбиения отношения на два или более мелких отношения по определенным правилам.
