Классификация бд по характеру хранимой информации. Классификация и характеристика баз данных Бд по характеру хранимой информации 16 букв

16.12.2023

1. Понятие базы данных База данных (БД) – это совокупность массивов и файлов данных, организованная по определённым правилам, предусматривающим стандартные принципы описания, хранения и обработки данных независимо от их вида. База данных (БД) – совокупность организованной информации, относящейся к определённой предметной области, предназначенная для длительного хранения во внешней памяти компьютера и постоянного применения.

По типу используемой модели данных выделяют три классических класса БД :

иерархические,

сетевые,

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

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

Типология баз данных с точки зрения информационных процессов

С другой стороны, БД могут соотноситься с различными уровнями информационных процессов:

уровень информационных технологий (ИТ),

уровень системы (ИС),

уровень информационных ресурсов (ИР).

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

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

При рассмотрении на уровне информационных ресурсов БД трактуется как элемент мировых ИР. Основной характеристикой здесь является содержание БД , хотя и структуры данных также немаловажны.

Классификация по модели данных

Иерархическая

Сетевая

Реляционная

Объектная и объектно-ориентированная

Объектно-реляционная

Функциональная .

Классификация по среде постоянного хранения

Во вторичной памяти, или традиционная (англ. conventional database ): средой постоянного хранения является периферийная энергонезависимая память (вторичная память) - как правило жёсткий диск . В оперативную память СУБД помещает лишь кеш и данные для текущей обработки.

В оперативной памяти (англ. in-memory database, memory-resident database, main memory database ): все данные на стадии исполнения находятся в оперативной памяти .

В третичной памяти (англ. tertiary database ): средой постоянного хранения является отсоединяемое от сервера устройство массового хранения (третичная память), как правило на основе магнитных лент или оптических дисков . Во вторичной памяти сервера хранится лишь каталог данных третичной памяти, файловый кеш и данные для текущей обработки; загрузка же самих данных требует специальной процедуры.

Классификация по содержимому

Географическая

Историческая

Мультимедийная.

Классификация по степени распределённости

Централизованная, или сосредоточенная (англ. centralized database ): БД, полностью поддерживаемая на одном компьютере.

Распределённая (англ. distributed database ): БД, составные части которой размещаются в различных узлах компьютерной сети в соответствии с каким-либо критерием.

Неоднородная (англ. heterogeneous distributed database ): фрагменты распределённой БД в разных узлах сети поддерживаются средствами более одной СУБД
Однородная (англ. homogeneous distributed database ): фрагменты распределённой БД в разных узлах сети поддерживаются средствами одной и той же СУБД.
Фрагментированная, или секционированная (англ. partitioned database ): методом распределения данных является фрагментирование (партиционирование, секционирование ), вертикальное или горизонтальное.
Тиражированная (англ. replicated database ): методом распределения данных является тиражирование (репликация ).

Другие виды БД

Пространственная (англ. spatial database ): БД, в которой поддерживаются пространственные свойства сущностей предметной области. Такие БД широко используются в геоинформационных системах .

Временная , или темпоральная (англ. temporal database ): БД, в которой поддерживается какой-либо аспект времени , не считая времени, определяемого пользователем.

Пространственно-временная (англ. spatial-temporal database ) БД: БД, в которой одновременно поддерживается одно или более измерений в аспектах как пространства, так и времени.

Циклическая (англ. round-robin database ): БД, объём хранимых данных которой не меняется со временем, поскольку в процессе сохранения данных одни и те же записи используются циклически.

СУБД имеет программные, технические и организационные составляющие.

Программные средства включают систему управления, обеспечивающую ввод-вывод, обработку и хранение информации, создание, модификацию и тестирование базы данных. Внутренними языками программирования СУБД являются языки четвертого поколения (C, C++, Pascal, Object Pascal). С помощью языков БД создаются приложения, базы данных и интерфейс пользователя, включающий экранные формы, меню, отчеты.

2. Систе́ма управле́ния ба́зами да́нных (СУБД) - совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных.

Классификации субд По модели данных

Иерархические

Реляционные
Объектно-ориентированные
Объектно-реляционные

По степени распределённости

Локальные СУБД (все части локальной СУБД размещаются на одном компьютере)

Распределённые СУБД (части СУБД могут размещаться на двух и более компьютерах).

По способу доступа к бд

Файл-серверные

В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера. Недостатки: потенциально высокая загрузка локальной сети; затруднённость или невозможность централизованного управления; затруднённость или невозможность обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность. Применяются чаще всего в локальных приложениях, которые используют функции управления БД; в системах с низкой интенсивностью обработки данных и низкими пиковыми нагрузками на БД.

На данный момент файл-серверная технология считается устаревшей.

Клиент-серверные

Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно. Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу. Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность.

Встраиваемые

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

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

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

Моделирование данных

Особенности архитектуры и функциональные возможности

Контроль работы системы

Особенности разработки приложений

Производительность

Надежность

Требования к рабочей среде

Смешанные критерии

3. Архитектура базы данных

Информация об определенной предметной области представлена в базе данных моделями нескольких уровней. По числу уровней в архитектуре различают одноуровневые, двухуровневые, трехуровневые системы. На различных уровнях архитектуры СУБД поддерживается разный уровень абстракции данных. В настоящее время наиболее распространенной является предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД. При проектировании баз данных выделяют три уровня: концептуальный, внутренний и внешний.

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

2. Концептуальный уровень - центральное управляющее звено. Здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически, концептуальный уровень отражает обобщенную логическую модель предметной области, для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов предметной области. Концептуальная модель является моделью логического уровня и не зависит от особенностей используемой СУБД. Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных.

3. Физический уровень - собственно данные, расположенные в файлах или в страничных структурах, расположенных на внешних носителях информации. Физическое представление БД относится к внутреннему уровню. Он описывает способы организации данных на внешних носителях информации (в виде файловых или страничных структур) и предназначен для достижения оптимальной производительности и эффективности использования ресурсов вычислительной системы. Описание физической структуры БД называется схемой хранения, а соответствующий этап проектирования БД – физическим проектированием.

Проектирование базы данных состоит из двух основных фаз: логического и физического моделирования. Во время фазы логического моделирования разработчик собирает требования к разрабатываемой БД, составляет описание предметной области и разрабатывает модель, не зависящую от конкретной СУБД. Во время фазы физического моделирования разработчик создает модель, оптимизированную для СУБД и конкретных приложений пользователей. В настоящее время внутренний уровень практически полностью обеспечивается СУБД. Основной акцент при проектировании БД переносится на создание модели концептуального уровня. Такая архитектура позволяет обеспечивать логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными.

Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных, и реорганизации механизма доступа к физическим данным.

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

