Remkomplekty.ru

IT Новости из мира ПК
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Централизованная архитектура бд

Распределенные и централизованные базы данных. Архитектура файл-сервер. Архитектура клиент-сервер.

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

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

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

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

Иерархическая и сетевая модели данных.

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

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

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

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

Основная идея реляционной модели данных заключается в том, чтобы представить любой набор данных в виде двумерных таблиц. В простейшем случае реляционная модель описывает единственную двумерную таблицу, но как правило эта модель описывает структуру и взаимодействие нескольких двумерных таблиц. Развитие реляционных баз данных началось в 60х годах когда появились первые работы в которых обсуждалась возможность использования при проектировании баз данных привычных и естественных способов представления данных, так называемых табличных дата-логических моделей. Теория реляционных баз данных разработана в 60х годах в США Коддом. Теория имеет мощную математическую основу описывающую правила эффективной организации данных. Разработанная Коддом теоретическая база стала основой теории проектирования баз данных. Кодд предложил использовать для обработки данных классический аппарат теории множеств и доказал что любой набор данных можно представить в виде двумерных таблиц особого вида известных в математике как отношения. Термин отношения в реляционной модели данных обозначает таблицу. Наименьшая единица данных, с которой оперирует реляционная модель данных это отдельное для данной предметной области атомарное значение данных, которое не может быть разложено на более простые составляющие. Множество атомарных значений одного и того же типа образует домен. Домен определяется как допустимое потенциальное множество значений одного типа. В один домен могут входить значения из нескольких колонок объединенных помимо одинакового типа данных еще и логически. Каждый элемент данных в отношении может быть определен с указанием его адреса в формате aij, где a – элемент данных, i – строка отношения, j – номер атрибута отношения. Количество атрибутов в отношении определяет его порядок. Множество значений aij-x при постоянном i и всех возможных j образует кортеж отношения или просто строку таблицы. Количество всех кортежей в отношении определяет его мощность или кардинальное число. Совокупность всех кортежей образует тело отношения. Некоторые множества атрибутов образуют ключ для данного отношения если задание значений этих атрибутов определяет значение всех остальных атрибутов таблицы. Множество атрибутов отношения является возможным ключом этого отношения, когда выполняются два независимых условия.

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

2. Минимальность. Ни один из входящих и исходящих в ключ атрибутов не может быть исключен из ключа без нарушения условия уникальность.

Реляционная база данных.

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

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

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

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

3. Ни в какой момент времени в таблице не должно быть двух строк дублирующих друг друга.

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

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

18 Функции системы управления базами данных (СУБД): управления данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями.

Считается, что система управления данными является СУБД при условии что она выполняет следующие функции:

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

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

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

5. Поддержка языков баз данных.

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

Считается, что система управления данными является СУБД при условии что она выполняет следующие функции:

1. Непосредственное управление данными во внешней памяти.

2. Управление буферами оперативной памяти.

3. Управление транзакциями.

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

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

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

Читать еще:  Архитектура arm скачать

5. Поддержка языков баз данных. Стандартным языком наиболее распространенных СУБД является SQL.

Вопрос Централизованная архитектура

Вопрос

Лекция № 4

«ПОНЯТИЕ АРХИТЕКТУРЫ ИНФОРМАЦИОННОЙ СИСТЕМЫ»

Учебные вопросы:

В начале лекции рассмотреть определение «архитектуры информационной системы», которое дают различные источники:

• Архитектура — это организационная структура системы.

• Архитектура информационной системы — концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы.

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

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

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

• Архитектура — это структура организации и связанное с ней поведение системы.

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

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

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

Таким образом, под архитектурой программных систем будем понимать совокупность решений относительно:

• организации программной системы;

• выбора структурных элементов, составляющих систему и их интерфейсов;

• поведения этих элементов во взаимодействии с другими элементами;

• объединение этих элементов в подсистемы;

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

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

Далее рассмотреть классификацию программных систем по их архитектуре:

• Двухзвенная архитектура «клиент-сервер»;

• Архитектура распределенных систем.

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

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

Централизованная архитектура вычислительных систем была распространена в 70-х и 80-х годах и реализовывалась на базе мейнфреймов (например, IВМ-З60/З70 или их отечественных аналогов серии ЕС ЭВМ), либо на базе мини-ЭВМ (например, PDP-11 или их отечественного аналога СМ-4). Характерная особенность такой архитектуры — полная «не интеллектуальность» терминалов. Их работой управляет хост-ЭВМ.

Достоинства такой архитектуры:

· пользователи совместно используют дорогие ресурсы ЭВМ и дорогие периферийные устройства;

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

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

Главным недостатком для пользователя является то, что он полностью зависит от администратора хост-ЭВМ. Пользователь не может настроить рабочую среду под свои потребности — все используемое программное обеспечение является коллективным.

Классическое представление централизованной архитектуры показано на рис. l.

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

Рис.1.Классическое представление централизованной архитектуры

3 вопрос . Архитектура «файл-сервер»

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

Функции клиента: обработка данных происходит исключительно на стороне клиента.

