ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 29.04.2024
Просмотров: 11
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
улучшая интерфейс и быстродействие систем, снижая их стоимость. Наличие на рынке большого числа СУБД, исполняющих похожие функции, потребовало разработки методов экспорта - импорта данных для этих систем и открытия форматов сохранения данных.
Но и в этот период появились любители, которые, вопреки здравому смыслу, разрабатывали собственные СУБД на стандартных языках программирования. Это тупиковый путь, так как последующие разработки показали, что перенос данных из нестандартных форматов в новые СУБД будет намного сложнее и в некоторых случаях требует таких трудозатрат, как было бы проще это сделать. все с нуля, но данные все равно пришлось мигрировать на новую, более перспективную СУБД. И это тоже результат недооценки функций, которые должна выполнять СУБД.
Особенности этого этапа следующие:
· Все СУБД рассчитаны на создание БД в основном с монопольным доступом. И это понятно. Персональный компьютер, он не был подсоединен к сети, и база данных на нем создавалась для работы одного пользователя. В редких случаях предполагалась последовательная работа нескольких пользователей, например, первоначально оператор, который вводил бухгалтерские документы, а позже главбух, который определял проводки, соответствующие первичным документам.
· Большинство СУБД имели развитый и удобный пользовательский интерфейс. В большинстве существовал интерактивный режим работы с БД как в рамках описания БД, так и в рамках проектирования запросов. Кроме того, большинство СУБД предлагали развитый и удобный инструментарий для разработки готовых приложений без программирования. Инструментальная среда состояла из готовых элементов приложения в виде шаблонов экранных форм, отчетов, этикеток (Labels), графических конструкторов запросов, которые достаточно просто могли быть собраны в единый комплекс.
· Во всех настольных СУБД поддерживался только внешний уровень представления реляционной модели, то есть только внешний табличный вид структур данных.
· При наличии высокоуровневых языков манипулирования данными типа реляционной алгебры и SQL в настольных СУБД поддерживались низкоуровневые языки манипулирования данными на уровне отдельных строк таблиц.
· в настольных СУБД отсутствовали средства поддержки ссылочной и структурной целостности базы данных. Эти функции должны были выполнять приложения, однако скудость средств разработки приложений иногда не позволяла это сделать, и в этом случае эти функции должны были выполняться пользователем, требуя от него дополнительного контроля при вводе и изменении информации, хранящейся в БД.
· Наличие монопольного режима работы фактически привело к вырождению функций администрирования БД и в связи с этим - к отсутствию инструментальных средств администрирования БД.
· И, наконец, последняя и в настоящий момент весьма положительная особенность - это сравнительно скромные требования к аппаратному обеспечению со стороны настольных СУБД. Вполне работоспособные приложения, разработанные, например, на Clipper, работали на PC 286.
· В принципе, их даже трудно назвать полноценными СУБД. Яркие представители этого семейства - очень широко использовавшиеся до недавнего времени СУБД Dbase (DbaseIII+, DbaselV), FoxPro, Clipper, Paradox.
1.3. Распределенные многопользовательские базы данных
Всем известно, что история развития идет по спирали, поэтому после процесса «персонализации» начался обратный процесс интеграции. Количество локальных сетей увеличивается, все больше информации передается между компьютерами, остро встает проблема непротиворечивости данных, хранящихся и обрабатываемых в разных местах, но логически друг с другом связанных, возникают задачи, связанные с параллельной обработкой транзакций - последовательностей операций над БД, переводящих ее из одного непротиворечивого состояния в другое непротиворечивое состояние. Удачное решение этих задач приводит к образованию распределенных многопользовательских баз данных, сохраняющих все преимущества настольных СУБД и в то же время позволяющих организовать параллельную обработку информации и поддержку целостности БД.
Особенности данного этапа:
- Практически все современные СУБД дают поддержку полной реляционной модели, а именно:
- структурной целостности - допустимыми являются только данные, представленные в виде отношений реляционной модели;
- языковой целостности, то есть языков манипулирования данными высокого уровня (в основном SQL);
- ссылочной целостности, контроля за соблюдением ссылочной целостности в течение всего времени функционирования системы, и гарантий невозможности со стороны СУБД нарушить эти ограничения.
- Большинство современных СУБД рассчитаны на многоплатформенную архитектуру, то есть они могут работать на компьютерах с разной архитектурой и под разными операционными системами, при этом для пользователей доступ к данным, управляемым СУБД на разных платформах, практически неразличим.
- Необходимость поддержки работы нескольких пользователей с базами данных и возможности децентрализованного хранения данных вызывает необходимость разработки средств администрирования баз данных с реализацией общей концепции средств защиты данных.
- Потребность в новых реализациях привела к возникновению серьезных теоретических работ по оптимизации реализаций распределенных многопользовательских баз данных и работе с распределенными запросами и транзакциями с результатами реализации, полученными в коммерческих СУБД.
- Чтобы не терять клиентов, ранее работавших на десктопных СУБД, почти все современные СУБД имеют средства для подключения клиентских приложений, разработанных с использованием СУБД, на десктоп и средства для экспорта данных из форматов СУБД на десктоп второго этапа разработки.
Именно на этом этапе было разработано несколько стандартов в контексте языков манипулирования данными и описания, начиная с SQL89, SQL92, SQL99, и технологий обмена данными между различными СУБД, включая протокол ODBC (Open DataBase Connectivity), предусмотренный от Майкрософта.
- Именно к этому этапу можно отнести начало работ, связанных с концепцией объектно-ориентированных БД - ООБД. Представителями СУБД, относящимся ко второму этапу, можно считать MS Access и все современные серверы баз данныхOracle7.3, Oracle 8.4, MS SQL-Server 6.5, MS SQL-Server 7.0, System 10, System 11, Informix, DB2, Progress, SQLBase и другие современные серверы баз данных, которых в настоящий момент насчитывается несколько десятков.
Глава 2. Теоретические сведения
2.1. Общие положения
База данных (БД) – это совокупность документов, систематизированных таким образом, чтобы их можно было легко найти и обработать с помощью ПК или другого компьютера (ЭВМ). Под документацией можно понимать все: статьи, различные документы, отчеты и т.д.
Модели баз данных основаны на современном подходе к обработке информации. Информационная структура базы данных позволяет создавать логические записи об элементах и их отношениях. Отношения могут быть «один к одному», «один ко многим» и «многие ко многим».
Применение того или иного типа взаимосвязи определены тремя моделями базы данных:
- иерархической
- сетевой
- реляционной
Иерархическая модель данных — это модель данных, где используется представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.
Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка, к потомку, при этом возможна ситуация, когда объект-предок не имеет потомков или имеет их несколько, тогда как у объекта-потомка обязательно только один предок. Объекты, имеющие общего предка, называются близнецами.
Достоинства:
- эффективное использование памяти
- неплохие временные характеристики выполнения операций над данными
Недостатки:
- сложные логические связи
- громоздкость в обработке данных
Сетевая модель данных - это логическая модель данных, представляющая их сетевыми структурами типов записей и связанные отношениями мощности один-к-одному или один-ко-многим.
В отличие от реляционной модели, содержащиеся в ней отношения моделируются наборами, которые реализуются с помощью указателей. Сетевая модель данных — это расширенная версия иерархической модели, но основное отличие состоит в том, что сетевая модель данных имеет двунаправленные указатели, соединяющие связанную информацию.
Достоинства:
- высокая эффективность затрат памяти
- оперативность обработки данных
Недостатки:
- сложность и жёсткость схемы базы
- сложность понимания
- ослаблен контроль целостности, так как в ней разрешено устанавливать различные связи между записями
В реляционной базе данных вся информация отображается в виде таблицы, а все операции с данными являются табличными операциями. Таблицы состоят из строк и столбцов. Строки представляют собой записи, а столбцы показывают структуру записи (каждый столбец имеет определенный тип данных и длину данных). Строки таблицы неупорядоченно - у них нет первой или десятой строки. Однако, поскольку на строки нужно каким-то образом ссылаться, было сформировано понятие «первичный ключ».
Достоинства:
- простота моделирования и физическая реализация
- высокая эффективность обработки данных
Недостатки:
- отсутствие стандартных средств идентификации каждой отдельной записи
Проектирование базы данных (БД) – одна из наиболее непростых и ответственных задач, связанных с созданием информационной системы (ИС). В результате её решения должны быть поставлены содержание БД, лучший для всех её будущих пользователей способ организации данных и инструментальные средства управления данными.
Главная цель процесса проектирования БД состоит в получении такого проекта, который удовлетворяет следующим требованиям:
- корректность схемы БД, т. е. база должна быть гомоморфным образом моделируемой предметной области (ПО), где каждому объекту предметной области соответствуют данные в памяти ЭВМ, а каждому процессу – адекватные процедуры обработки данных;
- обеспечение ограничений ;
- эффективность функционирования ;
- защита данных (от аппаратных и программных сбоев
и несанкционированного доступа);
- простота и удобство эксплуатации;
-гибкость, т. е. возможность развития и адаптации к
изменениям предметной области и/или требований пользователей
2.2. Этапы проектирования базы данных
Процесс проектирования включает в себя следующие этапы.
Концептуальное проектирование – это конструирования информативноймодели, не зависящей от каких-либо физических условий реализации.
Логическое проектирование – это конструирования информационной модели на основе существующих моделей данных, не зависимо от используемой СУБД и других условий физической
Физическое проектирование – это процедура создания описания конкретной реализации БД с описанием структуры хранения данных, методов доступа к данным.
Концептуальный дизайн (информатика) строит семантическую модель предметной области, то есть информационную модель на высшем уровне абстракции. Такая модель создается без ориентации на конкретную СУБД или модель данных. Термины "семантическая модель", "концептуальная модель" и "инфологическая модель" являются синонимами. Кроме того, в этом контексте одинаково могут использоваться слова "модель базы данных" и "модель предметной области" (например, "концептуальная модель базы данных" и "концептуальная модель предметной области"), потому что эта модель является одновременно образом реальности и образ базы данных дизайна для этой реальности.
Определенный вид и содержание концептуальной модели базы данных определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграммам.
Больше всего концептуальная модель базы данных содержит в себе:
· описание информационных объектов или понятий предметной области и связей между ними.
· описание ограничений целостности, т. требований к допустимым значениям данных и к связям между ними.
Логическое (даталогическое) проектирование - создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель - набор схем отношений, обычно с указанием первичных ключей, а также "связей" между отношениями, представляющих собой внешние ключи.
Но и в этот период появились любители, которые, вопреки здравому смыслу, разрабатывали собственные СУБД на стандартных языках программирования. Это тупиковый путь, так как последующие разработки показали, что перенос данных из нестандартных форматов в новые СУБД будет намного сложнее и в некоторых случаях требует таких трудозатрат, как было бы проще это сделать. все с нуля, но данные все равно пришлось мигрировать на новую, более перспективную СУБД. И это тоже результат недооценки функций, которые должна выполнять СУБД.
Особенности этого этапа следующие:
· Все СУБД рассчитаны на создание БД в основном с монопольным доступом. И это понятно. Персональный компьютер, он не был подсоединен к сети, и база данных на нем создавалась для работы одного пользователя. В редких случаях предполагалась последовательная работа нескольких пользователей, например, первоначально оператор, который вводил бухгалтерские документы, а позже главбух, который определял проводки, соответствующие первичным документам.
· Большинство СУБД имели развитый и удобный пользовательский интерфейс. В большинстве существовал интерактивный режим работы с БД как в рамках описания БД, так и в рамках проектирования запросов. Кроме того, большинство СУБД предлагали развитый и удобный инструментарий для разработки готовых приложений без программирования. Инструментальная среда состояла из готовых элементов приложения в виде шаблонов экранных форм, отчетов, этикеток (Labels), графических конструкторов запросов, которые достаточно просто могли быть собраны в единый комплекс.
· Во всех настольных СУБД поддерживался только внешний уровень представления реляционной модели, то есть только внешний табличный вид структур данных.
· При наличии высокоуровневых языков манипулирования данными типа реляционной алгебры и SQL в настольных СУБД поддерживались низкоуровневые языки манипулирования данными на уровне отдельных строк таблиц.
· в настольных СУБД отсутствовали средства поддержки ссылочной и структурной целостности базы данных. Эти функции должны были выполнять приложения, однако скудость средств разработки приложений иногда не позволяла это сделать, и в этом случае эти функции должны были выполняться пользователем, требуя от него дополнительного контроля при вводе и изменении информации, хранящейся в БД.
· Наличие монопольного режима работы фактически привело к вырождению функций администрирования БД и в связи с этим - к отсутствию инструментальных средств администрирования БД.
· И, наконец, последняя и в настоящий момент весьма положительная особенность - это сравнительно скромные требования к аппаратному обеспечению со стороны настольных СУБД. Вполне работоспособные приложения, разработанные, например, на Clipper, работали на PC 286.
· В принципе, их даже трудно назвать полноценными СУБД. Яркие представители этого семейства - очень широко использовавшиеся до недавнего времени СУБД Dbase (DbaseIII+, DbaselV), FoxPro, Clipper, Paradox.
1.3. Распределенные многопользовательские базы данных
Всем известно, что история развития идет по спирали, поэтому после процесса «персонализации» начался обратный процесс интеграции. Количество локальных сетей увеличивается, все больше информации передается между компьютерами, остро встает проблема непротиворечивости данных, хранящихся и обрабатываемых в разных местах, но логически друг с другом связанных, возникают задачи, связанные с параллельной обработкой транзакций - последовательностей операций над БД, переводящих ее из одного непротиворечивого состояния в другое непротиворечивое состояние. Удачное решение этих задач приводит к образованию распределенных многопользовательских баз данных, сохраняющих все преимущества настольных СУБД и в то же время позволяющих организовать параллельную обработку информации и поддержку целостности БД.
Особенности данного этапа:
- Практически все современные СУБД дают поддержку полной реляционной модели, а именно:
- структурной целостности - допустимыми являются только данные, представленные в виде отношений реляционной модели;
- языковой целостности, то есть языков манипулирования данными высокого уровня (в основном SQL);
- ссылочной целостности, контроля за соблюдением ссылочной целостности в течение всего времени функционирования системы, и гарантий невозможности со стороны СУБД нарушить эти ограничения.
- Большинство современных СУБД рассчитаны на многоплатформенную архитектуру, то есть они могут работать на компьютерах с разной архитектурой и под разными операционными системами, при этом для пользователей доступ к данным, управляемым СУБД на разных платформах, практически неразличим.
- Необходимость поддержки работы нескольких пользователей с базами данных и возможности децентрализованного хранения данных вызывает необходимость разработки средств администрирования баз данных с реализацией общей концепции средств защиты данных.
- Потребность в новых реализациях привела к возникновению серьезных теоретических работ по оптимизации реализаций распределенных многопользовательских баз данных и работе с распределенными запросами и транзакциями с результатами реализации, полученными в коммерческих СУБД.
- Чтобы не терять клиентов, ранее работавших на десктопных СУБД, почти все современные СУБД имеют средства для подключения клиентских приложений, разработанных с использованием СУБД, на десктоп и средства для экспорта данных из форматов СУБД на десктоп второго этапа разработки.
Именно на этом этапе было разработано несколько стандартов в контексте языков манипулирования данными и описания, начиная с SQL89, SQL92, SQL99, и технологий обмена данными между различными СУБД, включая протокол ODBC (Open DataBase Connectivity), предусмотренный от Майкрософта.
- Именно к этому этапу можно отнести начало работ, связанных с концепцией объектно-ориентированных БД - ООБД. Представителями СУБД, относящимся ко второму этапу, можно считать MS Access и все современные серверы баз данныхOracle7.3, Oracle 8.4, MS SQL-Server 6.5, MS SQL-Server 7.0, System 10, System 11, Informix, DB2, Progress, SQLBase и другие современные серверы баз данных, которых в настоящий момент насчитывается несколько десятков.
Глава 2. Теоретические сведения
2.1. Общие положения
База данных (БД) – это совокупность документов, систематизированных таким образом, чтобы их можно было легко найти и обработать с помощью ПК или другого компьютера (ЭВМ). Под документацией можно понимать все: статьи, различные документы, отчеты и т.д.
Модели баз данных основаны на современном подходе к обработке информации. Информационная структура базы данных позволяет создавать логические записи об элементах и их отношениях. Отношения могут быть «один к одному», «один ко многим» и «многие ко многим».
Применение того или иного типа взаимосвязи определены тремя моделями базы данных:
- иерархической
- сетевой
- реляционной
Иерархическая модель данных — это модель данных, где используется представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.
Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка, к потомку, при этом возможна ситуация, когда объект-предок не имеет потомков или имеет их несколько, тогда как у объекта-потомка обязательно только один предок. Объекты, имеющие общего предка, называются близнецами.
Достоинства:
- эффективное использование памяти
- неплохие временные характеристики выполнения операций над данными
Недостатки:
- сложные логические связи
- громоздкость в обработке данных
Сетевая модель данных - это логическая модель данных, представляющая их сетевыми структурами типов записей и связанные отношениями мощности один-к-одному или один-ко-многим.
В отличие от реляционной модели, содержащиеся в ней отношения моделируются наборами, которые реализуются с помощью указателей. Сетевая модель данных — это расширенная версия иерархической модели, но основное отличие состоит в том, что сетевая модель данных имеет двунаправленные указатели, соединяющие связанную информацию.
Достоинства:
- высокая эффективность затрат памяти
- оперативность обработки данных
Недостатки:
- сложность и жёсткость схемы базы
- сложность понимания
- ослаблен контроль целостности, так как в ней разрешено устанавливать различные связи между записями
В реляционной базе данных вся информация отображается в виде таблицы, а все операции с данными являются табличными операциями. Таблицы состоят из строк и столбцов. Строки представляют собой записи, а столбцы показывают структуру записи (каждый столбец имеет определенный тип данных и длину данных). Строки таблицы неупорядоченно - у них нет первой или десятой строки. Однако, поскольку на строки нужно каким-то образом ссылаться, было сформировано понятие «первичный ключ».
Достоинства:
- простота моделирования и физическая реализация
- высокая эффективность обработки данных
Недостатки:
- отсутствие стандартных средств идентификации каждой отдельной записи
Проектирование базы данных (БД) – одна из наиболее непростых и ответственных задач, связанных с созданием информационной системы (ИС). В результате её решения должны быть поставлены содержание БД, лучший для всех её будущих пользователей способ организации данных и инструментальные средства управления данными.
Главная цель процесса проектирования БД состоит в получении такого проекта, который удовлетворяет следующим требованиям:
- корректность схемы БД, т. е. база должна быть гомоморфным образом моделируемой предметной области (ПО), где каждому объекту предметной области соответствуют данные в памяти ЭВМ, а каждому процессу – адекватные процедуры обработки данных;
- обеспечение ограничений ;
- эффективность функционирования ;
- защита данных (от аппаратных и программных сбоев
и несанкционированного доступа);
- простота и удобство эксплуатации;
-гибкость, т. е. возможность развития и адаптации к
изменениям предметной области и/или требований пользователей
2.2. Этапы проектирования базы данных
Процесс проектирования включает в себя следующие этапы.
Концептуальное проектирование – это конструирования информативноймодели, не зависящей от каких-либо физических условий реализации.
Логическое проектирование – это конструирования информационной модели на основе существующих моделей данных, не зависимо от используемой СУБД и других условий физической
Физическое проектирование – это процедура создания описания конкретной реализации БД с описанием структуры хранения данных, методов доступа к данным.
Концептуальный дизайн (информатика) строит семантическую модель предметной области, то есть информационную модель на высшем уровне абстракции. Такая модель создается без ориентации на конкретную СУБД или модель данных. Термины "семантическая модель", "концептуальная модель" и "инфологическая модель" являются синонимами. Кроме того, в этом контексте одинаково могут использоваться слова "модель базы данных" и "модель предметной области" (например, "концептуальная модель базы данных" и "концептуальная модель предметной области"), потому что эта модель является одновременно образом реальности и образ базы данных дизайна для этой реальности.
Определенный вид и содержание концептуальной модели базы данных определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграммам.
Больше всего концептуальная модель базы данных содержит в себе:
· описание информационных объектов или понятий предметной области и связей между ними.
· описание ограничений целостности, т. требований к допустимым значениям данных и к связям между ними.
Логическое (даталогическое) проектирование - создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель - набор схем отношений, обычно с указанием первичных ключей, а также "связей" между отношениями, представляющих собой внешние ключи.