Клиент-серверная информационная система состоит в простейшем случае из 2 основных компонентов:

1. Сервера баз данных, управляющего хранением данных, доступом и защитой, резервным копированием, отслеживающего целостность данных в соответствии с бизнес-правилами и, самое главное, выполняющего запросы клиента;

2. Клиента, предоставляющего другим клиентам интерфейс пользователя, выполняющий логику приложения, проверяющей допустимость данных, посылающий запросы к серверу и получающий ответы на него;

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

Клиент - это приложение пользователя. Его также называют приложением - клиентом.

Клиент и сервер взаимодействуют следующим образом:

1. Клиент формирует и посылает запросы (SQL-запросы) на чтение или изменения данных на сервер, на котором размещена БД. Эти запросы написаны на языке SQL.

2. Удалённый сервер сети направляет запрос программе SQL Server (серверу баз данных).

Достоинства архитектуры «клиент-сервер».

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

 Например, при необходимости выбора пяти записей из таблицы, содержащий миллион, клиентское приложение посылает серверу запрос, который сервером компилируется, оптимизируется и выполняется, после чего результат запроса (те самые 5 записей, а вовсе не вся таблица) передаётся обратно на рабочую станцию. При этом не редко в первом приближении можно не задумываться, а если вообще индекс, способный облегчить поиск нужной записи, если он есть, он будет использован сервером, если нет- запрос всё равно будет выполнен, хотя, скорее всего, в большее количество времени.

 Приложение не управляет напрямую базой, управлением занимается только сервер. Это приводит к повышение степени защиты информации.

 Уменьшение сложности клиентских приложений за счёт отсутствия в нём кода, связанного с контролем БД и разграничения доступа к ней.

Жизненный цикл базы данных.

Процесс проектирования, реализации и поддержания системы базы данных называется жизненным циклом базы данных (ЖЦБД). Процедура создания системы называется жизненным циклом системы (ЖЦС).

ЖЦБД состоит из следующих этапов:

1. Предварительное планирование – планирование БД, выполняемое в процессе разработки стратегического плана БД. В процессе планирования собирается следующая информация:

 какие прикладные программы используются, и какие функции они выполняют;

 какие файлы связаны с каждым из этих приложений;

 какие новые приложения и файлы находятся в процессе работы.

Данная информация помогает определить, как используется информация приложений, определить будущие требования к системе БД.

Информация этого этапа документируется в виде обобщенной модели данных.

2. Проверка осуществимости. Здесь определяется технологическая, операционная и экономическая осуществимость плана создания БД, т. е.:

 технологическая осуществимость – есть ли технология для реализации запланированной БД?

 операционная осуществимость – есть ли средства и эксперты, необходимые для успешного осуществления плана создания БД?

 экономическая целесообразность – можно ли определить выводы? Окупится ли запланированная система? Можно ли оценить издержки и выгоду?

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

 Определяются цели системы путём анализа информационных потребностей. Здесь также обязательно указывается, какую именно БД следует создавать (распределённую, целостную) и какие коммуникационные средства необходимы. Выходной документ – комментарий, описывающий цели системы.

 Определение пользовательских требований: документация в виде обобщённой информации (комментарии, отчёты, опросы, анкеты и т. д.); фиксация функций системы и определение прикладных систем, которые будут выполнять эти требования. Данные представляются в виде соответствующих документов.

 Определение общих требований к оборудованию и программному обеспечению, связанных с поддержанием желаемого уровня быстродействия. (Выяснение количества пользователей системы, числа входных сообщений в день, количество распечаток). Данная информация используется для выбора типов компьютеров и СУБД, объёма дисков, количества принтеров. Данные этого этапа излагаются в отчёте, содержащем примерные конфигурации оборудования и программного обеспечения.

 Разработка плана поэтапного создания системы, включающий выбор исходных приложений.

4. Концептуальное проектирование – создание концептуальной схемы БД. Спецификации разрабатываются в той степени, которая необходима для перехода к реализации.

Основным выходным документом является единая инфологическая модель (или схема БД на концептуальном уровне). При разработке данной модели используются информация и функции, которые должна выполнить система, определённые на этапе сбора и определения требований к системе. На данном этапе желательно также определить: 1) правила для данных; 2) правила для процессов; 3) правила для интерфейса.

5. Реализация – процесс превращения концептуальной модели в функциональную БД. Он включает в себя следующие этапы.

1) Выбор и приобретение необходимой СУБД.

2) Преобразование концептуальной (инфологической) модели БД в логическую и физическую модель данных:

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

 определяются, какие прикладные процессы необходимо реализовать в схеме данных как хранимые процедуры;

 реализовать ограничения, предназначенные для обеспечения целостности данных и реализации правил для данных;

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

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

 определить уровни доступа пользователей, разработать и внедрить правила обеспечения безопасности и аудита. Создать роли и синонимы для обеспечения многопользовательского доступа с согласованными уровнями полномочий доступа.

 разработать сетевую топологию БД и механизм бесшовного доступа к удалённым данным (реплицированная или распределённая БД).

3) Построение словаря данных, который определяет хранение определений структуры данных БД. Словарь данных также содержит информацию о полномочиях доступа, правилах защиты данных и контроля данных.

4) Заполнение базы данных.

5) Создание прикладных программ, контроль управления.

6) Обучение пользователей.

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

Таким образом, ЖЦБД включает в себя:

 Изучение предметной области и представление соответствующей документации (1-3).

 Построение инфологической модели (4).

 Реализация (5).

 Оценка работы и поддержка БД (6).

Этапы проектирования баз данных

При разработке БД можно выделить следующие этапы работы.

I этап. Постановка задачи.

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

II этап. Анализ объекта.

На этом этапе рассматривается, из каких объектов может состоять БД, каковы свойства этих объектов. После разбиения БД на отдельные объекты необходимо рассмотреть свойства каждого из этих объектов, или, другими словами, установить, какими параметрами описывается каждый объект. Все эти сведения можно располагать в виде отдельных записей и таблиц. Далее необходимо рассмотреть тип данных каждой отдельной единицы записи. Сведения о типах данных также следует занести в составляемую таблицу.

III этап. Синтез модели.

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

IV этап. Выбор способов представления информации и программного инструментария.

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

В большинстве СУБД данные можно хранить в двух видах:

с использованием форм;

без использования форм.

Форма – это созданный пользователем графический интерфейс для ввода данных в базу.

