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

Вид материала

Диплом

Содержание 1.6. Преобразование реляционных нормализованных таблиц в файлы БД 1.7. Вопросы преобразования электронных таблиц

Подобный материал:

• Учебное пособие Допущено Министерством образования Российской Федерации в качестве, 2582.59kb.
• Д. В. Андреев Программирование микроконтроллеров mcs-51, 2064.3kb.
• И. В. Борискина, А. А. Плотников, А. В. Захаров проектирование современных оконных, 1699.55kb.
• «История нового времени», 4001.1kb.
• Учебное пособие. 3-е изд., испр и доп, 125.38kb.
• М. В. Ломоносова Хрестоматия по истории государства и права зарубежных стран, 11295.75kb.
• В. В. Крупица Личность Коллектив Стиль отношений (социально-психологический аспект), 4876.34kb.
• И. М. Синяева, В. М. Маслова, В. В. Синяев сфера, 5230.77kb.
• И. К. Корнеев информационная безопасность и защита информации учебное пособие, 7667.6kb.
• Курслекций допущено умо по образованию в области социальной работы в качестве учебного, 2178.14kb.

1.6. Преобразование реляционных нормализованных таблиц в файлы БД

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

В частности, Microsoft Access позволяет импортировать данные, представленные в раз­личных форматах - в HTML, Microsoft Excel, текстовом формате и др. Это существенно уп­рощает решение проблемы преобразования таблиц в файлы БД.

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

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

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

В системе Oracle предусмотрено специализированное средство для перемеще­ния данных - SQL*Loader. В нем в процессе перемещения данных формируются файлы отвергнутых и некоррект­ных записей - записей, которые по каким-либо причинам не могут быть включены в БД. Это, с одной стороны, говорит о том, что проблема преобразования информации табличного вида в файлы БД актуальна (коль скоро ею занимается самая крупная в мире корпорация в области БД), а, с другой стороны, эта проблема не всегда имеет корректное решение.

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

1.7. Вопросы преобразования электронных таблиц

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

Преимущества баз данных (БД) по сравнению с ЭТ обсуждаются в ряде работ, в частности в [5,6]. В связи с этими преимуществами часто возникает необходимость перехода к БД от ЭТ. Ниже рассматриваются ситуации, когда такая необходимость возникает.

1. В процессе интенсивной работы с ЭТ создается множество таблиц, которые логически связаны между собой. В этом случае очень часто возникает необходимость анализа информации сразу из нескольких таблиц. В ЭТ такого рода манипуляции над данными чрезвычайно затруднительны, а в БД - естественны.
   
2. Очень часто в ЭТ, даже в составе одной книги, хранится несколько таблиц с одинаковыми столбцами. Это приводит к неэффективному использованию памяти компьютера. Установка связей между отдельными таблицами в БД позволяет избежать ненужного дублирования.
   
3. Объем информации, хранимой в ЭТ, в процессе работы с ЭТ может достигнуть значительных объемов. Это приводит к тому, что информация становится необозримой или ресурсы хранения информации достигают пределов возможностей систем, с помощью которых она обрабатываются. В БД гораздо проще, чем в ЭТ построить пользовательский интерфейс, ориентированный на эффективную работу с большими объемами информации. Кроме того, современные БД позволяют хранить и обрабатывать очень большие объемы данных – сотни гигабайтов или терабайтов данных.
   
4. Хранимая в таблицах информация нередко носит конфиденциальный характер. Кроме того, эта информация может не представлять интерес для определенных категорий пользователей. Организовать многоуровневую защиту от несанкционированного доступа в системах, ориентированных на работу с ЭТ, чрезвычайно сложно. В БД для этого предусмотрены специальные механизмы.
   
5. Для ЭТ зачастую необходимо обеспечить многопользовательский доступ. В соответствующих системах число пользователей ограничено несколькими десятками. В современных БД обеспечивается совместная работа тысяч пользователей.
   