Классическое представление информационной системы в архитектуре «файл-сервер» представлено на рис. 2.

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

Достоинства такой архитектуры:

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

· удобство централизованного управления доступом;

· низкая стоимость разработки;

· высокая скорость разработки;

· невысокая стоимость обновления и изменения по.

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

· отсутствие гарантии целостности;

· низкая производительность (зависит от производительности сети, сервера, клиента);

· плохая возможность подключения новых клиентов;

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

4 вопрос . Архитектура «клиент-сервер»

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

Схематически такую архитектуру можно представить, как показано на рис. 3.

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

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

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

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

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

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

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

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

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

Преимуществами данной архитектуры являются:

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

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

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

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

Архитектура СУБД. Архитектура баз данных. Логическая структура СУБД. Описание данных в базе данных. Базы данных схема данных

  • 08.12.2012
  • Базы данных
  • 2 комментария

Здравствуйте, уважаемые посетители моего скромного блога для начинающих вебразработчиков и web мастеров ZametkiNaPolyah.ru. Продолжаем рубрику Заметки о MySQL, в которой уже были публикации: Нормальные формы и транзитивная зависимость, избыточность данных в базе данных, типы и виды баз данных, настройка MySQL сервера и файл my.ini, MySQL сервер, установка и настройка. Сегодня мы поговорим о логической структуре СУБД и архитектуре баз данных. Как всегда, я постараюсь описать архитектуру СУБД на простом и понятном языке, без всяких сложных и умных слов.

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

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

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

Читать еще:  Error c2143 синтаксическая ошибка отсутствие перед

Трехуровневая архитектура баз данных. Три уровня абстракции описания данных.

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

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

Для наглядности можете посмотреть на рисунок, на нем продемонстрирована структура трехуровневой СУБД:

Структура базы данных

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

Базы данных. Схема данных. Независимость уровней от данных.

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

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

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

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

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

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

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

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

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

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

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

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

  1. Таблицы и их атрибуты
  2. Связи между таблицами
  3. Ограничения, накладываемые на данные
  4. Семантику данных
  5. В концептуальной схеме данных должны быть учтены аспекты безопасности и целостности данных

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

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

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

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

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

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

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

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

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

Введение в базы данных. Базы данных, системы управления базами данных, банки данных. Организация баз данных: иерархическая, сетевая, реляционная и объектная.

База данных – это некоторый набор перманентных (постоянных) данных, используемых прикладными системами какого-либо предприятия [Ошибка! Источник ссылки не найден.].

База данных – это средство для рационального и эффективного хранения информации [Ошибка! Источник ссылки не найден.].

База данных – это самодокументированное собрание интегрированных записей [Ошибка! Источник ссылки не найден.]. База данных является самодокументированной, так как она содержит в дополнение к исходным данным пользователя, описание собственной структуры.

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

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

· пользователь формирует запрос на доступ к данным, применяя определенный язык манипулирования данными (обычно это SQL);

· СУБД получает этот запрос и анализирует его;

· СУБД выполняет необходимые операции в хранимой базе данных;

· СУБД возвращает приложению данные, удовлетворяющие поставленному запросу.

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

По характеру использования СУБД разделяют на:

Персональная СУБД обеспечивает возможность создания локальных БД, работающих на одном компьютере. К персональным СУБД относятся Рагаdох, dBase, FохРго, Ассеss (ранних версий) и др.

Многопользовательские СУБД позволяют создавать информационные системы, функционирующие в архитектуре «клиент-сервер». К многопользовательским СУБД относятся Огас1е, Informiх, SyBase, Мiсгоsoft SQL Server, InterBasе и другие.

В состав языковых средств современных СУБД входят:

· язык описания данных, предназначенный для описания логической структуры данных (DDL Data Definition Language);

· язык манипулирования данными, обеспечивающий выполнение основных операций над данными – ввод, модификацию и выборку (DML Data Manipulation Language);

· язык структурированных запросов (SQL Structured Query Language), обеспечивающий управление структурой БД и манипулирование данными, а также являющийся стандартным средством доступа к удаленным БД;

· язык запросов по образцу (QВЕ – Query Ву Ехаmp1е), обеспечивающий визуальное конструирование запросов к БД.

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

· манипулирование данными (хранение, извлечение и обновление);

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

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

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

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

В зависимости от организации данных различают следующие основные модели представления данных в БД:

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

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

В сетевой модели данные организуются в виде произвольного графа (рис.3.3). Недостатком сетевой модели является жесткость структуры и высокая сложность организации.

Читать еще:  Ошибка системного времени ютуб

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

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

Архитектура БД. Модели данных, используемые на различных этапах проектирования БД.

