ВУЗ:
Составители:
Итак, центральной сущностью будущей модели данных является факт
рекламации товара. В рекламации участвуют и клиент, и
товар. В сходной сущности помимо атрибутов, идентифицирующих
клиента и товар (которые, следовательно, могут повторяться), присутствуют
атрибуты, характеризующие конкретный экземпляр данной сущности,- дата
рекламации, ее форма выражения, статус (первичная или повторная рекламации) и
причина. При проектировании данных желательно создать также уникальный
первичный ключ (например, номер рекламации). это более удобно чем
использовать комбинацию первичных ключей сущностей “Клиента” и “Товар”, к
тому же у клиента могут возникнуть проблемы с одним тем же товаром из разных
партий поставки (рис.2).
Рисунок 2
Учитывая возможную повторяемость значений атрибутов,
характеризующих дефект и статус рекламации, целесообразно создать
соответствующие дополнительные сущности, выполняющие роль справочников
(другими словами, произведем нормализацию данных к первой форме).
Теперь рассмотрим сущность “Клиент”. Очевидно, у предприятия может
быть несколько клиентов, имеющих одну и ту же значимость для него как
потребители товара, поэтому имеет смысл выделить “код значимости” в отдельную
сущность и связать ее посредством внешнего ключа с сущностью “Клиент”. В
результате получается логическая модель данных в виде (рис.3).
Возникает вопрос, а как быть с атрибутами сущности “Товар”?
Ведь очевидно, что атрибуты “Гарантия”и “N_партии” тоже повторяются.
При рассмотрении вопроса о целессобразности создания для них справочников,
примем во внимание то, что “Гарантия” имеет значения “Да” и “Нет”, а “N_партии”
это просто число и хотя этот атрибут может быть вынесен в отдельный справочник,
в данной лабораторной работе это не будет делаться из соображений достаточности
(нормализуя модель, можно дойти до такого состояния, когда выполнение запросов
к таблицам окажется весьма длительным из- за бльшого их числа).
Теперь следует подумать о физическом проектировании данных, а
именно о выборе СУБД, создании таблиц, соответствующих созданным
сущностям, типах полей для хранения атрибутов, а также о создании других
объектов БД, предназначенных для облегчения поиска в таблицах, контроля
ссылочной целостности данных, обработки данных таких как индексы, триггеры,
хранимые процедуры.