V этап. Синтез компьютерной модели объекта.

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

Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.

Стадия 2. Создание исходной таблицы или таблиц.

Создавая исходную таблицу, необходимо указать имя и тип каждого поля. Имена полей не должны повторяться внутри одной таблицы. В процессе работы с БД можно дополнять таблицу новыми полями. Созданную таблицу необходимо сохранить, дав ей имя, уникальное в пределах создаваемой базы.

1. Информация в таблице не должна дублироваться. Не должно быть повторений и между таблицами. Когда определенная информация хранится только в одной таблице, то и изменять ее придется только в одном месте. Это делает работу более эффективной, а также исключает возможность несовпадения информации в разных таблицах. Например, в одной таблице должны содержаться адреса и телефоны клиентов.

2. Каждая таблица должна содержать информацию только на одну тему. Сведения на каждую тему обрабатываются намного легче, если они содержатся в независимых друг от друга таблицах. Например, адреса и заказы клиентов лучше хранить в разных таблицах, с тем, чтобы при удалении заказа информация о клиенте осталась в базе данных.

3. Каждая таблица должна содержать необходимые поля. Каждое поле в таблице должно содержать отдельные сведения по теме таблицы. Например, в таблице с данными о клиенте могут содержаться поля с названием компании, адресом, городом, страной и номером телефона. При разработке полей для каждой таблицы необходимо помнить, что каждое поле должно быть связано с темой таблицы. Не рекомендуется включать в таблицу данные, которые являются результатом выражения. В таблице должна присутствовать вся необходимая информация. Информацию следует разбивать на наименьшие логические единицы (Например, поля "Имя" и "Фамилия", а не общее поле "Имя").

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

Стадия 3. Создание экранных форм.

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

Стадия 4. Заполнение БД.

Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE – в виде формы.

VI этап. Работа с созданной базой данных.

Работа с БД включает в себя следующие действия:

поиск необходимых сведений;

сортировка данных;

отбор данных;

вывод на печать;

изменение и дополнение данных.

Понимание и правильный подход к ЖЦБД очень важен и требует детального рассмотрения, так как в его основе лежит подход, ориентированный на данные. Элементы данных более стабильны, чем выполняемые функции системы. Создание правильной структуры данных требует сложного анализа классов единиц данных и отношений между ними. Если построить логичную схему базы данных, то в дальнейшем можно создать любое количество функциональных систем, использующих эту схему. Функционально-ориентированный подход можно применять лишь для создания временных систем, которые рассчитаны на недолгое время функционирования.

Концептуальное (инфологическое) проектирование

Концептуальное (инфологическое) проектирование - построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБДимодель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.

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

Чаще всего концептуальная модель базы данных включает в себя:

описание информационных объектов, или понятий предметной области и связей между ними.

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

Логическое (даталогическое) проектирование

Логическое (даталогическое) проектирование - создание схемы базы данныхна основе конкретноймодели данных, например,реляционной модели данных. Для реляционной модели данных даталогическая модель - набор схемотношений, обычно с указаниемпервичных ключей, а также «связей» между отношениями, представляющих собойвнешние ключи.

Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован.

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

Дисциплина: Информационные технологии в управлении

Тема: Классификация баз данных

Москва 2004 г.

ПЛАН

1. Классификация СУБД.

2. Функциональные возможности СУБД.

3. Модели описания баз данных.

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

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

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

Классификация СУБД:

По выполняемым функциям СУБД подразделяются на операционные и информационные;

По сфере применения СУБД подразделяются на универсальные и проблемно-ориентированные;

По используемому языку общения СУБД подразделяются на замкнутые, имеющие собственные самостоятельные языки общения пользователей с базами данных, и открытые, в которых для общения с базой данных используется язык программирования, расширенный операторами языка манипулирования данными;

По числу поддерживаемых уровней моделей данных СУБД подразделяются на одно-, двух-, трехуровневые системы;

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

По способу организации хранения данных и выполнения функций обработки базы данных подразделяются на централизованные и распределенные.

Системы централизованных баз данных с сетевым доступом предполагают две основные архитектуры – файл-сервер или клиент-сервер.

Архитектура файл-сервер. Предполагает выделение одной из машин сети в качестве центральной (главный сервер файлов), где хранится совместно используемая централизованная база данных. Все другие машины исполняют роль рабочих станций. Файлы базы данных в соответствии с пользовательскими запросами передаются на рабочие станции, где в основном и производится их обработка. При большой интенсивности доступа к одним и тем же данным производительность информационной системы падает.

Архитектура клиент-сервер. Эта модель взаимодействия компьютеров в сети для современных СУБД фактически стала стандартом. Каждый из подключенных к сети и составляющих эту архитектуру компьютеров играет свою роль: сервер владеет и распоряжается информационными ресурсами системы, клиент имеет возможность пользоваться ими. Помимо хранения централизованной базы данных сервер базы данных обеспечивает выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере. Извлеченные данные транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запроса SQL.

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

Характеристиками СУБД являются:

Производительность;

Обеспечение целостности данных на уровне баз данных;

Обеспечение безопасности данных;

Возможность работы в многопользовательских средах;

Возможность импорта и экспорта данных;

Обеспечение доступа к данным с помощью языка SQL;

Возможность составления запросов;

Наличие инструментальных средств разработки прикладных программ.

Производительность СУБД оценивается:

Временем выполнения запросов;

Скоростью поиска информации;

Временем импортирования баз данных из других форматов;

Скоростью выполнения операций (таких как обновление, вставка, удаление);

Временем генерации отчета и другими показателями.

Безопасность данных достигается:

Шифрованием прикладных программ;

Шифрованием данных;

Защитой данных паролем;

Ограничением доступа к базе данных (к таблице, к словарю и т.д.).

Обеспечение целостности данных подразумевает наличие средств, позволяющих удостовериться, что информация в базе данных всегда остается корректной и полной. Целостность данных должна обеспечиваться независимо от того, каким образом данные заносятся в память (в интерактивном режиме, посредством импорта или с помощью специальной программы). Используемые в настоящее время СУБД обладают средствами обеспечения целостности данных и надежной безопасности.

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

Наибольшее распространение в настоящее время получили системы управления базами данных Microsoft Access и Oracle.

Этапами работы в СУБД являются:

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

Ввод и редактирование данных в таблицах баз данных с помощью представляемой по умолчанию стандартной формы в виде таблицы и с помощью экранных форм, специально создаваемых пользователем;

Обработка данных, содержащихся в таблицах, на основе запросов и на основе программы;

Вывод информации из ЭВМ с использованием отчетов и без использования отчетов.