6. С ростом объема хранимой информации все более актуальной становится проблема безопасности данных, их сохранности и возможности восстановления при утере. В СУБД в отличие от ЭТ детально продуманы вопросы сжатия и восстановления данных, их защита, резервное копирование.
   
7. При работе с ЭТ в ячейки одного и того же столбца можно ввести данные различных типов. Иногда это оправданно, а зачастую недопустимо (например, в случае ошибочного ввода данных). СУБД обеспечивает автоматическую проверку данных на соответствие заранее определенному типу. Более того, СУБД обеспечивает не только контроль вводимых типов данных, но и правильность самих данных. Для этого реализуется возможность описания правил проверки данных.
   

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

Как показывает опыт работы с реальными БД, нередко возникает необходимость сбора данных, представленных в различных форматах, и добавления их в существующую БД. Чаще всего данные, добавляемые в БД, представлены в формате ЭТ. Такая технология обработки данных на сегодня имеет широкое распространение и часто оправданна.

Даже если такая технология предусмотрена изначально и структура электронных таблиц полностью соответствует структуре таблиц БД, то все равно возникают проблемы преобразования ЭТ в таблицы БД.

Если БД и ЭТ создавались независимо друг от друга и структура электронных таблиц не соответствует структуре таблиц БД, то проблема преобразования усугубляется.

Таким образом, можно сделать вывод о том, что необходимость преобразования ЭТ в таблицы БД может возникнуть, как минимум, в двух случаях:

- когда системы управления ЭТ не удовлетворяют пользователей;

- когда возникает необходимость импорта ЭТ в существующую БД.

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

Во многих современных СУБД имеются средства импорта ЭТ в таблицы БД. Однако, в подавляющем большинстве случаев эти средства неприемлемы для формирования полноценных БД, удовлетворяющих современным требованиям. Они работают только тогда, когда ЭТ представлены реляционными таблицами. В общем случае, а, как правило, и в частностях, ЭТ не являются реляционными. Требования к реляционным таблицам широко освещены в специальной литературе, например в [2]. К числу основных причин несоответствия ЭТ реляционным таблицам можно отнести следующие причины:

- в заголовках столбцов ЭТ зачастую имеют место подзаголовки, что недопустимо в реляционных таблицах;

- типы данных, расположенных в одноименных столбцах очень часто не совпадают, что также недопустимо;

- ячейки в ЭТ могут быть пустыми, что неприемлемо в БД;

- внутри таблицы могут быть подзаголовки таблицы, что совершенно неприемлемо;

- в заголовках столбцов и в ячейках часто присутствуют недопустимые с точки зрения БД символы (например, точка);

- записи в ЭТ могут совпадать, а это неприемлемо в БД в большинстве случаев;

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

Невозможность использования таблицы в формате Microsoft Excel непосредственно в БД нетрудно видеть из реального примера, представленного на рис. 1.5.




Рис. 1.5. Пример таблицы в формате Microsoft Excel


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

Лучший результат, который можно получить после автоматизированного преобразования с помощью средств импорта БД системы Microsoft Access, представлен на рис. 1.6.




Рис.1.6. Результат импорта таблицы в формате Microsoft Excel в формат БД Microsoft Access


Несмотря на то, что Microsoft Access очень хорошо сочетается с Microsoft Excel (как разработки одной корпорации), результаты преобразования не могут быть использованы без дополнительных модификаций структуры таблицы и ее содержимого. В частности, заголовки таблицы необходимо исправлять, типы двух последних (на рисунке) столбцов менять, значения отдельных столбцов корректировать. Учитывая то, что в данной таблице более 50-и полей и около 1000 строк выполнение названных манипуляций трудоемко. Анализируя содержимое таблицы, нетрудно сделать вывод о том, что она избыточна. В частности, в столбцах “Поле1”, ”Город”, ”Продавец”, ”Сегмент”, ”Тип оборудования” имеет место дублирование значений. Кроме того, в процессе импорта сформировалась таблица с ошибками импорта, которую разработчику БД необходимо проанализировать и принять решение по модификации соответствующих записей.

