На каком уровне архитектуры бд определяются разрешения права доступа

Обновлено: 07.07.2024

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

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

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

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

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

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

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

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

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

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

Клиент-серверные (двухзвенные) системы значительно снижают нагрузку на сеть, так как клиент общается с данными через специализированного посредника — сервер базы данных, который размещается на машине с данными. Сервер БД принимает запрос от клиента, отыскивает в данных нужную запись и передает ее клиенту. Таким образом, по сети передается относительно короткий запрос и единственная нужная запись, даже если соответствующий файл с данными содержит сотни тысяч записей. Запрос к серверу формируется на специальном языке структурированных запросов (Structured Query Language, SQL), поэтому часто серверы БД называются SQL-серверами. Серверы БД представляют собой относительно сложные программы, изготавливаемые различными фирмами. К ним относятся, например, Microsoft SQL Server производства корпорации Microsoft, Sybase SQL Server корпорации Sybase, Oracle производства одноименной корпорации1, DB2 корпорации IBM и т. д. SQL-сервером является также и сервер InterBase корпорации Inprise, который поставляется вместе с Delphi в комплектации Enterprise. Клиент-серверные СУБД масштабируются до сотен и тысяч клиентских мест.

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

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

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

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

1. Архитектура базы данных. Физическая и логическая независимость

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

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

1978 год – появился стандарт, который принял коммитет ANSI/SPARC, который фиксирует разделение между логическим и физическим представлением данных. В часности, была предложена 3-х уровневая модель данных, т.е. обобщенная структура.

Рис. 1 - Трехуровневая модель системы управления базой данных, предложенная ANSI

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

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

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

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

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

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

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

Внешний уровень – определяет пользовательские представления данных.

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

Главное назначение трёхуровневой архитектуры – это обеспечение независимости от данных (внутеннего образа хранение от отображения). Независимость от данных бывает 2-х типов:

- логическая – это полная защищенность внешних схем от изменений, которые вносятся в концептуальную схему;

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

2. Этапы жизненного цикла СУБД

Рис. 2 - Жизненный цикл баз данных

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

(План выполнения работ)

- Сформулировать перечень вопросов, которые будут решены при испльзовании новой ИС.

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

- Выбрать ИС, которая будет разрабатываться (обосновать с учетом предыдущих пунктов).

После этого уже можно выполнять этап проектирование.

В часности, это –– водопадный подход.

Основные действия, выполняемые на каждом этапе жизненного цикла СУБД:

1) Планирование разработки БД. На этом этапе рассматривают самые эффективные методики.

2) Определение требований к системе. Диапазон действия БД, состав пользователей, области применения.

3) Сбор и анализ требований пользователей.

4) Проектирование БД. Проведение концептуального, логического и физического проектирование БД.

5) Реализация БД. Создание структуры данных, интерфейса пользователя и т.д., т.е. ПО.

7) Конвертирование и загрузка данных. Этот этап для новых БД не существенно, а для переделанных – очень важно (например, смена ОС).

8) Эксплуатация и сопровождение. Для всех БД актуален. Администрирование. Доработка концептуальной схемы.

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

ЖЦБД включает в себя следующие основные этапы:

- планирование разработки базы данных;

- определение требований к системе;

- сбор и анализ требований пользователей;

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

- разработка приложений (проектирование транзакций; проектирование пользовательского интерфейса);

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

Здесь представлен перечень основных этапов ЖЦБД. Естественно, что конкретное наполнение каждого этапа в значительной степени зависит от сложности разрабатваемого продукта.

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

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

2.2. Планирование разработки базы данных

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

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

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

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

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

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

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

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

- ожидаемая выгода от внедрения подлежащих созданию приложений;

- время окупаемости внедренной БД;

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

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

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

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

2.3. Определение требований к системе

На данном этапе необходимо определить диапазон действия приложения базы данных, состав его пользователей и области применения.

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

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

2.4. Сбор и анализ требований пользователей

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

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

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

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

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

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

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

2.5. Проектирование базы данных

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

Основными целями проектирования базы данных являются:

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

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

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

В создании БД как модели ПрО (предметной области) выделяют:

- объектную (предметную) систему, представляющую фрагмент реального мира;

- информационную систему, описывающую некоторую объектную систему;

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

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