Реализуются названные этапы работы с помощью различных команд.

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

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

Известны три типа моделей описания баз данных – иерархическая, сетевая и реляционная, основное различие между которыми состоит в характере описания взаимосвязей и взаимодействия между объектами и атрибутами базы данных.

Иерархическая модель предполагает использование для описания базы данных древовидных структур, состоящих из определенного числа уровней. «Дерево» представляет собой иерархию элементов, называемых узлами. Под элементами понимается список, совокупность, набор атрибутов, элементов, описывающих объекты.

В качестве примера простой иерархической структуры можно привести административную структуру высшего учебного заведения, элементами которой являются: «Университет – Факультет – Группа». На каждом уровне иерархии данной структуры могут быть использованы различные атрибуты. Например, атрибутами третьего уровня могут быть: специализация группы, численный состав, фамилия старосты группы и другие.

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

Принципы иерархии:

Иерархия всегда начинается с корневой вершины (или главного узла);

Исходный узел, из которого строится дерево, называется корневым узлом или просто корнем, причем одно дерево может иметь только один корень;

Узел может содержать один или несколько атрибутов, описывающих находящийся в нем объект;

Порожденные узлы могут встраиваться в «дерево» как в горизонтальном направлении, так и в вертикальном;

Доступ к порожденным узлам возможен только через исходный узел, поэтому существует только один путь доступа к каждому узлу.

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

Сетевая модель описывает элементарные данные и отношения между ними в виде ориентированной сети. Это такие отношения между объектами, когда каждый порожденный элемент имеет более одного исходного и может быть связан с любым другим элементом структуры. Например, в структуре управления учебным заведением порожденный элемент «Студент» может иметь не один, а два исходных элемента: «Студент – Учебная группа», и «Студент – Комната в общежитии».

Сетевые структуры могут быть многоуровневыми и иметь разную степень сложности. Схема, в которой присутствует хотя бы одна связь «многие ко многим» и которая требует для своей реализации использования сложных методов, является сложной схемой.

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

Реляционная модель имеет в своей основе понятие «отношения», и ее данные формируются в виде таблиц. Отношение – это двумерная таблица, имеющая сове название, в которой минимальным объектом действий, сохраняющим ее структуру, является строка таблицы (кортеж), состоящая из ячеек таблицы – полей.

Каждый столбец таблицы соответствует только одной компоненте этого отношения. С логической точки зрения реляционная база данных представляется множеством двумерных таблиц различного предметного наполнения.

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

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

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

ЛИТЕРАТУРА

1. Веретенникова Е.И., Патрушина С.М., Савельева Н.Г. Информатика: Учебное пособие. Серия «Учебный курс». – Ростов н/Д: Издательский центр «МарТ», 2002.

2. Могилев А.В. Информатика: Учеб. пособие для студ. пед. вузов / А.В. Моглиев, Н.И. Пак, Е.К. Хеннер; Под ред. Е.К. Хеннера.- 2-е изд., стер. – М.: Издательский центр «Академия», 2003.

Репетиторство

Нужна помощь по изучению какой-либы темы?

Наши специалисты проконсультируют или окажут репетиторские услуги по интересующей вас тематике.
Отправь заявку с указанием темы прямо сейчас, чтобы узнать о возможности получения консультации.

Введение

Глава1. Основы баз данных

1.1.Классификация баз данных

1.3Модели описания баз данных

1.4. Основы работы настольных СУБД

1.5.Требования и стандарты, предъявляемые к базам данных

Глава 2. Работа с базой данных Microsoft Access

2.1. Основы работы настольной СУБД Microsoft Access

2.2. Работа с базой данных Microsoft Access

Заключение

Список использованной литературы

Введение

Потоки информации, циркулирующие в мире, который нас окружает, огромны. Во

времени они имеют тенденцию к увеличению. Поэтому в любой организации, как

большой, так и маленькой, возникает проблема такой организации управления

данными, которая обеспечила бы наиболее эффективную работу. Некоторые

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

компьютеризированные способы – базы данных, позволяющие эффективно хранить,

структурировать и систематизировать большие объемы данных. И уже сегодня без баз

данных невозможно представить работу большинства финансовых, промышленных,

торговых и прочих организаций. Не будь баз данных, они бы просто захлебнулись в

информационной лавине.

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

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

Для использования столь огромных объемов хранимой информации, помимо развития

системных устройств, средств передачи данных, памяти, необходимы средства

обеспечения диалога человек - ЭВМ, которые позволяют пользователю вводить

или принимать решения на основании хранимых данных. Для обеспечения этих функций

созданы специализированные средства – системы управления базами данных (СУБД).

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

1.1.Классификация баз данных

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

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

Классификация СУБД:

· по выполняемым функциям СУБД подразделяются на операционные и информационные;

· по сфере применения СУБД подразделяются на универсальные и проблемно-ориентированные;

· по используемому языку общения СУБД подразделяются на замкнутые, имеющие собственные самостоятельные языки общения пользователей с базами данных, и открытые, в которых для общения с базой данных используется язык программирования, расширенный операторами языка манипулирования данными;

· по числу поддерживаемых уровней моделей данных СУБД подразделяются на одно-, двух-, трехуровневые системы;

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

· по способу организации хранения данных и выполнения функций обработки базы данных подразделяются на централизованные и распределенные.

1.2. Функциональные возможности СУБД

Характеристиками СУБД являются:

· производительность;

· обеспечение целостности данных на уровне баз данных;

· обеспечение безопасности данных;

· возможность работы в многопользовательских средах;

· возможность импорта и экспорта данных;

· обеспечение доступа к данным с помощью языка SQL;

· возможность составления запросов;

· наличие инструментальных средств разработки прикладных программ.

Производительность СУБД оценивается:

· временем выполнения запросов;

· скоростью поиска информации;

· временем импортирования баз данных из других форматов;

· скоростью выполнения операций (таких как обновление, вставка, удаление);

· временем генерации отчета и другими показателями.

· Безопасность данных достигается:

· шифрованием прикладных программ;

· шифрованием данных;

· защитой данных паролем;

· ограничением доступа к базе данных (к таблице, к словарю и т.д.).

Наибольшее распространение в настоящее время получили системы управления базами данных Microsoft Access и Oracle.

Этапами работы в СУБД являются:

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

· ввод и редактирование данных в таблицах баз данных с помощью представляемой по умолчанию стандартной формы в виде таблицы и с помощью экранных форм, специально создаваемых пользователем;

· обработка данных, содержащихся в таблицах, на основе запросов и на основе программы;

