Импорт базы данных БД ЧЭС

Импорт базы данных БД ЧЭС

Начнем с краткой характеристики базы данных БД ЧЭС.

Первый этап: импорт данных из среды Clarion в dBase

Сначала посмотрим, как выглядит фрагмент этой базы данных. На рис. 7.1 представлена часть окна базы данных – ответ на запрос об авариях на магистральных трубопроводах, которые произошли на территории Российской Федерации в 1995 г. По каждой из чрезвычайных ситуаций, содержащихся в этом списке, можно получить (в электронном или печатном виде) более подробную информацию.

Рис. 7.1

Для импорта базы данных используем конвертер Ccvt, который входит в состав программного обеспечения среды Clarion (см. рис. 7.2). Как видно из рисунка, конвертер предоставляет не слишком широкие возможности преобразования форматов: либо в текстовый файл на языке Basic, либо в универсальный обменный формат DIF, либо в один из форматов языка dBase. Однако Basic нам в данном случае не нужен, а DIF не получил широкого распространения. Значит, остается, как мы уже договорились, преобразовывать данные в формат DBF.

Как и раньше, мы будем рассматривать конвертацию данных на примере одного файла. Возьмем самый представительный в базе данных БД ЧЭС файл – File1.dat, показанный на рис. 7.2. В сущности, формальное преобразование происходит предельно просто. Выберите с помощью клавиатуры (а не мыши, так как MS DOS вполне может обходиться и без нее) выходной формат (Output Type) и имя выходного файла (Output File), который назовите Fiie1.dbf. Теперь нажмите клавишу Enter. Указывать файл-источник (Source File) не надо: имя этого системного файла Clarion введет самостоятельно. На данном этапе и произойдет преобразование: появится требуемый файл Fiie1.dbf. Если, вводя имя этого файла, вы не указали его расположение, то он будет помещен в ту же директорию, в которой находится конвертер Ccvt. Казалось бы, дело сделано, и можно переходить к следующему этапу конвертирования.

Однако не все так просто. В dBase действует ограничение на длину имени поля – оно не может превышать 10 символов. Кроме того, при конвертации в название включается префикс. Например, имя поля PEREDAL после преобразования превратится в FIL_PEREDA. Но в результате конвертации точно так же будет выглядеть и имя другого поля – PEREDAB. Тогда окажется, что в файле File1.dbf содержатся два поля с одинаковыми именами, что недопустимо. Конечно, такая проблема разрешается относительно легко: войдите в систему dBase и там исправьте имя файла. Поскольку данная ситуация является частной, здесь она подробно не рассматривается. Но очень важно помнить, что при переносе файлов из одной СУБД в другую (даже если речь идет о реляционных СУБД) необходимы повышенные осторожность и внимание. В следующем разделе будет показано, что описанный выше эпизод – не единственный случай, когда могут возникнуть проблемы.

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

Второй этап: импорт данных из dBase в Access 2002

Теперь нам нужно импортировать в базу данных Контрольно-измерительные приборы файлы из базы данных БД ЧЭС, конвертировав их при этом из формата dBase.

Снова откройте окно базы данных. Напомним, что необходимо выполнить следующие действия:

1. Из окна Access 2002 открыть базу данных по ее имени (БД ЧЭС).

2. Щелкните по кнопке

на панели инструментов базы данных. На экране появится окно базы данных (см. рис. 3.1).

3. Если начальная форма вам почему-либо мешает, уберите ее, щелкнув по кнопке закрытия окна.

Теперь в меню базы данных выберите опцию Файл, а в открывшемся подменю – Внешние данные. Затем активизируйте опцию Импорт, после чего на экране появится одноименное окно (рис. 7.3).

Вам придется пройти по дереву файлов в поисках базы данных в формате DBF, которую вы получили в результате первого этапа работы (см. предыдущий раздел). Как и раньше, возьмем в качестве примера файл File1.dbf. Чтобы увидеть его либо другие файлы этой базы данных в формате DBF, надо в поле Тип файла активизировать или какую-либо модификацию dBase (например, dBaseIII), или опцию Все файлы. В противном случае файлы формата DBF будут невидимы. Найдя нужный файл и пометив его, щелкните по кнопке