2.6. Концептуальное проектирование базы данных

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

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

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

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

Нисходящий подход демонстрируется в концепции модели "сущность-связь" (Entity - Relationship model – ER-модель) - cамой популярной технологии высокоуровнего моделирования данных, предложенной Ченом.

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

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

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

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

- Выделение ключевых атрибутов.

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

- Анализ и добавление не ключевых атрибутов.

- Объединение локальных представлений.

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

2.7. Логическое проектирование базы данных

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

3. Особенности проектирования СУБД и модели данных

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

1) Обеспечение быстрого доступа к данным. Обычно этот вопрос решают окончательно уже ближе к концу, на этапе проектирования и тестирования.

2) Исключение ненужного повторения данных, которое может явится причиной ошибок при вводе.

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

Можно выделить 2 подхода к проектированию реляционной БД (основаны на нисходящем и восходящем подходах).

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

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

4. Избыточность данных в БД

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

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

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

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

Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу.

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

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

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

Местоположение Ядра БД и баз данных зависит от используемой архитектуры. Имеется три разновидности архитектур баз данных:

• локальные базы данных и архитектура "файл-сервер";

• многозвенная (трехзвенная N-tier или multi-tier) архитектура.

Использование той или иной архитектуры накладывает сильный отпечаток на общую идеологию работы приложения, на программный код в приложении, на состав компонентов для работы с БД, используемых в приложении (прежде всего это касается невизуальных компонентов).[4, 15].

Локальные базы данных и архитектура "файл-сервер"

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

При работе в архитектуре "файл-сервер" БД и приложение расположены на файловом сервере сети (например, Novell NetWare). Возможна много­пользовательская работа с одной и той же БД, когда каждый пользователь со своего компьютера запускает приложение, расположенное на сетевом сервере.

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

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

Кардинальных различий с точки зрения архитектуры между одно­пользовательской архитектурой и архитектурой "файл-сервер" нет. И в том и в ином случае в качестве СУБД применяются так называемые "персональные" (или "локальные") СУБД такие как Paradox, dBase и пр. Сама база данных в этом случае представляет собой набор таблиц, индексных файлов, файлов полей комментариев (мемо-полей) и пр., хранящихся в одном каталоге на диске в виде отдельных файлов.[4].

Удаленные базы данных и архитектура "клиент-сервер"

Архитектура "файл-сервер" неэффективна, по крайней мере, в двух отношениях:

При выполнении запроса к базе данных, расположенной на файловом сервере, в действительности происходит запрос к локальной копии данных на компьютере пользователя. Поэтому перед выполнением запроса данные в локальной копии обновляются из реальной БД. Данные обновляются в полном объеме. Так, если таблица БД состоит из 1000 записей, а для выполнения запроса (например, выдать сумму премий за октябрь в отделе Y) реально нужно 10 записей, все равно перегоняются все 1000 записей. Таким образом, не нужно иметь слишком много пользователей и запросов от них, чтобы серьезно ''забить" сеть, что, конечно же, не может не сказаться на ее быстродействии.

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

Архитектура "клиент-сервер" разделяет функции приложения пользователя (называемого клиентом) и сервера.

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

Все это повышает быстродействие системы и снижает время ожидания результата запроса.

При выполнении запросов сервером существенно повышается степень безопасности данных, поскольку правила целостности данных определяются в базе данных на сервере и являются едиными для всех приложений, исполь­зующих эту БД. Таким образом, исключается возможность определения противоречивых правил поддержания целостности. Мощный аппарат транзакций, поддерживаемый SQL-серверами, позволяет исключить одновременное изменение одних и тех же данных различными пользователями и предоставляет возможность откатов к первоначальным значениям при внесении в БД изменений, закончившихся аварийно. Таким образом, функциями приложения-клиента являются:

посылка к серверу запросов;

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

реализация интерфейса пользователя.

SQL-сервер - это программа, расположенная на компьютере сетевого сервера. SQL-сервер должен быть загружен на момент принятия запроса от клиента. Функциями сервера БД являются:

прием запросов от приложений-клиентов, интерпретация запросов, выполнение запросов в БД, отправка результата выполнения запроса приложению-клиенту;

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

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

