Автоматизированные банки данных уже давно стали неотъемлемой частью практически всех компьютерных систем управления на любом уровне – от отрасли до отдельного предприятия.
Однако проектирование и создание баз данных (БД) до сих пор остается, за редким исключением, не технической задачей, а творческим процессом, который скорее сродни искусству, нежели науке. Это утверждение может показаться несколько странным, поскольку разработка и исследование баз данных ведутся более 35 лет. Однако, как нам кажется, такой парадокс вполне объясним. За прошедшие годы неизмеримо вырос уровень потребительских качеств систем управления базами данных (СУБД): разнообразие поддерживаемых функций, удобный для пользователя интерфейс, сопряжение с программными продуктами, в частности с другими СУБД, возможности для работы в сети и т. д.
Но изменения почти не коснулись того, что раньше называлось логическими структурами баз данных. Это формы, в которых пользователь представляет и хранит свою информацию в БД. А ведь именно от них в немалой степени зависит удобство работы пользователя с базой данных: формулировка запроса, простота поиска данных, форма выдачи итоговой информации и другие операции. В современных БД могут использоваться более или менее удачные структуры, но почти никогда мы не найдем обоснованного ответа на вопрос, почему для конкретной базы данных была выбрана именно такая форма.
Однако к настоящему времени накоплен значительный опыт проектирования банков данных, предназначенных для управления производством. Это позволяет сделать процесс создания БД значительно более формализованным. (Правда, поле для субъективных решений, а значит, и для индивидуального творчества все равно остается, но его можно существенно сузить.)
Итак, речь идет об информации, которая формируется и накапливается в компьютерных банках данных. В условиях реальной производственной деятельности это понятие употребляется в двух различных значениях:
• информация, прежде хранившаяся на бумажных носителях и внесенная в новый банк данных, который создавался на основе какой-либо СУБД. Сюда же следует отнести и сведения, связанные с текущим производственным процессом. Они вводятся в банк данных в реальном масштабе времени;
• банк данных, который был создан ранее и используется до сих пор.
Постепенно разница между двумя названными типами данных стирается. С одной стороны, неизбежно появляется новая информация, которую надо структурировать и организовать в банке данных, и создаются новые СУБД, более удобные, чем прежние. С другой стороны, ранее накопленные сведения продолжают храниться в банке данных, который наверняка никто никогда не будет перестраивать. Обычно самое простое решение проблемы – конвертировать старые данные в новую СУБД, объединяя информационные массивы и решая возникающие при этом проблемы. В результате возникает новый банк данных, куда входят разные БД[1]. Все они имеют один формат данных (например, для Access – это. mdb), но сохраняют прежнюю структуру первичных файлов, таблиц и т. д. Иными словами, данные остаются в значительной мере разнородными, что осложняет дальнейшую работу с ними.
Поэтому после конвертации или интеграции разнородных баз данных в единую программную среду пользователю потребуется дополнительное (иногда специальное) программное обеспечение, чтобы обслуживать полученную БД.
До сих пор в специальной литературе рассматривалась только одна сторона задачи – создание новых баз данных. О том, как конвертировать собранную информацию в программную среду новой СУБД, написано значительно меньше. Наконец, мало внимания уделялось другой важной проблеме: какой должна быть единая программная среда и почему.