· вывод информации из ЭВМ с использованием отчетов и без использования отчетов.

Реализуются названные этапы работы с помощью различных команд.

1.3.Модели описания баз данных

Принципы иерархии:

· иерархия всегда начинается с корневой вершины (или главного узла);

· исходный узел, из которого строится дерево, называется корневым узлом или просто корнем, причем одно дерево может иметь только один корень;

· узел может содержать один или несколько атрибутов, описывающих находящийся в нем объект;

· порожденные узлы могут встраиваться в «дерево» как в горизонтальном направлении, так и в вертикальном;

· доступ к порожденным узлам возможен только через исходный узел, поэтому существует только один путь доступа к каждому узлу.

Реляционная модель имеет в своей основе понятие «отношения», и ее данные формируются в виде таблиц. Отношение – это двумерная таблица, имеющая свое название, в которой минимальным объектом действий, сохраняющим ее структуру, является строка таблицы (кортеж), состоящая из ячеек таблицы – полей.

1.4. Настольные СУБД

Настольные СУБД отличаются тем, что используют в модель вычислений с сетью и файловым сервером (архитектура «файл-сервер»). Увеличение сложности задач, появление персональных компьютеров и локальных вычислительных сетей явилось предпосылками появления новой архитектуры «файл-сервер». Эта архитектура баз данных с сетевым доступом предполагает назначение одного из компьютеров сети в качестве выделенного сервера, на котором будут храниться файлы базы данных. В соответствие с запросами пользователей файлы с файл-сервера передаются на рабочие станции пользователей, где и осуществляется основная часть обработки данных. Центральный сервер выполняет в основном только роль хранилища файлов, не участвуя в обработке самих данных.

Работа построена следующим образом:

База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (файлового сервера). Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлены СУБД и приложение для работы с БД. На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.

Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на файловом сервере. СУБД инициирует обращения к данным, находящимся на файловом сервере, в результате которых часть файлов БД копируется на клиентский компьютер и обрабатывается, что обеспечивает выполнение запросов пользователя (осуществляются необходимые операции над данными). При необходимости (в случае изменения данных) данные отправляются назад на файловый сервер с целью обновления БД. Результат СУБД возвращает в приложение. Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов. В рамках архитектуры «файл-сервер» были выполнены первые версии популярных т.н. настольных СУБД, таких как dBase и Microsoft Access.

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

На сегодняшний день известно более двух десятков форматов данных настольных СУБД, однако наиболее популярными, исходя из числа проданных копий, следует признать dBase, Paradox, FoxPro и Access. Из появившихся недавно СУБД следует также отметить Microsoft Data Engine - по существу серверную СУБД, представляющую собой <облегченную> версию Microsoft SQL Server, но предназначенную, тем не менее, для использования главным образом в настольных системах и небольших рабочих группах.

	Производитель
		http://www.dbase2000.com/
		http://www.corel.com/
Microsoft Access 2000		http://www.microsoft.com/
Microsoft FoxPro		http://www.microsoft.com/
Microsoft Visual FoxPro		http://www.microsoft.com/
Microsoft Visual FoxPro		http://www.microsoft.com/
Microsoft Data Engine		http://www.microsoft.com/

1.5.Требования и стандарты, предъявляемые к базам данных

К современным базам данных, а, следовательно, и к СУБД, на которых они строятся, предъявляются следующие основные требования:

· Высокое быстродействие (малое время отклика на запрос).

Для создания новой базы данных с помощью мастера выполните следующие действия:

Выполните команду Файл [Создать]

В открывшемся окне диалога “Создание” выберите ярлык “Базы данных”. На экране появится список баз данных, предлагаемых мастером. Данный список очень велик и может достигать нескольких десятков различных вариантов, которые могут сразу использоваться или послужат основой для построения других баз данных. Например, “Заказы на работы”, “Счета”, “Контакты”, “Мероприятия”, … и т.п.

Выберите из списка подходящий Вам образец базы данных и запустите на выполнение мастер создания базы данных, нажав кнопку ОК.

В открывшемся окне диалога “Файл новой базы данных” из раскрывающегося списка Папка выберите папку, в которой хотите сохранить создаваемую базу данных, а в поле Имя файла введите ее имя. Затем нажмите кнопку Создать.

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

Отмена - прекращает работу мастера;

Назад - позволяет вернуться к предыдущему шагу в работе мастера;

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

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

В следующем окне диалога выберите из предлагаемых образцов вид оформления экрана и нажмите кнопку Далее (при этом на экране Вам предлагается возможность предварительного просмотра видов оформления экранов, которые Вы можете перебирать в правом окне окна диалога).

На следующем шаге работы мастера можно определить вид создаваемых для базы данных отчетов. После выбора подходящего вам вида нажмите кнопку Далее (здесь также Вам предлагается предварительно ознакомиться с возможными вариантами, которые также можно перебирать).

Открывшееся затем окно диалога мастера создания базы данных позволяет задать ее заголовок и рисунок (например, торговый знак фирмы), который будет появляться во всех отчетах. Если Вы решили использовать рисунок, установите флажок Да. В этом случае становится доступна кнопка Рисунок, нажатие на которую открывает окно диалога “Выбор рисунка” для выбора заранее созданного Вами файла с рисунком. Нажмите кнопку Далее для выполнения дальнейших установок.

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

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

Если варианты предложенных баз данных Вас не устраивают, то Вы можете создать пустую базу данных и добавить в нее таблицы, запросы, формы и отчеты .

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

Создание таблицы в MS Access осуществляется в окне базы данных. Рассмотрим последовательность Ваших действий при создании таблицы в новой базе данных:

Откройте окно созданной Вами базы данных и перейдите на вкладку “Таблицы”.

Нажмите кнопку Создать в окне базы данных.

Откроется окно диалога “Новая таблица”, в правой части которого находится список вариантов дальнейшей работы:

Режим таблицы - позволяет создать новую таблицу в режиме таблицы;

Конструктор - позволяет создать новую таблицу в конструкторе таблиц;

Мастер таблиц - позволяет создать новую таблицу с помощью мастера;

Импорт таблиц - позволяет осуществить импорт таблиц из внешнего файла в текущую базу данных;

Связь с таблицами - позволяет осуществить создание таблиц, связанных с таблицами из внешних файлов.

Выберите из этой таблицы подходящий Вам вариант создания таблицы и нажмите кнопку ОК.

Создайте структуру таблицы с помощью выбранного Вами средства. Создать таблицу можно с помощью мастера и с помощью конструктора.

Для того чтобы связать таблицу с содержащейся в ней информацией, каждой таблице присваивается имя. Задайте имя таблицы в окне диалога “Сохранение” и нажмите кнопку ОК.

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

