Коррективы по ходу дела
Как известно, теория всегда отличается от практики. Конечно, чем выше уровень профессионализма, в какой бы то ни было области, тем меньше эти отличия, потому профи и получают свои "приличные" гонорары. Но основную массу пользователей и даже разработчиков СУБД составляют как раз не они, а самые настоящие любителя, так что лучше сразу привыкнуть к мысли о том, что в процессе разработки неизбежно будут "всплывать" всякие особые случаи, поправки и новые вводные, из-за которых ваш проект, полностью или частично, потребуется переработать. Обычно подобные коррективы касаются не чего-то там глобального, типа общей системы запросов или форм, а вещей куда более банальных, особенно при разработке самых первых своих проектов. В подавляющем большинстве "нюансы" начинаются еще на этапе воплощения первых таблиц или связывания их первыми запросами.
Зачастую все сводится к внезапному осознанию необходимости добавить в таблицу дополнительные поля, изначально проектом не предусматривавшиеся. Несмотря на банальность, это одновременно и просто и сложно. Просто - так как в техническом плане введение нового поля в существующую таблицу мало чем отличается от его определения при создании новой таблицы. Сложно - так как при большом объеме сопутствующих настраиваемых параметров лишь немногие, хорошо "набившие руку" люди ухитряются ничего не упустить. На первый взгляд это кажется не таким уж и принципиальным, однако накопление мелких ошибок достаточно быстро переходит в качество, то есть в такие трудно "вылавливаемые" ошибки, которые могут поставить в тупик и матерого профессионала, а уж времени на отладку отнимут вообще немеренно. Поэтому вопрос доработки таблиц в СУБД нелишне рассмотреть особо. Как говорится, тяжело в учении - легко в бою.
Начнем с самого простого - с переименования полей. Предположим, создали мы таблицу и сохранили ее, а потом оказалось, что какое-то поле названо не слишком верно или вообще с банальной орфографической ошибкой. Чтобы это исправить, надлежит предпринять следующие действия. Открываем таблицу "РУБРИКАТОР", которую мы создали ранее, в режиме конструктора (см. рис. 1), и выделяем, к примеру, поле " Рубрика", что в графе " Имя поля". Как только в нем замигает маркер, можно совершенно спокойно "забить" ее текущее содержимое и заменить более развернутым и казенным " Наименование рубрики". После сохранения таблицы и внесения изменений можно смело переключиться непосредственно в режим таблицы и полюбоваться на результат.
Но это еще только самая первая задачка. Гораздо сложнее, когда в практически "отстроенном" проекте, давно обросшем множеством ограничений и прочих "условий на значение", возникает необходимость вставить новое поле, причем не где-то в конце, а в самой середине, аккурат между уже обросшими связями и в каких-то запросах задействованными. Для освоения методики опять воспользуемся той же таблицей " Рубрикатор". Для начала соседние строки следует раздвинуть, то есть вставить между ними новую, временно пустую. Для этого выделяем мышью ту строку, НАД которой намерены вставить новую, и нажатием правой клавиши мыши активизируем контекстное меню (см. рис. 2), в котором выбираем режим ДОБАВИТЬ СТРОКИ. В описании таблицы появится новая, пока еще пустая, строка. Теперь ее нужно заполнить данными, однако, вместо черновой ручной работы, можно воспользоваться способностью компьютера повторять однажды сделанное. Сразу, как это реализовано, например, в электронных таблицах Microsoft Excel, в Microsoft Access нельзя просто выделить строку в одном месте и вставить такую же в другом. Такое "проходит", только если требуется заменить одно содержимое другим. В данном случае мы намеревались данные не заменить, а вставить, поэтому-то сначала вставляли пустую строку, чем создавали себе в некотором роде "простор для маневра". Теперь привычным способом выделяем, опять в режиме конструктора, всю строку "Наименование рубрики", при помощи инструментальной панели, системного или контекстного меню "выделить" в буфер, потом выделяем ту самую пустую строку и "вставляем" в нее содержимое вышеупомянутого буфера. Теперь у нас есть две строки с одинаковым именем и совершенно одинаковыми значениями настроек. Естественно, для нормального функционирования таблицы такую несуразность следует исправить. Для этого достаточно вышеописанным способом изменить наименование поля и по готовности сохранить таблицу. Правда, в том случае, если вы настраивали в том числе еще и подписи к полям, которые Microsoft Access 97 применяет в качестве всплывающей подсказки, не помешает скорректировать и их, иначе впоследствии пользователь может запутаться, что, согласитесь, нехорошо.
Как вы, надеюсь, уже поняли, сама по себе процедура копирования или вставки полей достаточно проста и позволяет сэкономить массу рабочего времени. Особенно в тех случаях, когда создаваемые поля одной или нескольких таблиц идентичны или близко похожи. В такой ситуации куда удобнее не создавать каждое поле по отдельности, а настроить и отладить всего одно, как правило первое, которое потом скопировать необходимое количество раз, слегка подкорректировав результат по мере необходимости.
Естественно, если СУБД Microsoft Access 97 "позволяет" поля вставлять, то согласно элементарной логике она же должна обладать возможностью удаления полей из таблицы как только надобность в них отпала. Обычно нужда в удалении возникает либо тогда, когда разработчик кардинально "пересмотрел" уже созданный проект, либо когда он слишком уж "перемудрил" с настройками конкретного поля и его теперь проще удалить и создать заново, чем исправить. Естественно, перед началом процедуры удаления следует выделить то, что подлежит "утилизации". Это может быть всего одно поле, то есть всего одна строка в таблице, открытой в режиме конструктора, а может быть и некоторое количество таких строк. Выделение одной строки производится обычным способом, при помощи маркера мыши. Слева в окне мастера определения таблицы, который предстает на экране каждый раз, когда сама таблица переводится в режим конструктора, располагается столбец "для особых пометок". Он не имеет наименования и не отражается как хранилище данных. Назначение этого столбца - хранить специальную служебную информацию, необходимую для нормального функционирования самой СУБД. В частности, именно в этом столбце Microsoft Access 97 "ставит" изображение ключа, которым обозначает ключевое поле. Так вот, если однократно кликнуть в этом столбце напротив какой-либо строки, то вся она автоматически будет выделена. Если же нужно выделить не одно поле, а несколько, то, не отпуская левую клавишу мыши, следует "растянуть" область выделения на любое количество строк вверх или вниз, после чего указанную клавишу отпустить. Для "любителей" преимущественно клавиатурного управления существует альтернативный способ: выделите одну строку, после чего нажмите клавишу Shift и, удерживая ее, раздвиньте область выделения в нужную сторону клавишами перемещения курсора вверх или вниз, затем отпустите Shift. Все, выделение готово. Правда, в Microsoft Access 97 непредусмотрено несмежное выделение, то есть программа вам не позволит выделить несколько отдельных друг от друга строк. Точнее, как только вы попытаетесь их "удалить", все остальные выделения, кроме активной в данный момент строки, будут утеряны. Теперь остается отдать СУБД соответствующую команду. Это делается либо через контекстное меню мыши (см. рис. 2), либо посредством режима УДАЛИТЬ системного меню ПРАВКА, либо вообще простым нажатием клавиши Del. Microsoft Access 97 по привычке "попросит" подтверждение на удаление данных, ссылаясь на то, что они будут потеряны навсегда (см. рис. 3), которое вам следует дать, нажав на экранную клавишу " ДА". В некоторых случаях "система" может "напомнить", что удаляемое поле, возможно, является индексированным и "не желает ли уважаемый дон еще поразмыслить". Если вы уверены в том, что не создавали никаких индексов, с данным полем связанных, то можете спокойно игнорировать это предупреждение. Единственное, что должно вас заботить, это возможность применения данных удаляемого поля (или группы полей) в каком-нибудь запросе или форме. При удалении Microsoft Access 97 вам ничего "не скажет", но вот указанные формы или запросы корректно работать уже, естественно, не будут, их придется корректировать в ручном режиме.
Довольно часто случается так, что вполне рационально спланированные с самого начала таблицы в процессе эксплуатации или тестирования базы данных вызывают раздражение не слишком удобным расположением полей. Конечно, для истинного профессионала совершенно все равно, как в таблице расположены те или иные поля, так как обращение к ним происходит через собственноручно разработанные формы, содержание которых зависит исключительно от их дизайнера. Однако практика показывает, что слишком уж утомительно бывает "лазить" по большой таблице в поисках совместно используемых, но нерационально разбросанных полей. Сие недоразумение ничего не стоит исправить буквально за пару минут, если воспользоваться встроенным в Microsoft Access 97 механизмом перемещения полей. Вообще говоря, в любой таблице поля следуют в том порядке, в котором они вносились при создании таблицы. Этот порядок становится видным каждый раз, как только таблица переводится в режим конструктора. В этом режиме поля допускается перетаскивать в любое место таблицы, чем по собственному усмотрению изменять порядок их следования. Для этого выделите ту строку, которую хотите переместить. Теперь, если снова навести маркер мыши на ячейку этой строки в служебном столбце и опять нажать левую клавишу мыши, окно мастера примет несколько иной вид. Во-первых, под маркером мыши и чуть правее появится маленький пунктирный прямоугольник, свидетельствующий о том, что выделенное поле захвачено и готово к перемещению. Во-вторых, если, не отпуская нажатую правую клавишу мыши, переместить маркер в любое место таблицы, то между ее строками станет перемещаться жирная черная линия. Она показывает то место, в которое в данный момент выделенная строка может быть автоматически перенесена. Как только необходимое вам место будет "найдено", отпустите левую клавишу мыши и Microsoft Access 97 переместит в него выделенную строку. Останется только сохранить внесенные изменения и "дело в шляпе". Следует заметить, что, в отличие от удаления, перемещение полей никак не отражается на их использовании в системе связей, форм или запросов, что, несомненно, чрезвычайно удобно.
В процессе работы с таблицами могут возникнуть и проблемы иного рода, связанные с неверным определением типов конкретных полей. Теоретически, ничего страшного в этом нет, если помнить, что любое преобразование типов данных всегда "что-то стоит". Допустим, никогда не поздно превратить число 2345 в текст, но вернуться обратно после такого превращения уже не удастся, ибо Microsoft Access 97 "не сможет" представить набор символов 2345 каким бы то ни было числом. Таким образом, перед началом любых запоздалых преобразований следует обратить внимание (и желательно запомнить) на содержание нижеследующей таблицы, описывающей все возможные виды преобразования типов данных.
Естественно, процедура преобразования данных в Microsoft Access 97 полностью автоматизирована. Разработчик в свойствах поля указывает желаемый их тип, а СУБД самостоятельно "переписывает" внутренний код. Впрочем, это таит в себе и некоторые проблемы. Как вы уже наверняка заметили, некоторые преобразования типов чреваты потерей части уже имевшихся в данном поле данных, если после преобразования их вид не соответствует определенному стандарту. Так, например, если вы возьметесь преобразовывать поле "Комментарий" какой-либо таблицы, данные которого содержали, в зависимости от конкретного случая, как текстовые пометки, так и графические "вставки", из типа MEMO в тип TEXT, то Microsoft Access 97 гарантированно "потеряет" все картинки, так как они не являются набором текстовых символов, а следовательно не могут храниться в поле текстового типа. Все это я рассказываю к тому, что в случае столкновения с какой-либо коллизией при операции преобразования СУБД немедленно выдаст оповещение с указанием количества подобных "неувязочек" и просьбой подтвердить преобразование. Если вы по рассеянности скажете "ОК", то потом останется только посыпать голову пеплом... ибо "откат" после преобразования невозможен. Поэтому, если система вдруг "споткнулась", целесообразно операцию преобразования отменить, а данные заново просмотреть и подкорректировать при необходимости. И еще, процедура преобразования типов теснейшим образом зависит от факта наличия в поле таблицы фактических данных и их количества. Мне известны случаи, когда Microsoft Access 97 занимался преобразованием около двадцати минут не на самых "слабых" машинах, так что если ваш электронный помощник не подает признаков жизни пару минут - не торопитесь его перегружать. Вполне возможно он занят весьма кропотливым делом и ему просто некогда отвлекаться на что бы то ни было.
Александр Запольскис
Начнем с самого простого - с переименования полей. Предположим, создали мы таблицу и сохранили ее, а потом оказалось, что какое-то поле названо не слишком верно или вообще с банальной орфографической ошибкой. Чтобы это исправить, надлежит предпринять следующие действия. Открываем таблицу "РУБРИКАТОР", которую мы создали ранее, в режиме конструктора (см. рис. 1), и выделяем, к примеру, поле " Рубрика", что в графе " Имя поля". Как только в нем замигает маркер, можно совершенно спокойно "забить" ее текущее содержимое и заменить более развернутым и казенным " Наименование рубрики". После сохранения таблицы и внесения изменений можно смело переключиться непосредственно в режим таблицы и полюбоваться на результат.
Но это еще только самая первая задачка. Гораздо сложнее, когда в практически "отстроенном" проекте, давно обросшем множеством ограничений и прочих "условий на значение", возникает необходимость вставить новое поле, причем не где-то в конце, а в самой середине, аккурат между уже обросшими связями и в каких-то запросах задействованными. Для освоения методики опять воспользуемся той же таблицей " Рубрикатор". Для начала соседние строки следует раздвинуть, то есть вставить между ними новую, временно пустую. Для этого выделяем мышью ту строку, НАД которой намерены вставить новую, и нажатием правой клавиши мыши активизируем контекстное меню (см. рис. 2), в котором выбираем режим ДОБАВИТЬ СТРОКИ. В описании таблицы появится новая, пока еще пустая, строка. Теперь ее нужно заполнить данными, однако, вместо черновой ручной работы, можно воспользоваться способностью компьютера повторять однажды сделанное. Сразу, как это реализовано, например, в электронных таблицах Microsoft Excel, в Microsoft Access нельзя просто выделить строку в одном месте и вставить такую же в другом. Такое "проходит", только если требуется заменить одно содержимое другим. В данном случае мы намеревались данные не заменить, а вставить, поэтому-то сначала вставляли пустую строку, чем создавали себе в некотором роде "простор для маневра". Теперь привычным способом выделяем, опять в режиме конструктора, всю строку "Наименование рубрики", при помощи инструментальной панели, системного или контекстного меню "выделить" в буфер, потом выделяем ту самую пустую строку и "вставляем" в нее содержимое вышеупомянутого буфера. Теперь у нас есть две строки с одинаковым именем и совершенно одинаковыми значениями настроек. Естественно, для нормального функционирования таблицы такую несуразность следует исправить. Для этого достаточно вышеописанным способом изменить наименование поля и по готовности сохранить таблицу. Правда, в том случае, если вы настраивали в том числе еще и подписи к полям, которые Microsoft Access 97 применяет в качестве всплывающей подсказки, не помешает скорректировать и их, иначе впоследствии пользователь может запутаться, что, согласитесь, нехорошо.
Как вы, надеюсь, уже поняли, сама по себе процедура копирования или вставки полей достаточно проста и позволяет сэкономить массу рабочего времени. Особенно в тех случаях, когда создаваемые поля одной или нескольких таблиц идентичны или близко похожи. В такой ситуации куда удобнее не создавать каждое поле по отдельности, а настроить и отладить всего одно, как правило первое, которое потом скопировать необходимое количество раз, слегка подкорректировав результат по мере необходимости.
Естественно, если СУБД Microsoft Access 97 "позволяет" поля вставлять, то согласно элементарной логике она же должна обладать возможностью удаления полей из таблицы как только надобность в них отпала. Обычно нужда в удалении возникает либо тогда, когда разработчик кардинально "пересмотрел" уже созданный проект, либо когда он слишком уж "перемудрил" с настройками конкретного поля и его теперь проще удалить и создать заново, чем исправить. Естественно, перед началом процедуры удаления следует выделить то, что подлежит "утилизации". Это может быть всего одно поле, то есть всего одна строка в таблице, открытой в режиме конструктора, а может быть и некоторое количество таких строк. Выделение одной строки производится обычным способом, при помощи маркера мыши. Слева в окне мастера определения таблицы, который предстает на экране каждый раз, когда сама таблица переводится в режим конструктора, располагается столбец "для особых пометок". Он не имеет наименования и не отражается как хранилище данных. Назначение этого столбца - хранить специальную служебную информацию, необходимую для нормального функционирования самой СУБД. В частности, именно в этом столбце Microsoft Access 97 "ставит" изображение ключа, которым обозначает ключевое поле. Так вот, если однократно кликнуть в этом столбце напротив какой-либо строки, то вся она автоматически будет выделена. Если же нужно выделить не одно поле, а несколько, то, не отпуская левую клавишу мыши, следует "растянуть" область выделения на любое количество строк вверх или вниз, после чего указанную клавишу отпустить. Для "любителей" преимущественно клавиатурного управления существует альтернативный способ: выделите одну строку, после чего нажмите клавишу Shift и, удерживая ее, раздвиньте область выделения в нужную сторону клавишами перемещения курсора вверх или вниз, затем отпустите Shift. Все, выделение готово. Правда, в Microsoft Access 97 непредусмотрено несмежное выделение, то есть программа вам не позволит выделить несколько отдельных друг от друга строк. Точнее, как только вы попытаетесь их "удалить", все остальные выделения, кроме активной в данный момент строки, будут утеряны. Теперь остается отдать СУБД соответствующую команду. Это делается либо через контекстное меню мыши (см. рис. 2), либо посредством режима УДАЛИТЬ системного меню ПРАВКА, либо вообще простым нажатием клавиши Del. Microsoft Access 97 по привычке "попросит" подтверждение на удаление данных, ссылаясь на то, что они будут потеряны навсегда (см. рис. 3), которое вам следует дать, нажав на экранную клавишу " ДА". В некоторых случаях "система" может "напомнить", что удаляемое поле, возможно, является индексированным и "не желает ли уважаемый дон еще поразмыслить". Если вы уверены в том, что не создавали никаких индексов, с данным полем связанных, то можете спокойно игнорировать это предупреждение. Единственное, что должно вас заботить, это возможность применения данных удаляемого поля (или группы полей) в каком-нибудь запросе или форме. При удалении Microsoft Access 97 вам ничего "не скажет", но вот указанные формы или запросы корректно работать уже, естественно, не будут, их придется корректировать в ручном режиме.
Довольно часто случается так, что вполне рационально спланированные с самого начала таблицы в процессе эксплуатации или тестирования базы данных вызывают раздражение не слишком удобным расположением полей. Конечно, для истинного профессионала совершенно все равно, как в таблице расположены те или иные поля, так как обращение к ним происходит через собственноручно разработанные формы, содержание которых зависит исключительно от их дизайнера. Однако практика показывает, что слишком уж утомительно бывает "лазить" по большой таблице в поисках совместно используемых, но нерационально разбросанных полей. Сие недоразумение ничего не стоит исправить буквально за пару минут, если воспользоваться встроенным в Microsoft Access 97 механизмом перемещения полей. Вообще говоря, в любой таблице поля следуют в том порядке, в котором они вносились при создании таблицы. Этот порядок становится видным каждый раз, как только таблица переводится в режим конструктора. В этом режиме поля допускается перетаскивать в любое место таблицы, чем по собственному усмотрению изменять порядок их следования. Для этого выделите ту строку, которую хотите переместить. Теперь, если снова навести маркер мыши на ячейку этой строки в служебном столбце и опять нажать левую клавишу мыши, окно мастера примет несколько иной вид. Во-первых, под маркером мыши и чуть правее появится маленький пунктирный прямоугольник, свидетельствующий о том, что выделенное поле захвачено и готово к перемещению. Во-вторых, если, не отпуская нажатую правую клавишу мыши, переместить маркер в любое место таблицы, то между ее строками станет перемещаться жирная черная линия. Она показывает то место, в которое в данный момент выделенная строка может быть автоматически перенесена. Как только необходимое вам место будет "найдено", отпустите левую клавишу мыши и Microsoft Access 97 переместит в него выделенную строку. Останется только сохранить внесенные изменения и "дело в шляпе". Следует заметить, что, в отличие от удаления, перемещение полей никак не отражается на их использовании в системе связей, форм или запросов, что, несомненно, чрезвычайно удобно.
В процессе работы с таблицами могут возникнуть и проблемы иного рода, связанные с неверным определением типов конкретных полей. Теоретически, ничего страшного в этом нет, если помнить, что любое преобразование типов данных всегда "что-то стоит". Допустим, никогда не поздно превратить число 2345 в текст, но вернуться обратно после такого превращения уже не удастся, ибо Microsoft Access 97 "не сможет" представить набор символов 2345 каким бы то ни было числом. Таким образом, перед началом любых запоздалых преобразований следует обратить внимание (и желательно запомнить) на содержание нижеследующей таблицы, описывающей все возможные виды преобразования типов данных.
Естественно, процедура преобразования данных в Microsoft Access 97 полностью автоматизирована. Разработчик в свойствах поля указывает желаемый их тип, а СУБД самостоятельно "переписывает" внутренний код. Впрочем, это таит в себе и некоторые проблемы. Как вы уже наверняка заметили, некоторые преобразования типов чреваты потерей части уже имевшихся в данном поле данных, если после преобразования их вид не соответствует определенному стандарту. Так, например, если вы возьметесь преобразовывать поле "Комментарий" какой-либо таблицы, данные которого содержали, в зависимости от конкретного случая, как текстовые пометки, так и графические "вставки", из типа MEMO в тип TEXT, то Microsoft Access 97 гарантированно "потеряет" все картинки, так как они не являются набором текстовых символов, а следовательно не могут храниться в поле текстового типа. Все это я рассказываю к тому, что в случае столкновения с какой-либо коллизией при операции преобразования СУБД немедленно выдаст оповещение с указанием количества подобных "неувязочек" и просьбой подтвердить преобразование. Если вы по рассеянности скажете "ОК", то потом останется только посыпать голову пеплом... ибо "откат" после преобразования невозможен. Поэтому, если система вдруг "споткнулась", целесообразно операцию преобразования отменить, а данные заново просмотреть и подкорректировать при необходимости. И еще, процедура преобразования типов теснейшим образом зависит от факта наличия в поле таблицы фактических данных и их количества. Мне известны случаи, когда Microsoft Access 97 занимался преобразованием около двадцати минут не на самых "слабых" машинах, так что если ваш электронный помощник не подает признаков жизни пару минут - не торопитесь его перегружать. Вполне возможно он занят весьма кропотливым делом и ему просто некогда отвлекаться на что бы то ни было.
Александр Запольскис
Компьютерная газета. Статья была опубликована в номере 08 за 1999 год в рубрике soft :: субд
