Ограничения, относящиеся к записи

Если ограничения целостности затрагивают несколько полей од­ной записи, то они должны задаваться не как свойство записи, а как свойство таблицы (рис. 5.34). Чтобы попасть в окно Свойства таб­лицы, надо, находясь в окне конструктора таблицы, позициониро­ваться на заголовке этого окна, нажать правую клавишу мыши и в появившемся контекстном меню выбрать позицию Свойства.

Целостность связи

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

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

1. запретить удалять основную запись, если имеются подчиненные;

2. удалить вместе с основной записью и все подчиненные (кас­кадное удаление).

В Access при поддержании целостности связи автоматически при­нимается первая стратегия. Чтобы отменить ее для данной связи, надо установить флажок Каскадное удаление связанных записей.

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

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

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

5.3. Организация ввода и корректировки данных в бд

5.3.1. Общие сведения

После того как завершено проектирование структуры базы дан­ных и БД описана на ЯОД, можно приступать к вводу данных. Это можно сделать как сразу по окончании описания структуры таблицы (или иной информационной единицы, если речь идет не о реляцион­ной СУБД), так и потом.

Если для осуществления ввода просто воспользоваться командой ввода записи, то обычно на экране появляется структура записи в сле­дующем виде: все поля размещаются одно под другим (анкетная фор­ма) в том порядке, в котором они были заданы при описании структу­ры файла; для каждого поля слева указывается его идентификатор, а справа имеется окошко, длина которого совпадает с длиной поля. В это окошко можно вводить требуемое значение поля.

Другой способ - идентификаторы полей размещаются друг за дру­гом слева направо, а окошки располагаются под ними (табличная форма). Такой способ ввода данных имеет много очевидных недо­статков.

1. Идентификаторы полей часто бывают короткими и малоинфор­мативными.

2. Порядок ввода полей может не совпадать с порядком их распо­ложения в структуре файла БД.

3. Нерационально используется пространство экрана.

4. Не все СУБД позволяют задать контроль ограничений целост­ности при описании структуры БД и обеспечивать таким образом кон­троль правильности ввода.

5. Оформление экрана оставляет желать лучшего.

6. Невозможно в полной мере управлять выдачей подсказок пользователю.

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

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

Поскольку экранные формы могут использоваться для организа­ции как ввода, так и вывода информации, этот вопрос выделен в от­дельный раздел учебника (см. главу 8).

Заполнение БД можно осуществлять посредством ввода данных с клавиатуры, переноса данных из других файлов (той же СУБД) или путем импорта из других систем. Кроме того, можно формировать запись или отдельные ее элементы программным путем.

При организации ведения баз данных нужно стремиться к реа­лизации принципа однократного ввода информации. Вводить вруч­ную информацию в БД следует только тогда, когда невозможно это сделать иными способами, используя уже имеющуюся в ИС инфор­мацию. Современные СУБД предоставляют простые и быстро реа­лизуемые возможности по связыванию и совместной обработке фай­лов, по переносу данных из одних файлов в другие, возможности экспорта/импорта в другие системы; и этим надо пользоваться, из­бегая повторного ручного ввода данных. Кроме того, нужно стре­миться к достижению минимально возможного уровня дублирова­ния данных.

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

Как отмечалось выше, в большинстве случаев в БД не следует хранить производные показатели. Если же по каким-либо причинам это признано целесообразным, то значения этих полей следует не вводить вручную, а вычислять. Это не только сократит объем ручных операций и возможность ошибок при вводе, но и обеспечит автома­тическое поддержание целостности данных.

При организации ввода данных важно не только выявить возмож­ные ошибки, но и организовать ввод таким образом, чтобы предотв­ратить их.

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

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

Существует несколько вариантов ввода записей:

1. сразу в БД;

2. сначала в переменные памяти (при вводе данных в перемен­ные памяти они могут быть обособленными переменными, а могут быть организованы в виде массива);

3. с использованием вспомогательных файлов.

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

Третий вариант дает, кроме того, возможность распараллелить процесс ввода данных.

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

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

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

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

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

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

С помощью масок можно организовать ввод конфиденциальной информации (если использовать маску типа «пароль», то вместо сим­волов, введенных в поле, будут изображаться звездочки (*); если в СУБД нет специальных типов, предназначенных для подобных це­лей, то можно запрограммировать эту возможность самостоятельно (например, сделать одинаковым цвет букв и фона).

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

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