Наименование поля вводится в поле ввода столбца имя поля. При задании наименований полей Вы должны следовать следующим правилам:

Наименование поля может содержать до 64 символов, но не следует злоупотреблять этой возможностью, задавая слишком длинные имена;

Наименование поля может содержать буквы, цифры, пробелы и специальные символы, за исключением точки (.), восклицательного знака (!), прямых скобок () и некоторых управляющих символов (с кодами ASCII 0-31);

Наименование поля не может начинаться с пробела;

Два поля в одной таблице не могут иметь одинаковых наименований;

Несоблюдение этих правил отслеживается средствами СУБД MS Access, но в некоторых случаях это может привести к трудно определяемым ошибкам, поэтому рекомендуется самостоятельно контролировать следование вышеперечисленным правилам в практической работе.

Желательно стараться использовать имена, отличающиеся краткостью, для облегчения их идентификации при просмотре таблиц.

Текстовый;

Числовой;

Денежный;

Счетчик;

Даты/времени;

Логический;

Поле MEMO:

Поле объекта OLE;

Мастер подстановок.

Текстовые поля могут содержать буквы, цифры и специальные символы. Максимальная ширина поля составляет 255 символов.

Для изменения ширины поля нужно в строке Размер поля раздела “Свойства поля” задать число, определяющее ширину поля (от 1 до 255).

Каждый из типов данных наделен собственными свойствами, которые отображаются в разделе “Свойства поля” окна конструктора.

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

В окне конструктора таблицы в столбце Имя поля введите КодЗаказа.

Нажмите клавишу Tab или Enter, чтобы перейти в столбец Тип данных. При этом обратите внимание, что в нижней части окна диалога появляется информация в разделе “Свойства поля”.

В столбце Тип данных появилось значение Текстовый. Нажмите на кнопку раскрытия списка в правой части прямоугольника, и Вы увидите список, содержащий все типы данных. Из этого списка с помощью мыши или клавишами вверх и вниз выберите значение Счетчик и нажмите на клавишу Tab для перехода в столбец Описание. Столбец Описание представляет собой пояснение, которое Вы даете своим полям. Когда Вы в будущем будете работать с данной таблицей, это описание будет появляться в нижней части экрана MS Access всякий раз, когда Вы окажетесь в поле КодЗаказа, и напомнит Вам назначение данного поля.

Введите поясняющий текст в столбец Описание и нажмите клавишу Tab или Enter, чтобы перейти к вводу информации о следующем поле.Аналогичным образом введите описание всех полей таблицы.Завершив ввод структуры таблицы, сохраните ее, выполнив команду Файл/Сохранить.

Создание таблицы в режиме таблицы

Мы рассмотрели два способа создания таблиц, теперь переходим к третьему. Каждый из способов имеет свои преимущества и недостатки. Но мы уверены, что этот способ создания таблицы поразит Вас своей простотой, наглядностью и очень понравится. Не зря он расположен первым в списке методов создания таблиц окна диалога “Новая таблица”. Вы, вероятно, им чаще всего и будете пользоваться.

Ниже приведена последовательность действий, которую Вам предстоит выполнить:

Перейдите на вкладку “Таблицы” окна базы данных и нажмите кнопку Создать.

В окне диалога “Новая таблица” выберите из списка вариантов значение Режим таблицы и нажмите кнопку ОК. В результате выполнения этих действий откроется окно диалога “Таблица”, содержащее созданную по умолчанию таблицу. Эта таблица содержит 20 столбцов и 30 строк, и этого вполне достаточно для начала. После сохранения этой таблицы Вы, конечно, можете добавить столько строк и столбцов, сколько Вам понадобится.

Наименования полей таблицы определены по умолчанию, но вряд ли они удовлетворяют Вашим требованиям. MS Access позволяет очень просто присвоить полям новые имена. Для этого нажмите дважды кнопкой мыши на область выбора первого поля (заголовок которого содержит Поле 1). Имя поля выделяется и появляется мигающий курсор. Введите имя первого поля и нажмите клавишу Tab. Аналогично введите остальные имена полей вашей таблицы в следующих столбцах.

Теперь заполните несколько строк Вашей таблицы, вводя информацию в том виде, в каком она будет вводиться и в будущем. Старайтесь записывать все в одном стиле (например, если первую дату Вы записали 10/14/09, то не пишите следующую в виде Ноябрь 3, 2009). Если MS Access установит неправильный тип данных, Вы сможете его изменить, но лучше вводить все правильно сразу.

Сохраните таблицу, выполнив команду Файл/Сохранить макет или нажав кнопку Сохранить на панели инструментов. В открывшемся окне диалога “Сохранение” присвойте таблице имя и нажмите кнопку ОК.

На запрос о необходимости создания для таблицы первичного ключа нажмите кнопку Да, и MS Access создаст таблицу, удалив лишние строки и столбцы.

Теперь убедитесь, что Access выбрал для каждого поля правильные типы данных. Для этого перейдите в окно конструктора таблицы, выполнив команду Вид/Конструктор таблиц. Если Вас что-то не устраивает в структуре таблицы, внесите необходимые изменения .

В предыдущей главе мы рассмотрели использование фильтров, а в этой главе рассмотрим более мощное средство выборки данных - запросы.

На практике часто требуется выбрать из исходной таблицы часть записей, удовлетворяющих определенным критериям, и упорядочить выборку. Критерии могут определяться сочетанием ряда условий. Например, Вам необходимо выбрать записи о поставщиках определенного товара из Минска и упорядочить их в алфавитном порядке по наименованию фирм. Для решения таких задач предназначены мастера запросов и конструктор запросов, при помощи которых Вы сможете:

Формировать сложные критерии для выбора записей из одной или нескольких таблиц;

Указать поля, отображаемые для выбранных записей;

Выполнять вычисления с использованием выбранных данных.

Что такое “Запрос по образцу”

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

Что же такое “Запрос по образцу”? Запрос по образцу - это интерактивное средство для выбора данных из одной или нескольких таблиц. При формировании запроса Вам необходимо указать критерии выборки записей в исходной таблице. При этом вместо того, чтобы печатать предложения на специальном языке, Вы должны просто заполнить бланк запроса, который располагается в окне конструктора запросов. Метод формирования запроса путем заполнения бланка прост для изучения и понимания. Он способствует эффективному использованию возможностей MS Access пользователями, имеющими даже минимальный навык работы с приложением или не имеющими его вовсе