Если все прошло нормально, то Access 2002 выдаст сообщение об успешном импортировании файла (рис. 7.4). Щелкните по кнопке ОК.

Теперь надо закрыть окно Импорт, и тогда вы увидите, что в окне базы данных появилась новая таблица Fiie1 (см. рис. 7.5).

Поля даты и времени

Итак, второй этап импорта прошел успешно, и кажется, что с базой данных все в порядке. Однако приглядимся повнимательнее к импортированной таблице (см. рис. 7.6), особенно к полям даты и времени FIL_DATAY, FIL_TIMECH, FIL_DATAS, FIL_TIMESO. (Вы помните, как образовались эти имена? К исходным названиям полей файла File1.dat при преобразовании его в формат DBF слева добавляются префиксы FIL, а общее имя поля «обрезается» до 10 символов.)

На рис. 7.6 эти поля сгруппированы вместе, чтобы их удобнее было просматривать. Значения перечисленных полей выглядят необычно, и вы поймете, в чем дело, перейдя в режим конструктора. Окно режима конструктора показано на рис. 7.7. Оказывается, эти поля, которые должны принадлежать к типу Дата/Время, после преобразования относятся к типам Текст или Числовой.

Внесите необходимые исправления. Задайте для полей тип Дата/Время. В разделе для полей дат FIL_DATAY и FIL_DATAS установите значение свойства Краткий формат дат, что соответствует формату даты 09/12/1999, а для полей времени FIL_TIMECH и FIL_TIMESO – значение свойства Краткий формат времени, что соответствует изображению времени 12:36. Раз уж мы взялись наводить порядок, давайте зададим для свойства Заголовок перечисленных полей соответственно значения Дата ЧЭС, Дата сообщения о ЧЭС, Время ЧЭС, Время сообщения о ЧЭС. Путешествия во времени

Посмотрим, что у нас получилось. Перейдя в режим формы (см. рис. 7.7), вы обнаружите крайне любопытную картину. Поля времени теперь имеют привычные русскоязычные имена и выглядят нормально, если не считать того, что в большинстве случаев в них представлены нулевые значения. (Заметим, что это не ваша вина; информация о времени ЧЭС и уж тем более о времени передачи сообщения поступает далеко не всегда.) Но взгляните на поля дат. На календаре базы данных должен стоять 1995 год – год, указанный в запросе. А в таблице, которая представлена на рис. 7.8, вы видите 2093 год.

Этот забавный факт имеет вполне рациональное объяснение, связанное с тем, что называется несовпадением в исходных установках различных СУБД. Если не задать заранее точное значение типа поля [8] – а для даты и времени это Дата/Время, то каждая введенная дата будет заноситься в память СУБД в виде числового выражения. Оно представляет собой количество дней, прошедших от даты, принятой за точку отсчета (ей присвоено значение 1). Это имеет определенный смысл: при необходимости вы сможете выполнять с датами арифметические действия. Если вы вводите значение времени, оно сохраняется в памяти в виде десятичной дроби, которая равна прошедшей на данный момент части дня. (За точку отсчета принимается 12 часов ночи.) А вот исходная дата в каждом семействе СУБД может быть разной. Например, в различных редакциях пакета Office, частью которого является Access, такой датой является 1 января 1900 года. В версиях языка dBase (одну из которых мы использовали) это 1 января 1800 года. Теперь вам понятны числа, которые появились в полях дат сразу после конвертации файла File1 в Access 2002 (см. рис. 7.6). А вот сутки во всех семействах СУБД начинаются в полночь, и тут при всем желании трудно придумать что-то оригинальное.

Возникает естественный вопрос: почему при конвертации данных в dBase нельзя установить для полей дат соответствующий формат, а не цифровой, который был использован в нашем примере? К сожалению, в dBase задано жесткое ограничение на длину поля Дата – 8 байт. Если вы считаете необходимым использовать четырехзначные символы для указания года (вспомните «проблему 2000 года»), то в отведенный лимит явно не укладываетесь: поля дат получатся просто пустыми, что вас, разумеется, не устроит.

