ГОСУДАРСТВЕННЫЙ КОМИТЕТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ПО ВЫСШЕМУ ОБРАЗОВАНИЮ
Новосибирская государственная академия экономики и управления
ЛАБОРАТОРНЫЙ ПРАКТИКУМ ПО ДИСЦИПЛИНЕ
«Базы данных»
Лабораторная работа N 4
«Разработка схемы реляционной базы данных
на основе концептуальной модели»
НОВОСИБИРСК 2000
Введение
Одной из основных проблем проектирования баз данных является точное представление сложных аспектов прикладной проблемы. Если описание предметной области проектируемой информационной системы представляет собой сложную задачу, то требуется разработка концептуальной модели.
В связи с этим возникает задача преобразования концептуальной модели в схему БД. Наиболее распространенными являются СУБД, поддерживающие реляционную модель данных. Следовательно, необходимо уметь преобразовывать концептуальную модель в схему реляционной БД.
Лабораторная работа предназначена для практического освоения метода перевода концептуальных моделей в реляционную модель. Данный метод позволяет получать реляционную модель, соответствующую четвертой нормальной форме.
Для выполнения лабораторной работы требуется знание методов построения концептуальных моделей и основных понятий реляционной модели данных.
В результате выполнения лабораторной работы Вы освоите методы проектирования реляционных баз данных на основе концептуальных моделей.
Преобразование объектных множеств и атрибутов
Рассмотрим простую концептуальную модель на рис.1. Мы видим объектное множество с двумя атрибутами: PERSON (ЧЕЛОВЕК) — это абстрактное (то есть нелексическое) объектное множество, a SS# (.no-страховки) и BIRTHDATE (ДАТА-РОЖДЕНИЯ) - лексические атрибуты.
Рис. 1. Концептуальная модель человека
Поскольку атрибуты в реляционной модели должны быть лексическими, то SS# и BIRTHDATE могут быть атрибутами реляционной таблицы. Таким образом, мы можем преобразовать диаграмму в реляционную таблицу с атрибутами следующим образом PERSON (SS#, BIRTHDATE).
Что является ключом? Поскольку мы можем (и будем) предполагать, что SS# однозначно определяет человека, то ключом будет SS#. Таким образом, мы имеем PERSON (SS#, BIRTHDATE) в качестве результата преобразования концептуальной модели рис. 1 в реляционную модель.
2. Преобразование моделей без ключей
Теперь рассмотрим рис. 2. Мы можем попытаться преобразовать эту модель так же, как и предыдущую, получив в результате
SALE (AMOUNT, PRODUCT-#)
Но в этом случае отсутствует ключ, так как возможно несколько продаж с одними и теми же значениями AMOUNT (КОЛИЧЕСТВО) и PRODUCT-# (№-ТОВАРА). Таким образом, мы должны добавить ключевой атрибут SALE-# (№-ПРОДАЖИ):
SALE (SALE-#, AMOUNT, PRODUCT-#).
Мы можем кратко изложить суть процесса следующим образом. Объектное множество с атрибутами может быть преобразовано в реляционную таблицу с именем объектного множества в качестве имени таблицы и атрибутами объектного множества в качестве атрибутов таблицы. Если некоторый набор этих атрибутов может быть использован в качестве ключа таблицы, то он выбирается ключом таблицы. В противном случае мы добавляем к таблице атрибут, значения которого будут однозначно определять объекты-элементы исходного объектного множества, и который, таким образом, может служить ключом таблицы. В предыдущем примере мы добавили атрибут SALE-#, подразумевая, что SALE-# однозначно определяет элемент объектного множества SALE (ПРОДАЖА).
Рис. 2. Концептуальная модель продажи
Мы показали простой и быстрый метод создания ключей для таблиц, которые в противном случае их не имели бы. В действительной практике проектировщик базы данных должен советоваться с пользователем по поводу выбора ключа реляционной таблицы. Часто таким ключом будет номер счета или некоторое другое значение, которое записывается и может служить ключом. Это будет логичным выбором ключевого атрибута. Другая возможность состоит в том, что пользователь предложит набор атрибутов, которые вместе составят ключ. Аналитик несет ответственность за работу с пользователями при определении атрибута(ов) ключа.