Вся необходимая информация находится в таблице Клиенты базы данных Борей. Поэтому для создания запроса выполните следующие действия:

В окне базы данных перейдите на вкладку “Запросы” и нажмите кнопку Создать.

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

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

Нажмите и удерживайте кнопку мыши в этом положении. На конце указателя появится прямоугольник.

Перемещайте столбец в требуемом направлении. Толстая вертикальная линия покажет его текущее положение.

Отпустите кнопку, когда толстая вертикальная линия окажется в требуемом месте. Поле будет перемещено в новое место.

Перемещение столбца бланка запроса. Иногда не сразу удается выделить столбец для его перемещения. Убедитесь в том, что Вы нажимаете область выбора столбца (маленький прямоугольник, который находится прямо над названием поля). Это единственное место, за которое Вы можете захватить столбец для переноса. Для переноса поля в бланк запроса дважды нажмите мышью на названии поля

рите Автоотчет.

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

Заключение

В данной курсовой работе было рассмотрено понятие базы данных и системы управлениями базами данных, с помощью которой реализуется централизованное управление данными, хранимыми в базе, доступ к ним, поддержка их в актуальном состоянии. Итак, база данных - это совокупность взаимосвязанных данных, совместно хранимых в одном или нескольких компьютерных файлах. А также было рассмотрена работа с одной из популярных СУБД Microsoft Access.

СУБД Microsoft Access предоставляет необходимые средства для работы с базами данных неискушенному пользователю, позволяя ему легко и просто создавать базы данных, вводить в них информацию, обрабатывать запросы и формировать отчеты. К сожалению, встроенная система помощи недостаточно понятно объясняет начинающему пользователю порядок работы, поэтому возникает необходимость в пособии.

Марченко А. П. Microsoft Access: Краткий курс. – СПб.: Питер, 2005. – стр. 56

Лазарев И.П.. “Microsoft Access для чайников”.. СПб – Питер, 2004. – стр.139.

Лазарев И.П.. “Microsoft Access для чайников”.. СПб – Питер, 2004. – стр. 196.

Марченко А. П. Microsoft Access: Краткий курс. – СПб.: Питер, 2005. – 239.

ЛЕКЦИЯ

Классификация БД. Фактографические и документальные БД.

БД оперативной и ретроспективной информации.

Хранилища данных. Локальные и распределенные БД. Соотношение основных требований и свойств СУБД: система компромиссов

2.1. Классификация баз данных

Классификация баз и банков данных может быть произведена по разным признакам (и относящихся к разным компонентам и сторонам функционирования БнД), среди которых можно выделить, например, следующие (Слайд 2) .

По форме представляемой информации можно выделить фактографические, документальные, мультимедийные, в той или иной степени соответствующие цифровой, символьной и другим (не цифровой и не символьной) формам представления информации в вычислительной среде. К последним можно отнести картографические, видео, аудио, графические и другие БД.

По типу хранимой (не мультимедийной) информации можно выделить фактографические, документальные, лексикографические БД. Лексикографические базы – это классификаторы, кодификаторы, словари основ слов, тезаурусы, рубрикаторы и т.д., которые обычно используются в качестве справочных совместно с документальными или фактографическими БД. Документальные базы подразделяются по уровню представления информации – полнотекстовые (так называемые «первичные» документы) и библиографическо-реферативные («вторичные» документы, отражающие на адресном и содержательном уровне первичный документ).

По типу используемой модели данных выделяют три классических класса БД: иерархические, сетевые, реляционные. Развитие технологий обработки данных привело к появлению постреляционных, объектноориентированных, многомерных БД, которые в той или иной степени соответствуют трем упомянутым классическим моделям.

По топологии хранения данных различают локальные и распределенные БД.

По типологии доступа и характеру использования хранимой информации БД могут быть разделены на специализированные и интегрированные.

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

По сфере возможного применения можно различать универсальные и специализированные (или проблемно-ориентированные) системы.

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

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

Типология баз данных с точки зрения информационных процессов

БД могут соотноситься с различными уровнями информационных процессов: уровень информационных технологий (ИТ), уровень системы (ИС), уровень информационных ресурсов (ИР).(слайд 3)

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

При рассмотрении БД на уровне информационных ресурсов БД трактуется как элемент мировых ИР. Основной характеристикой здесь является содержание БД , хотя и структуры данных также немаловажны.

2.2. Фактографические и документальные БД

Главное отличие фактографических и документальных БД состоит в структуре единицы хранения информации.

Под единицей хранения информации будем понимать совокупность данных, которая с точки зрения информационной системы представляет собой единое целое. Единица хранения определяет свойства целостности и непротиворечивости данных.

С точки зрения структуры единицы хранения принято различать хорошо структурированные данные и слабо структурированные данные.

Хорошо структурированные данные – это данные, в которых каждую единицу хранения информации можно представить в качестве конечного набора атрибутов. При этом каждый из них будет принимать точно определенное значение.

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

Фактографические БД – БД, ориентированные на хранение хорошо структурированных данных. Единицей хранения в таких БД служит описание «факта» конечным четко определенным множеством характеристических свойств.

При построении концептуальной модели таких БД предметная область (ПрО) естественно декомпозируется на объекты и связи между ними. Каждое характеристическое свойство объекта имеет атомарное значение, которое не зависит от контекста использования.

Документальные БД – предназначены для хранения слабо структурированных данных. Единицей хранения при этом является документ, заданный конечным (но не фиксированным) набором полей в общем случае произвольной длины.

При построении документальных БД обычно ПрО представляется как совокупность в общем случае не взаимодействующих объектов. Набор характеристических свойств объекта конечен, но не фиксирован. Значение характеристического свойства может быть множественным и может зависеть от контекста использования (слайд 4).

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

Отличия этих двух видов поиска представлены на слайде (слайд 5) .

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

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

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

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

2.3. БД оперативной и ретроспективной информации. Хранилища данных

С точки зрения основных особенностей ПрО и решаемых задач можно выделить два основных класса БД – оперативной и ретроспективной информации.

БД оперативной информации являются основой так называемых OLTP -приложений (Оп- Line Transactions Processing ) . Типичными примерами OLTP -приложений являются системы складского учета, системы заказов билетов, банковские системы, выполняющие операции по переводу денег, и т. п. Основная функция подобных систем заключается в одновременном выполнении большого количеств коротких транзакций – завершенных блоков операций манипулирования данными, например: "снять некоторую сумму де нег со счета А и добавить эту сумму на счет В", "продать пассажиру билет на заданный поезд на заданное место на определенную дату". Завершенность транзакции означает, что при возникновении ошибки транзакция должна целиком откатиться и вернуть БД к состоянию, которое было до начала транзакции (не должно быть ситуации, когда деньги сняты со счета А , но не поступили на счет В ).

