Отображение простых объектов

Определение состава полей основной таблицы. Для каждого простого объекта и его единичных свойств строится отношение, атрибутами которого являются идентификаторы объекта и реквизиты, соответствующие каждому из единичных свойств.

Для объекта O1 (см. рис. 2.62, а) отношение может выглядеть следующим образом:

Rl (ИO1, C1, C2, C5, C6). (3.1)

Определение ключа таблицы. Любой из уникальных идентификаторов объекта является вероятным ключом полученного отношения. Если объект имеет несколько уникальных идентификаторов, один из них выбирается в качестве первичного ключа, как правило, самый короткий из вероятных ключей. Но это не всегда должно быть обязательно так. На решение вопроса о выборе первичного ключа (кроме длины ключа) влияет ряд факторов.

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

2. Мнемоничность - легкость запоминания. Поскольку в качестве ключа обычно используются короткие обозначения, то при прочих равных условиях следует отдавать предпочтение тем из вероятных ключей, которые легче запомнить.

Среди названных выше критериев наиболее важным является стабильность. Например, если у объекта КАФЕДРА есть три идентификатора: «Наименование_кафедры_полное», «Наименование_кафедры_краткое» и «Код_кафедры», то даже если «Краткое_наименование» короче других полей, скорее всего в качестве первичного ключа будет выбираться «Код», потому что наименования кафедр подвержены достаточно частым изменениям. Поэтому в алгоритме при выборе первичного ключа в качестве «решения по умолчанию» принимается более короткий идентификатор, но от пользователя требуется либо подтвердить это решение, либо выбрать иной первичный ключ.

Если объект является зависимой по идентификации сущностью, то ключ соответствующего ему отношения будет составным, включающим идентификатор этого объекта и идентификатор «вышестоящего» объекта, т.е. идентификатор основного объекта мигрирует в таблицу, соответствующую зависимому объекту (рис. 3.1). Если идентификаторов у главного объекта несколько, то выбирается один из них, а именно тот, который выбран в качестве первичного ключа основной сущности. Полученный таким образом составной идентификатор зависимой по идентификации сущности будет использоваться во всех случаях, когда нужно отображать связь этого зависимого объекта с другими.

Рис. 3.1. Отображение зависимой по идентификации сущности:

а - фрагмент ER-модели; б - реляционная таблица

Обычно зависимый по идентификации объект и тот объект, от которого он зависит, связаны друг с другом отношением 1:М, и может сложиться впечатление, что перенесение ключа просто соответствует отображению этой связи. Однако это не совсем так. Если сущность не зависима по идентификации, то связь 1:М можно отображать в структуре БД как путем переноса ключа связанного объекта в таблицу, соответствующую подчиненному объекту (т. е. объекту, стоящему со стороны М), так и другими способами, а ключом таблицы, соответствующей подчиненному объекту, будет являться только идентификатор самого этого объекта. Для зависимого по идентификации объекта связь 1:М дополнительно в схеме БД отображать не надо.

Другими словами, при создании таблицы в каждом конкретном случае необходимо решать вопрос, что выбрать в качестве ключа: естественный ключ, искусственный ключ, в том числе и созданный системой автоматически, а может быть, если СУБД это позволяет, отказаться от создания ключа вообще.

Отображение множественных свойств объекта. Если у объекта имеются множественные свойства, то каждому из них ставится в соответствие отдельное отношение, полями которого будут идентификатор объекта (при наличии у объекта нескольких идентификаторов - тот из них, который выбран в качестве первичного ключа) и поле, отображающее множественное свойство. Ключ этого отношения будет составным, включающим оба эти атрибута. Так, для множественных свойств С3, С4 (см. рис. 2,62, а) будут созданы отношения

R2 (ИO1, C3);

R3 (ИО1, C4).

Приведенное выше решение является универсальным. В отдельных случаях могут быть приняты и другие варианты. Так, если число экземпляров множественного свойства у каждого объекта невелико и в процессе обработки не возникает необходимости выделять каждое из этих значений, то можно все значения, относящиеся к одному объекту, хранить в одном поле. В этом случае отдельную таблицу для хранения множественного свойства создавать не нужно.

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

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

2. Если только незначительное число объектов обладает указанным свойством, то для многих записей в файле базы данных при использовании предыдущего решения значение соответствующего поля будет пустым. Для устранения этого недостатка можно выделить отдельное отношение, которое будет включать идентификатор объекта и атрибут, соответствующий рассматриваемому свойству. Это отношение будет содержать столько строк, сколько объектов имеет рассматриваемое свойство. Однако это решение, в свою очередь, имеет недостатки (в частности, усложнение структуры БД и трудности ее обработки) и применяется сравнительно редко.