Однако, объяснив этот печальный факт, вы не избавились от необходимости исправить положение. Чтобы сделать это, воспользуйтесь операцией замены-вставки. Сначала выделите столбец Дата ЧЭС, щелкнув кнопкой мыши по его имени. Теперь в меню Access 2002 откройте таблицу Fiie1 в режиме конструктора (см. рис. 7.8). Активизируйте меню Правка и выберите Найти. Можно, не входя в меню, просто применить комбинацию клавиш Ctrl+F. В результате на экране появится окно Поиск и замена (рис. 7.9).

Теперь откройте вкладку Замена и установите следующие значения полей:

• Образец – /2093 (часть поля в столбце, которая подлежит замене);

• Заменить на – /1994 (год, устанавливаемый в порядке замены);

• Совпадение (данная опция задается стрелкой прокрутки);

• Просмотр – Все. Задается стрелкой прокрутки.

После этого следует щелкнуть по кнопке Заменить все. Затем повторить описанную процедуру для столбца Дата сообщения. В ходе операции поиска-замены по всем полям этих двух столбцов значение года – 2093 – будет заменено на 1994. Итоговый вид таблицы после внесенных исправлений представлен на рис. 7.10.

Но и это еще не все. Если сравнить сообщение о ЧЭС, полученное из исходной базы данных в среде Clarion, и его изображение после конвертации в Access 2002, то можно обнаружить одно различие, свойственное всем записям. Состоит оно в том, что в новой базе данных даты всех событий сдвинуты на один день вперед по сравнению с исходной базой данных. Если, согласно информации в исходной базе данных, авария на магистральном трубопроводе произошла 23.03.95, то в новой БД этому событию соответствует другая дата – 24.03.95. В чем тут дело? Детальная проверка объясняет причину такого сдвига во времени: в разных СУБД заложены разные установки насчет того, как представлять дату 29.02 в високосном году. Это и проявляется при преобразовании базы данных. Там за несколько лет накапливаются большие массивы информации, и в каждом високосном году 29 февраля происходит своеобразная «мутация»: в преобразованных записях все даты отличаются от исходных на +1 день. Через 4 года сдвиг увеличивается еще на 1 день, и т. д. Как видите, здесь необходима корректировка, и осуществить ее технически несложно; потребуются лишь внимательность и методичность. Просто сравните выбранные вами контрольные записи в исходной БД с их отображением в новой, итоговой базе данных и определите границы подмассива с конкретным значением сдвига (например, + 1). Теперь исправьте данные этого подмассива с помощью операции поиска-замены так, как было показано выше. Сортировка записей

И наконец, последняя операция: таблицу базы данных желательно, хотя и не обязательно, отсортировать. Операция сортировки записей в Access 2002 очень проста. В окне конструктора (см. рис. 7.10) выделите тот столбец, по которому требуется сортировать записи. Сама сортировка производится с помощью одной из двух кнопок:

или

Посредством первой из них вы располагаете записи по возрастанию: для цифровых символов – от 0 до 9, для текстовых – от A до Z. Вторая кнопка, соответственно, используется для сортировки записей по убыванию. Щелкните по одной из кнопок.

Теперь оглянемся назад и посмотрим, что уже сделано и что еще предстоит выполнить.

Вы преобразовали и импортировали в Access 2002 один файл (Fiie1) базы данных БД ЧЭС из СУБД, созданной в среде Clarion. Но, во-первых, вы импортировали только часть информации (данные лишь за один год), а в БД ЧЭС накоплены записи с 1990 года. Во-вторых, в БД ЧЭС есть еще несколько словарных файлов, которые тоже нужно перенести в новую базу.

Что касается первой части вопроса, то можно, конечно, пополнить базу данных новыми записями точно так же, как данными одного года. Впрочем, для осуществления этой типовой операции вполне достаточно обычного SQL-запроса на присоединение, о чем будет рассказано в главе 11. (Правда, вам все равно придется заниматься устранением временного сдвига.)

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

В завершение работы надо привести базу данных в привычный вид. Ограничения на длину имени поля практически отсутствуют, поэтому дайте всем полям в файлах русскоязычные названия. Вы уже начали делать это немного раньше – в разделе «Поля даты и времени» – с помощью поля Имя поля конструктора таблиц. В своем заключительном варианте таблица Fiie1 представлена на рис. 7.11, а окно базы данных – на рис. 7.12.

Рис. 7.12