Основные особенности OLTP -приложений:

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

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

3. Запросы на выборку в основном предназначены для предос тавления пользователям возможности выбора из различных справочников, и большая часть этих запросов известна заранее еще на этапе проектирования.

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

БД ретроспективной информации входят в состав документальных ИС, ориентированных на задачи информационного поиска, а также в OLAP -приложения (Оп- Line Analitical Processing , оперативная аналитическая обработка данных). Это обобщенный термин, характеризующий принципы построения систем поддержки принятия решений ( DSS , Decision Support System ), а также хранилищ данных (data warehouse ) и систем интеллектуального анализа данных ( data mining ). Такие системы предназначены для установления зависимостей меж ду данными (например, можно попытаться определить, как связан объем продаж товаров с характеристиками потенциальных покупателей) или для проведения анализа, отвечающего на вопросы "что если...".

БД ретроспективной информации характеризуются следующими особенностями:

1. Добавление в БД новых данных происходит относительно редко крупными блоками.

2. Данные из БД обычно никогда не удаляются.

3. Запросы к данным являются нерегламентированными и, как правило, достаточно сложными. Очень часто новый запрос формулируется аналитиком для уточнения результата, полученного при выполнении предыдущего за проса.

4. Скорость выполнения запросов важна, но не критична.

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

Хранилища данных

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

Концепция хранилища данных первоначально была предложена как решение, обеспечивающее доступ к данным, накопленным в нереляционных системах. Предполагалось, что такое хранилище информации позволит организациям использовать свои архивы данных для эффективного решения деловых задач. Однако из-за чрезвычайной сложности и невысокой производительности подобных систем, созданных на начальных этапах, первые попытки создания хранилищ информации в целом оказались неудачными. С тех пор к концепции хранилищ информации возвращались вновь и вновь, но только в последние годы технология хранилищ данных стала рассматриваться как цен ное и жизнеспособное решение.

Хранилище данных - предметно-ориентированный, интегрированный, привязанный ко времени и неизменяемый набор данных, предназначенный для под держки принятия решений.

В приведенном определении указанные характеристики данных рассматриваются следующим образом.(слайд 6)

Предметная ориентированность. Хранилище данных организовано вокруг основных предметов (или субъектов) организации (например, клиенты, то вары и сбыт), а не вокруг прикладных областей деятельности (выставление счета клиенту, контроль запасов и продажа товаров). Это свойство отража ет необходимость хранения данных, предназначенных для поддержки принятия решений, а не обычных оперативно-прикладных данных.

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

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

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

К онечной целью создания хранилища данных является интеграция корпоративных данных в едином репозитории, обращаясь к которому пользователи могут выполнять запросы, подготавливать отчеты и проводить анализ данных. Подводя итог, можно сказать, что техно логия хранилищ данных – это технология управления данными и их анализа.

Сравнение систем OLTP и хранилищ данных

СУБД, созданная для поддержки оперативной обработки транзакций ( OLTP ), обычно рассматривается как непригодная для организации хранилищ данных, поскольку к этим двум типам систем предъявляются совершенно разные требо вания. Например, системы OLTP проектируются с целью обеспечения макси мально интенсивной обработки фиксированных транзакций, тогда как хранили ща данных – прежде всего для обработки единичных произвольных запросов . На слайде (слайд 7) для сравнения приведены основные характеристики типичных систем OLTP и хранилищ данных.

Проблемы разработки и сопровождения хранилищ данных

Перечислим потенциальные проблемы, связанные с разработкой и сопровождением хранилищ данных (слайд 8) .

· Недооценка ресурсов, необходимых для загрузки данных : многие разработчики склонны недооценивать время, необходимое для извле чения, очистки и загрузки данных в хранилище.

· Скрытые проблемы источников данных : проблемы, связанные с источниками данных, поставляющими ин формацию в хранилище, могут быть обнаружены только спустя несколько лет после начала их эксплуатации.

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

· Повышение требований конечных пользователей

· Унификация данных : создание крупномасштабного хранилища данных может быть связано с решением серьезной задачи унификации данных, но унификация способна умень шить ценность собранной информации

· Высокие требования к ресурсам : может потребоваться огромный объем дискового пространства.

· Владение данными : создание хранилища данных может потребовать изменения статуса конечных пользователей в отношении прав владения данными

· Сложное сопровождение : любая реорганизация деловых процессов или источников данных может отразиться на работе хранилища данных

· Долговременный характер проектов

· Сложности интеграции

Локальные и распределенные БД

В общем случае режимы работы с БД можно классифицировать по следующим признакам:

- многозадачность- однопользовательский или многопользовательский;

- правило обслуживания запросов – последовательное или параллельное;

- схема размещение данных – централизованная или распределенная БД.

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

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

Развитие сетевых технологий в сочетании с широким распространением персональных ЭВМ и внедрением стандартов открытых систем привело к появлению систем баз данных размещенных в сети разнотипных компьютеров. Такие системы распределенных баз данных обеспечивают обработку распределенных запросов, когда при обработке одного запроса используются ресурсы базы, размещенные на различных ЭВМ сети. Система распределенных баз данных состоит из узлов, каждый из которых является СУБД, а узлы взаимодействуют между собой так, что база данных любого узла будет доступна пользователю, так как если бы она была локальной. Архитектура распределенной БД приведена на слайде (слайд 9) .

Соотношение основных требований и свойств СУБД: система компромиссов(слайд 10)

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

1). Каким образом сложные нелинейные структуры данных представить в виде линейных – наиболее соответствующих принципу последовательного представления (хранения) в машинной памяти.

2). Каким образом организовать данные, чтобы была возможность эффективного внесения, удаления и редактирования данных.

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

4). Каким образом организовать данные, чтобы поиск был эффективным и позволял отыскивать записи по нескольким ключам.

Создание базы данных - это по существу попытка найти компромисс сразу по нескольким направлениям и сочетаниям нескольких взаимообратных факторов (с точки зрения их влияния на показатель общей эффективности системы), в том числе, следующих(слайд 11) :

1) Эффективность – простота;

2) Скорость выборки – стоимость (сложность) аппаратных средств;

3) Скорость выборки – сложность процедур доступа;

4) Плотность данных – время доступа и сложность процедур;

5) Независимость данных – производительность;

6) Гибкость средств поиска – избыточность данных или

7) Гибкость поиска – скорость поиска;

8) Сложность процедур доступа – простота обслуживания.