В отношении (3.1) использован вариант 1. Если бы было выбрано второе из обсуждаемых решений, то из отношения R1 атрибут С5 следовало бы исключить и создать дополнительно новое отношение:

R4 (ИO1, C5). (3.2)

Отображение составных свойств объекта. Если объект имеет составное свойство, то возможны два варианта его отображения в БД:

1. Всему составному свойству ставится в соответствие одно поле (3.1).

2. Каждому из составляющих элементов составного свойства ставится в соответствие отдельное поле:

Rl (ИО1, C1, C2, C5, C7, C8). (3.3)

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

2. Возможности ввода информации в реляционных СУБД.

Ввод данных в таблицу может быть осуществлен в режиме Таб­лица при работе с объектом ТАБЛИЦА.

Если таблица была создана ранее и в настоящий момент она зак­рыта, то попасть в режим Таблица можно, позиционировавшись на вкладке Таблица в окне БД на имени нужной таблицы и щелкнув по кнопке Открыть.

При создании новой таблицы после описания ее структуры мож­но сразу перейти в режим Таблица и приступить к вводу данных.

Каждая таблица содержит пустую запись, которая следует за по­следней существующей записью и предназначена для ввода новых данных. Эта запись отмечена слева символом «звездочка» (*). Пози­ционироваться на эту запись можно разными способами, например, щелкнув по соответствующей кнопке Новая запись в панели пере­мещения по записям или выбрав позицию меню Вставка/Но­вая запись, или просто мышью.

Введенные данные автоматически сохраняются при переходе к другой записи.

Для перехода между записями можно использовать кнопки внизу окна таблицы в панели перемещения по записям (к первой, следую­щей, предыдущей, последней записи).

Для облегчения процесса ввода данных в БД можно использовать соответствующие свойства полей: значение по умолчанию, маска вво­да, формат поля.

Значение по умолчанию. Обычно в этом качестве указывается какое-то постоянное значение, однако можно использовать и выраже­ние. Например, для ввода текущей даты можно в качестве значения по умолчанию использовать функцию =Date(). Значение, введенное по умолчанию, может быть впоследствии изменено.

Выражения, которые используются в качестве значений по умол­чанию, не должны содержать ссылок на элементы управления и дру­гие поля, а также функций, определенных пользователем. Выраже­ния могут записываться непосредственно или строиться с помощью «Построителя выражений».

Маска ввода (InputMask). Использование маски позволяет оп­ределить значения, которые можно ввести в поле, и не только обес­печивает контроль правильности ввода данных, но и облегчает их ввод. Значение свойства «Маска ввода» может быть введено вручную или с помощью Мастера масок ввода.

Используемые в масках знаки и их интерпретация приведены в приложении 1.

Рассмотрим некоторые примеры использования масок ввода.

1. Маска ввода для поля «Телефоны» может выглядеть следующим образом:

\(999")-"999\-9999

В приведенном примере константы (скобки, дефисы) отражаются на экране, но в базу данных не вводятся.

2. Пусть на фирме адрес электронный почты (ЭП) сотрудников
формируется следующим образом: префикс - любые четыре симво­ла, а затем для всех указывается @firm.ru

В этом случае маска может выглядеть следующим образом:

АААА"@ firm "."ru";0

Значение свойства «Маска ввода» может содержать до трех раз­делов, разделенных точкой с запятой (;). Первый представляет саму маску ввода, второй - определяет режим занесения в таблицу тексто­вых констант, добавляемых к знакам, вводящимся пользователем. «О» в данном компоненте указывает, что текстовые константы сохраня­ются вместе с введенными пользователем значениями; значение «1» или пустое значение данного раздела указывает, что сохраняются толь­ко знаки, введенные пользователем. В данном примере постоянная часть адреса электронный почты сохраняется в БД. Третий раздел определяет знак, используемый для изображения пустых позиций в маске ввода, в которые помещаются вводящиеся пользователем знаки.

Свойство «Формат поля» (Format). Кроме свойства «Маска вво­да» в Microsoft Access можно задать еще свойство «Формат поля» (Format). Их использование приводит к похожим результатам.

Свойство «Формат поля» влияет только на отображение значения, но никак не влияет на значение, хранимое в таблице. Для управления вводом данных удобнее использовать маску ввода.

Если для поля определены как формат отображения, так и маска ввода, то при добавлении и редактировании данных используется маска ввода, а формат поля определяет отображение данных после сохранения записи.

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