Выполним попытку преобразования подобной таблицы (рис. 1.7) в формат Microsoft SQL Server.



Рис. 1.7. Пример таблицы в формате Microsoft Excel


В результате выполнения всех действий, необходимых для выполнения импорта в формат Microsoft SQL Server, будет сформирована таблица, представленная на рис. 1.8.




Рис.1.8. Результат импорта таблицы в формате Microsoft Excel в формат БД Microsoft SQL Server


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

Опыт импорта реальных ЭТ в БД показывает, что это далеко не полный перечень несоответствий ЭТ требованиям к реляционным таблицам.

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

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

Суммируя сказанное, можно сделать вывод о том, что преобразовывать ЭТ нужно, как минимум, по следующим причинам:

- ЭТ в общем случае не являются реляционными;

- ЭТ, как правило, не подготовлены для наведения связей между ними;

- в ЭТ затруднен одновременный доступ к данным расположенных в различных таблицах;

- ЭТ не обладает преимуществами БД.

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

На сегодня сложилась методика проектирования реляционных БД, которая освещена в источниках по проектированию БД [1,2]. Следуя ей, разработчик может выполнить этапы проектирования от постановки задачи, инфологического и датологического проектирования до физической реализации и создать высокоэффективную БД, удовлетворяющую современным требованиям. Опять же, следуя методике, разработчик может в рамках всех этапов проектирования грамотно построить реляционные таблицы, удовлетворяющие всем нормальным формам. Рекомендации по проектированию БД помогают разработчику назначить ключевые и индексные поля, сформировать связи между таблицами, обеспечить безопасность данных и выполнить много полезных мероприятий, ориентированных на разработку высококачественного программного продукта. Другими словами, сегодня разработчик БД вооружен мощной теорией построения БД и множеством инструментальных средств, ориентированных на построение БД различного назначения в рамках этой теории. В связи с этим возникает вопрос - насколько применима существующая теория и инструментальные средства для преобразования ЭТ в таблицы БД.

Вся проблема в том, что в рассматриваемом случае данные уже есть, таблицы сформированы, и, конечно, при их создании никто не руководствовался теоретическими аспектами построения БД. Чаще всего эти аспекты при создании электронных таблиц неактуальны, их разработчик решал другие задачи. Таким образом, при построении ЭТ выпадают все этапы проектирования БД. Выполнить же положения, характерные для этапов построения БД в процессе преобразования ЭТ к БД, о которых идет речь, не представляется возможным. Если их выполнять, необходимо спроектировать новую БД, а затем вручную перенести данные из ЭТ в таблицы БД. Это, может быть, и оправданно, если данных немного. Здесь же речь идет о ситуации, при которой в ЭТ накоплены значительные объемы информации. Желательно процесс преобразования сделать автоматизированным, а лучше автоматическим. Таким образом, теоретические положения поэтапной разработки баз данных в рассматриваемом случае неприемлемы – приходится исходить из таких представлений ЭТ, которые уже сформированы.

Могут ли быть полезными другие положения теории построения реляционных БД для разработки математических и программных средств, ориентированных на преобразование ЭТ в таблицы БД? Вероятнее всего, да. Требования к реляционным таблицам четко сформулированы, и можно описать целевые функции, позволяющие осуществить автоматизированное преобразование существующих ЭТ к реляционным таблицам. Условия нормализации таблиц формализованы и представляется возможным формализовать процесс нормализации одной или совокупности заполненных реляционных таблиц. Кстати, некоторые средства автоматизированной нормализации таблиц на основе анализа содержащихся в них данных уже существуют, в частности в Microsoft Access. Рекомендации к ключевым и индексным полям имеют место и их можно использовать для автоматизированного назначения соответствующих полей.

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

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