Определение типов данных атрибутов

Определение первичных ключей

Выявление нереализуемых связей

К нереализуемым относятся связи кардинальностью 1:n или n:m, обяза-тельные в обе стороны. Например, связь заказы–строки заказов: заказ не может быть пустым, и заказанный товар должен входить в определённый заказ. Т.е. нельзя добавить заказ, пока в нём нет ни одной строки, и нельзя добавить строку в несуществующий заказ. Эта проблема обычно решается так: связь делается необязательной со стороны первичного ключа, а внешний ключ остаётся обязательным. При этом в приложении необходимо предусмотреть правило обработки пустых заказов (например, их удаление).

К необычным конструкциям данных можно отнести так называемые взаимоисключающие связи, когда подчинённая сущность связана с одной из двух родительских сущностей. Например, счёт в банке может принадлежать либо физическому лицу, либо юридическому, и не может принадлежать и тому, и другому либо не принадлежать никому. Такую связь можно реализовать по-разному, например, введением в таблицу счетов двух внешних ключей (номер_физ_лица и номер_юр_лица) и следующего ограничения целостности:

(номер_физ_лица IS NULL AND номер_юр_лица IS NOT NULL) OR(номер_физ_лица IS NOT NULL AND номер_юр_лица IS NULL)

В принципе, можно создать таблицу и без первичного ключа. Но наличие у каждой таблицы первичного ключа – хороший стиль проектирования БД. Кроме того, если эта таблица является родительской для какой-либо другой таблицы, то определить первичный или уникальный ключ необходимо, чтобы можно было определить внешний ключ в подчинённой таблице. В качестве ПК следует брать тот уникальный атрибут сущности, по которому чаще всего происходит обращение к данным. Например, для БД налоговой инспекции это ИНН – индивидуальный номер налогоплательщика, а для БД ФОМС (фонда обязательного медицинского страхования) – номер медицинского полиса.

Если у сущности нет уникальных атрибутов, можно рассмотреть уни-кальные комбинации атрибутов. Но первичный ключ не должен быть длинным, т.к. ссылающийся на него внешний ключ будет занимать много памяти. Поэтому при отсутствии подходящих атрибутов нужно вводить суррогатный первичный ключ, который не несёт смысловой нагрузки и служит только для идентификации записей. (Некоторые СУБД позволяют определять значения такого ключа как AUTOINCREMENT, т.е. числовое поле, значение которого начинается с 1 автоматически увеличивается на 1 при добавлении новой записи).

Определение типов данных для полей таблиц зависит от требований ПО. Но можно дать следующие общие рекомендации по выбору типов данных:

1. Для коротких символьных значений и символьных строк фиксированной длины следует выбирать тип CHAR. Например, для поля "единица измерения" со значениями 'кг', 'шт.', 'уп.' (char(3)), для поля "пол" (char(1)) и т.п.
2. Для символьных строк переменной длины нужно выбирать тип VARCHAR с указанием максимально возможной длины хранимого значения. Если при добавлении данных длина строки превысит указанное ограничение, система не сможет добавить данные и вернёт сообщение об ошибке.
3. Для числовых атрибутов, не участвующих в сложных расчётах, нужно использовать основной числовой тип реляционных СУБД – тип NUMBER, указывая реально необходимое количество разрядов. Например, для атрибута Номер сотрудника это может быть NUMBER(4) (до 10000 человек), а для зарплаты – NUMBER(8, 2) (до 999999.99 рублей).
4. Для числовых атрибутов, которые участвуют в сложных расчётах, следует использовать такие числовые типы, которые хранят данные в машинном (двоичном) представлении. Это ускорит выполнение расчётов.
5. Для числовых атрибутов, имеющих ведущие нули, следует выбирать тип CHAR, а не числовой тип, иначе ведущие нули будут потеряны. Например, для серии и номера паспорта (char(10)).
6. Для хранения дат нужно выбирать тип DATE или его варианты (DATETIME, например). Это позволит использовать арифметику дат и не заботиться о правильности вводимых данных: СУБД сама проверит допустимость даты.
7. Для хранения больших объектов (графических, звуковых и т.п.) следует выбирать специальные типы данных, перечень которых зависит от выбранной СУБД. Это могут быть типы LONG, CLOB (character large object), BLOB (binary large object) и другие.
8. Для семантически одинаковых полей разных таблиц нужно выбирать одинаковые типы данных. Например, ФИО сотрудника и ФИО клиента. Во многих СУБД для упрощения типизации данных можно создать специальные типы данных (create type) и использовать их в качестве типов полей таблиц.