Реляционные таблицы

Реляционная таблица (relational table) определяется фиксированным множеством своих столбцов. Типы данных, которые хранятся в столбцах, относятся к встроенным или определяемым пользователем типам (т.е. доменам). Таблица может содержать произвольное количество строк (или записей). Поскольку таблица есть не что иное, как математическое множество, повторяющиеся строки в таблице отсутствуют.

Для некоторых столбцов допускается, что значение столбца в определенной стро­ке может принимать значение NULL. Значение NULL означает одну из двух возможно­стей: "не определенное в данный момент значение" или "неприменимое значение".

Одним из следствий требования к модели РБД, которое состоит в недопустимости дублирования строк, является наличие у каждой таблицы первичного ключа (primary key). Ключ - это минимальное множество столбцов (возможно один) таких, что значения в этих столбцах единственным способом идентифицируют одну строку в таблице. Таблица может содержать много подобных ключей. Один из этих ключей произвольным обра­зом выбирается как наиболее важный- это первичный ключ, (primary key). Другие ключи называются потенциальными (candidate) или альтернативным (alternative) ключами.

На практике таблица СУРБД не обязана иметь ключ. Это значит, что таблица (без уникального ключа) может содержать идентичные строки - чудное бесполезное свойство реляционной базы данных, когда две строки, содержащие одинаковые зна­чения во всех своих столбцах, никак нельзя отличить. В системах ОБД и ОРБД по­добное различение обеспечивается за счет наличия OID (два объекта могут быть рав­ными, но не идентичными, например, как две копии одной книги).

Хотя существует возможность ввести в UML стереотипы для моделирования реля­ционных баз данных, более удобно использовать специально предназначенные для этого диаграммные методы, позволяющие осуществить логическое моделирование реляционных баз данных.

На рис. 9 показана одна из подобных систем нотации. В качестве целевой базы данных здесь использовалась база данных DB2 копании IBM.

Рис. 9 Определение таблиц реляционной базы данных

Таблица Employee состоит из восьми столбцов. Последние три столбца допускают в качестве значений использование значения NULL. Столбец emp_id представляет собой первичный ключ. Столбцы {family_name, date_of_birth} определяют потенци­альные (альтернативные) ключи. Столбец gender определен на домене Gender.

Поскольку на РБД накладывается ограничение, которое заключается в том, что столбцы могут принимать только атомические однократные значения, моделирова­ние имени и телефонного номера работника вызывает у нас определенные затрудне­ния. В предыдущем случае мы использовали два столбца : family_name и firstname. Столбцы не сгруппированы и никак не связаны в модели. В последнем случае мы предпочли решение с двумя столбцами (phone_numl, phone_num2), допус­кающими наличие максимум двух телефонных номеров у каждого работника.

После того, как таблица определена с помощью CASE-средств, можно автоматиче­ски сгенерировать программный код для создания таблицы, как показано ниже. Сге­нерированный текст программы включает определение домена Gender и определе­ние бизнес-правила, определенного на этом домене.

Задание: Выполнить системное проектирование программной системы. Обосновать выбор базы данных и выполнить ее проектирования.

Предоставить отчет, содержащий результаты системного проектирования и проектирования базы данных

Контрольные вопросы:

1. Объясните, в чем состоит различие между распределенной системой обработки и распределенной системой баз данных.

2. Что такое трехзвенная архитектура? В чем ее преимущества и недостатки?

3. Что такое доминантный класс?

4. Что такое отношение соединения?

5. Каковы различия между объектной и реляционной моделью БД?