обеспечение одновременно безопасной и отказоустойчивой многопользовательской работы с одними и теми же данными. В архитектуре "клиент-сервер" используются так называемые "удаленные" (или "промышленные") СУБД. Промышленными они называются из-за того. что именно СУБД этого класса могут обеспечить работу информационных систем масштаба среднего и крупного предприятия, организации, банка. Локальные СУБД предназначены для однопользовательской работы или для обеспечения работы информационных систем, рассчитанных на небольшие группы пользователей.[4, 15, 11].

К разрядку промышленных СУБД принадлежат: Oracle, Gupta, Informix, Sybase, MS SQL Server, DB2, InterBase и ряд других.

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

Кроме этого, существует отдельная категория сотрудников, называемых администраторами баз данных. Как правило, это администраторы сервера, разработчики БД или пользователи, имеющие привилегии на создание, изменение, настройку оптимальных параметров отдельных серверных БД. Администраторы БД также отвечают за предоставление прав на разно­уровневый доступ к сопровождаемым ими БД для других пользователей.[4, 15, 11].

Использование архитектуры "клиент-сервер":

резко уменьшает сетевой трафик:

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

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

повышает надежность БД, ее целостность, безопасность и секретность.

2.5. Проблемы проектирования БД.

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

1. Что представляют собой требования пользователей и в какой форме они могут быть выражены?

2. Как эти требования могут быть преобразованы в эффективную структуру базы данных?

3. Как часто и каким образом структура базы данных должна перестраиваться в соответствии с новыми и/или изменяющимися требованиями?

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

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

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

ГЛАВА 3. Среда Delphi как средство для разработки СУБД.

Раздел: Информатика, программирование
Количество знаков с пробелами: 176628
Количество таблиц: 13
Количество изображений: 26

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

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

· общая модель предметной области;

· логическая модель данных;

· физическая модель данных;

· база данных и приложения.

ПРЕДМЕТНАЯ ОБЛАСТЬ

ОБЩАЯ МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ

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

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

ЛОГИЧЕСКАЯ МОДЕЛЬ ДАННЫХ

Описывает взаимосвязи между понятиями предметной облас­ти и налагаемые при этом ограничения.

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

Естественно, кроме самих взаимосвязей, между понятиями могут присутствовать и некоторые ограничения на данные, кото­рые в них циркулируют. Например, оценкой может являться только целое число от 2 до 5.

ФИЗИЧЕСКАЯ МОДЕЛЬ ДАННЫХ

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

БАЗА ДАННЫХ И ПРИЛОЖЕНИЯ

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

Access и базы данных

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

Логическая архитектура базы данных

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

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

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

Как и с картотекой, с БД проводят ряд операций над содер­жащейся в ней информацией, например:

■ добавление новой информации;

Организацию действий, выполняемых над информацией, раз­мещение ее в таблицах и манипуляции с ней проводят специали­зированные программы – СУБД, которые отвечают за:

■ управление данными в БД – хранение данных и управление служебной информацией, обеспечивающей работу СУБД;

■ управление памятью компьютера – использование буфериза­ции данных 6 оперативной памяти компьютера;

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

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

Для более полного представления механизма работы СУБД и принципов ее организации рассмотрим ее архитектуру. Различа­ют три уровня архитектуры БД:

■ внутренний уровень – описывает, каким образом размещаются данные на устройствах хранения информации. Он, как прави­ло, недоступен пользователям БД для выполнения просмотра и модификации;

■ внешний уровень – задает способ представления данных непо­средственно для пользователей. На этом уровне имеется воз­можность манипуляции данными в СУБД с помощью языка;

■ концептуальный уровень – является как бы переходным уров­нем от внутреннего к внешнему и представляет собой обоб­щенное представление данных в базе.

Пример

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

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

При оформлении отчета используется текстовый редактор Microsoft Word 97-2003. Рисунки лучше всего делать во внешних (по отношению к Microsoft Word) графических редакторах и вставить в текст отчета в виде графических файлов.

Читайте также:

  
• Конституция рф как источник административного права реферат
  
• Обязан ли совет федерации рассматривать обращения общественных объединений
  
• Уральский синдром почему 10 лет советские граждане умирали от неизвестной болезни
  
• Инклюзивное образование как реализация права презентация
  
• Что такое соискание должности