Основной целью любой СУБД является возможность предложить обычному пользователю базы данных абстрактное представление данных, скрыв от пользователя особенности хранения и управления ими. Поскольку база данных, как правило, разрабатывается как общий ресурс для большого количества пользователей, то каждому пользователю может потребоваться своё, отличное от других пользователей представление о данных, хранимых в БД. Это вызвано следующими причинами:
— каждый пользователь иметь право обращаться к общим данным, используя своё представление о них;
— взаимодействие пользователя с БД не должно зависеть от особенностей её физической организации;
— администратор базы данных (АБД) должен иметь возможность изменять структуру и формат данных, не оказывая влияния на пользовательские представления;
— внутренняя структура БД не должна зависеть от таких изменений физических аспектов хранения информации, как переключение на новое устройство хранения;
— АБД должен иметь возможность изменять концептуальную или глобальную структуру данных без какого—либо влияния на всех пользователей.
Для удовлетворения этих потребностей архитектура большинства современных коммерческих СУБД, существующих на рынке программного обеспечения, в той или иной мере, строится на базе так называемой архитектуры ANSI—SPARC. Название произошло по названию комитета планирования стандартов и норм (Standards Planning and Requirements Committee SPARC) национального института стандартизации (American National Standard Institute— ANSI) США. Комитет признал необходимость использования трехуровневого подхода к организации БД. Этот подход отделяет пользовательские представления базы данных от её физического представления посредством создания независимого уровня, изолирующего программы от особенностей представления данных на низком уровне.
Архитектура БД представлена на рисунке 1.
Внешний уровень – это индивидуальное представление БД с точки зрения отдельного пользователей. Пользователи могут быть разные, с разным уровнем подготовки. Каждый пользователь представляет данные в соответствии с формами различных документов, присущих данной предметной области. При этом одни и те же данные могут иметь различную форму представления — формат (тип), длину. Например, сведения о зарплате – их можно увидеть в виде итоговой суммы в записи ведомости, либо в виде перечня составляющих – различных начислений и удержаний.

ПП1 – представление 1—го пользователя, ППк – представление к—того пользователя

Рисунок 1 — Трехуровневая архитектура БД

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

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

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

Различают логическую и физическую независимость данных.

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

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

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

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

В современной трактовке термин «модель данных» обозначает инструмент моделирования. Модель базы данных (схема данных) или модель предметной области являются результатами моделирования.

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

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

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

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

Модели данных, как инструменты, делятся на 3 основные категории:

1. Объектные модели данных. В этих моделях используются такие понятия как: классы объектов (типы сущностей), объекты (экземпляры сущностей), свойства классов объектов (атрибуты сущностей), связи между классами объектов. В скобках приведена исторически ранняя терминология, используемая в теории баз данных.
Среди объектных моделей выделяют наиболее общие типы:
— семантические модели. Их назначение – обеспечение возможности выражения семантики (смыла) предметной области. Это, например, модели типа «сущность—связь» (ER—модели — Entity Relationship model), отображающие семантику предметной области в виде ER—диаграмм;
— функциональные модели, дающие представление о функциях автоматизируемого предприятия, о распределении ответственности за их выполнение. Результаты использования функциональных моделей могут быть представлены в виде диаграмм бизнес—функций, диаграмм потоков данных;
—объектно—ориентированные модели. Эти модели расширяет определение класса объектов (сущности) предметной области с целью включения в определение не только свойств, описывающих состояние объекта, но и действий, которые с ним связаны, т.е. его поведение. Это, например, модели, основанные на использовании языка UML (Unified Modeling Language — унифицированного языка моделирования). Описание предметной области получают в виде различных диаграмм — диаграмм вариантов использования, диаграмм деятельности, диаграмм классов.
В настоящее время для проектирования БД, получения концептуальной инфологической модели предметной области, широко используются семантические модели «сущность—связь».
2. Модели на основе физических записей. Такие модели позволяют описывать логическую структуру БД в виде записей, фиксированного формата. Каждый тип записи определяет фиксированное количество полей, каждое из которых имеет фиксированную длину. Существует три основных типа логических моделей данных на основе записей:
— иерархическая (hierarchical data model);
— сетевая (network data model);
— реляционная (relational data model).
3. Физические модели данных. Модель содержит всю информацию, необходимую для реализации конкретной БД в среде выбранной (целевой) СУБД. В физической модели в виде описания содержится информация обо всех объектах БД. В описании объектов БД определяется физический формат данных, реализуются ограничения предметной области, бизнес—логика автоматизируемого предприятия, уровни доступа пользователей. Описание создается на языке определения данных (ЯОД) выбранной (целевой) СУБД. В состав ЯОД входят операторы, позволяющие создать или удалить объект БД, модифицировать его структуру. Физическая модель данных не затрагивает вопросы физического размещения данных на машинных носителях, в настоящее время это максимально реализуется средствами СУБД.
Модели первых двух групп используются для формирования концептуального уровня архитектуры БД, третьей – для описания БД на внутреннем уровне.
Модель данных, полученная в результате проектирования, должна представлять автоматизируемое предприятие в таком виде, который позволит проектировщикам и пользователям БД обмениваться конкретными недвусмысленными мнениями.

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

В таблице 1 представлены модель, которые будем использовать при проектировании базы данных

Таблица 1 — Модели данных

Модель данных, как инструмент, используемый для формирования схемы БД

Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector
×
×