Понятие СУБД. Архитектура СУБД. Классификация СУБД
Понятие. Система управления базами данных (СУБД) – это сов-сть языковых и програмн средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.
Современная СУБД содержит в своем составе программные средства создания баз данных (язык описания и манипулирования данными, визуальные средства, отладчики), средства работы с данными и сервисные средства. Функции элементов СУБД: — язык описания служит для преобразования логической модели в физическую; — язык манипулирования реализует операции над данными; — визуальные средства привлекаются в процессе проектирования графических объектов; — программы отладки соединяют и тестируют блоки программы управления, созданной БД; — средства работы с БД обеспечивают удобный интерфейс с пользователем; сервисные средства привлекают к работе с БД другие программы (эксель).
Архитектура. В среде СУБД можно выделить след. пять основных компонентов.
Аппаратное обеспечение. Одни СУБД предназначены для работы только с конкр типами ОС или оборудования, другие могут работать с широким кругом аппаратного обеспечения и различными ОС. Для работы СУБД обычно требуется некоторый минимум оперативной и дисковой памяти, но ее может быть недостаточно для достижения приемлемой производительности системы.
Программное обеспечение. Этот компонент включает операционную систему, программное обеспечение самой СУБД, прикладные программы, включая и сетевое программное обеспечение, если СУБД используется в сети. Обычно приложения создаются на языках третьего поколения, таких как С, COBOL, Fortran, Ada или Pascal, или на языках четвертого поколения, таких как SQL, операторы которых внедряются в программы на языках третьего поколения.
Данные – наиболее важный компонент с точки зрения конечных пользователей. База данных содержит как рабочие данные, так и метаданные, т.е. «данные о данных».
Процедуры, к которым относят инструкции и правила, которые должны учитываться при проектировании и использовании базы данных: регистрация в СУБД; использование отдельного инструмента СУБД или приложения; запуск и останов СУБД; создание резервных копий СУБД; обработка сбоев аппаратного и программного обеспечения, включая процедуры идентификации вышедшего из строя компонента, исправления отказавшего компонента (например, посредством вызова специалиста по ремонту аппаратного обеспечения), а также восстановления базы данных после устранения неисправности; изменение структуры таблицы, реорганизация базы данных, размещенной на нескольких дисках, способы улучшения производительности и методы архивирования данных на вторичных устройствах хранения.
Пользователи: клиенты БД, администратор БД, прикладн. программисты.
Подсистема средств проектирования представляет собой набор инструментов, упрощающих проектирование и реализацию баз данных и их приложений. Как правило, этот набор включает в себя средства для создания таблиц, форм, запросов и отчетов.
Подсистема обработки обеспечивает обработку компонентов приложений, созданных с помощью средств проектирования. Например, в Access 2003 имеется компонент, реализующий построение формы и связывающий элементы формы с данными таблиц.
Третий компонент СУБД – ее ядро (DBMS Engine) выполняет функцию посредника между подсистемой средств проектирования и обработки и данными. Ядро СУБД получает запросы от двух других компонентов, выраженные в терминах таблиц, строк и столбцов, и преобразует эти запросы в команды операционной системы, выполняющие запись и чтение данных с физического устройства.
Microsoft представляет два различных ядра для Access 2003: Jet Engine и SQL Server. Ядро Jet Engine используется для персональных и коллективных баз данных небольшого объема. Ядро SQL Server предназначено для крупных баз данных.
По степени универсальности:
СУБД общего назначения не ориентированы на какую-либо конкретную предметную область или на информационные потребности конкретной группы пользователей. Они не всегда позволяют добиться требуемой производительности и/или удовлетворить заданные ограничения по объёму памяти, предоставляемой для хранения БД.
Тогда — специализированную СУБД для данного конкретного применения. Примером специализированной СУБД может быть система IMBASE, используемая для автоматизации проектных и конструкторских разработок.
По типу модели данных:
— иерархические. Первой такая СУБД — система IMS (Information Management System) компании IBM;
— сетевые. Первой сетевой СУБД считается система IDS (Integrated Data Store), разработанная компанией General Electric немного позже системы IMS;
— реляционные. Первые коммерческие реляционные СУБД от компаний IBM, Oracle Corporation, Relation Technology Inc. и других поставщиков появились в начале 80-х годов. Реляционные СУБД просты в использовании, повышают производительность программистов при разработке прикладных программ, хорошо приспособлены для работы в архитектуре клиент/сервер, позволяют параллельную обработку БД, хорошо приспособлены к графическим пользовательским интерфейсам.
— объектно-реляционные (постреляционные). Объектно-реляционные СУБД продолжают использовать стандартный язык запросов для реляционных БД – SQL, но с объектными расширениями;
— объектно-ориентированные. В основе объектно-ориентированных СУБД лежит объектно-ориентированная модель обработки данных.
— многомерные, в основе которых лежит многомерная модель данных.
На самом общем уровне все СУБД можно разделить на:
— профессиональные (промышленные), которые представляют собой программную основу для разработки автоматизированных систем управления крупными экономическими объектами. (Oracle, DB2, Sybase, Informix, Inqres, Progress).
— персональные (настольные). (DBASE,FoxBase, FoxPro, Clipper, Paradox, Access.)
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
4. Типы управления бд (субд)
По технологии обработки данных базы данных подразделяются на централизованные и распределенные.
Централизованная база данных хранится в памяти одной вычислительной системы. Если эта вычислительная система является компонентом сети ЭВМ, возможен распределенный доступ к такой базе. Такой способ использования баз данных часто применяют в локальных сетях ПК.
Распределенная база данных состоит из нескольких, возможно пересекающихся или даже дублирующих друг друга частей, хранимых в различных ЭВМ вычислительной сети. Работа с такой базой осуществляется с помощью системы управления распределенной базой данных (СУРБД).
По способу доступа к данным базы данных разделяются на базы данных с локальным доступом и базы данных с удаленным доступом.
Системы централизованных баз данных с сетевым доступом предполагают различные архитектуры подобных систем;
Файл-сервер. Архитектура систем БД с сетевым доступом предполагает выделение одной из машин сети в качестве центрального сервера файлов. На такой машине хранится совместно используемая централизованная БД. Все другие машины сети выполняют функции рабочих станций, с помощью которых поддерживается доступ пользовательской системы к централизованной базе данных.
Клиент-сервер. В этой концепции подразумевается, что помимо хранения централизованной базы данных центральная машина (сервер базы данных) должна обеспечивать выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере. Извлеченные данные, но не файлы транспортируются по сети от сервера к клиенту.
По степени универсальности различают два класса СУБД:
— системы общего назначения;
СУБД общего назначения не ориентированы на какую-либо предметную область или на информационные потребности какой-либо группы пользователей. Каждая система такого рода реализуется как программный продукт, способный функционировать на некоторой модели ЭВМ в определенной операционной системе и поставляется многим пользователям как коммерческое изделие.
Специализированные СУБД создаются в редких случаях при невозможности или нецелесообразности использования СУБД общего назначения.
5. Классификация субд по архитектуре
По своей архитектуре СУБД делятся на одно-, двух- и трехзвенные:
— клиент-сервер приложений-сервер БД- данные;
В однозвенной архитектуре используется единственное звено (клиент), обеспечивающее необходимую логику управления данными и их визуализацию.
В двухзвенной архитектуре значительную часть логики управления данными берет на себя сервер БД, в то время как клиент в основном занят отображением данных в удобном для пользователя виде.
В трехзвенных СУБД используется промежуточное звено — сервер приложений, являющееся посредником между клиентом и сервером БД. Сервер приложений призван полностью избавить клиента от каких бы то ни было забот по управлению данными и обеспечению связи с сервером БД.
Терминал — это интерфейсный (обычно графический) компонент, который представляет первый уровень, собственно приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с базой данных (по требованиям безопасности), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надежности). На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал.
Сервер приложений располагается на втором уровне. На втором уровне сосредоточена большая часть бизнес-логики. Вне его остаются фрагменты, экспортируемые на терминалы, а также погруженные в третий уровень хранимые процедуры и триггеры.
Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных.
1 Классификация субд
СУБД ОБЩЕГО НАЗНАЧЕНИЯ не ориентированы на какую-либо конкретную предметную область или конкретного пользователя, являются универсальными, реализуют функционально избыточное множество операций над данными, имеют в своем составе средства настройки на конкретную предметную область, условия эксплуатации и требования к пользователю.
СПЕЦИАЛЬНЫЕ СУБД создаются в случае, если СУБД общего назначения не удовлетворяют по каким-либо параметрам. Необходимые параметры специальных СУБД достигаются:
1) за счет знания особенностей конкретной предметной области.
2) путем сокращения функциональной полноты системы.
2. Архитектура субд.
В архитектуре современных СУБД выделяют три уровня описания элементов хранимых данных. Эти уровни составляют трехуровневую архитектуру, которая охватывает внешний, концептуальный и внутренний уровни.
Внешний уровень – представление базы данных с точки зрения конкретных пользователей.
Указанный уровень может включать несколько различных представлений БД со стороны различных групп пользователей. При этом каждый пользователь имеет дело с представлением предметной области, выраженным в наиболее понятной и удобной для него форме. Такое представление содержит только те сущности, атрибуты и связи, которые интересны ему при решении профессиональных задач.
На внешнем уровне создается инфологическая модель БД (внешняя схема), полностью независимая от платформы (т.е. вычислительной системы, на которой будет использоваться). Инфологическая модель является человеко-ориентированной: средой ее хранения может быть память человека, а не ЭВМ.
Концептуальный уровень – обобщающее представление базы данных, описывающее то, какие данные хранятся в БД, а также связи, существующие между ними.
Концептуальный уровень содержит логическую структуру всей БД. На концептуальном уровне необходимо выделить:
сущности, их атрибуты и связи;
ограничения, накладываемые на данные;
семантическую информацию о данных (смысловое содержание);
информацию о мерах обеспечения безопасности.
На концептуальном уровне создается даталогическая модель (концептуальная схема БД), представляющая собой описание инфологической модели (внешней схемы) на языке определения данных конкретной СУБД. Эта модель является компьютеро-ориентированной (зависит от применяемой на компьютере СУБД).
Внутренний уровень – описывает физическую реализацию базы данных и предназначен для достижения оптимальной производительности и обеспечения экономного использования дискового пространства. Содержит описания структур данных и отдельных файлов, используемых для хранения данных в запоминающих устройствах.
На внутреннем уровне создается физическая модель БД, является компьютеро-ориент. С ее помощью СУБД дает возможность программам и пользователям осуществлять доступ .
3. Этапы проектрирования бд
Основная цель проектирования БД — это сокращение избыточности хранимых данных, то есть «Каждый факт в одном месте». Проектирование БД — это процесс проектирования отображения: «Описание ПО» «Схема внутренней модели БД»
Этапы проектирования базы данных.
Задача инфологического проектирования БД – получение семантических (смысловых) моделей, отражающих информационное содержание конкретной предметной области.
Задача логического этапа проектирования – организация данных, выделенных на предыдущем этапе проектирования в форму, принятую в выбранной конкретной СУБД.
Задача физического этапа проектирования – выбор рациональной структуры хранения данных и методов доступа к ним, исходя из арсенала методов и средств, который предоставляется разработчику системой управления базами данных.
4. Иерархическая модель организации данных (ИМД).
В ИМД объекты сущностей и отношения предметной области представляются набором данных, которые имеют строго древовидную структуру.
Достоинства ИМД: позволяют описать структуру, как на логическом, так и на физическом уровнях.
Жесткая фиксация связей между элементами данных;
Быстрота доступа достигается за счет потери информационной гибкости;
В ИМД устанавливается строгий порядок обхода дерева (сверху — вниз, слева – направо) и следующие операции над данными:
а) найти указанное дерево;
б) перейти от одного дерева к другому;
в) перейти от одной записи к другой;
г) перейти от одной записи к другой в порядке обхода иерархии;
д) удалить текущую запись.
Основное внимание в ограничении целостности в ИМД уделяется целостности ссылок между предками и потомками. С учетом основного правила, никакой потомок не может существовать без родителей.
5. Сетевая модель данных (СМД).
СМД является расширением иерархической, но в отличие от ИМД здесь объект потомок может иметь не одного, а любое количество предков, то есть допускаются любые связи отношений, в том числе и одноуровневые, поэтому сетевая модель может быть представлена графом любого типа. СМД состоит из одного или нескольких типов записей и набора связей между ними, то есть каждый тип записи представлен в базе данных набором экземпляров записей данного типа. Аналогично, каждый тип связи представлен набором экземпляров связей данного типа между конкретными экземплярами типов записей. Для данного типа связей «L», между типом записи предка «Р» и типом записи потомка «С» выполняются следующие условия:
1) каждый экземпляр типа «Р» является предком не более, чем в одном экземпляре «L».
2) каждый экземпляр «С» является потомком не более, чем в одном экземпляре «L».
Над данными выполняются следующие операции:
1) найти конкретную запись (экземпляр) в наборе однотипных записей;
2) перейти от предка к первому потомку по некоторой связи;
3) перейти к следующему потомку по некоторой связи;
4) создать новую запись;
5) уничтожить запись;
6) модифицировать запись;
7) включить в связь;
8) исключить из связи;
9) переставить в другую связь.
1. навигация по связанным данным, что является отличительной особенностью СМД.
2. использование множественных типов данных для описания атрибута информационных объектов, что позволяет создавать информационные структуры табличной формы.
3. адекватность отражает инфологические схемы сложных предметных областей.
Недостаток: невозможно использовать различные прикладные информационные системы для одинакового описания данных в сетевой организации.
6
. Реляционная модель организации данных (РМД).
В РМД объекты сущности инфологической схемы предметной области представляются плоскими таблицами данных. Столбцы таблицы, называемые полями соответствуют атрибутам объектов сущностей. Множество атомарных значений атрибута называется доменом. Строки таблиц представляют собой различное сочетание значений полей из доменов и называются кортежами (записями) и соответствуют экземплярам объектов сущностей.
В случае РМД слово «отношение» выражает не взаимосвязь между таблицами-сущностями, а определение самой таблицы как математического отношения доменов. Ключевому атрибуту объекта сущности, который идентифицирует (определяет) конкретный экземпляр объекта в таблице соответствует ключевое поле, когда конкретную запись таблицы идентифицирует значение не одного поля, а нескольких. Тогда, все эти поля называются ключевыми, а ключ составным. Ключевое поле для созданной записи впоследствии обновиться не может.
В некоторых таблицах роль ключа могут играть сразу несколько полей или группа полей. В этом случае один из ключей объявляется первичным. Непервичные ключи называются возможными, и в отличии от первичных могут обновляться. Отношения связей объектов сущностей в РМД устанавливаются через введение в таблицах дополнительных полей, и называются внешними ключами. Значения первичных ключей уникальны, то есть не могут повторяться. Значения внешнего ключа могут повторяться, что автоматически обеспечивает связь «один ко многим». Следовательно, связи типа «один к одному» в РМД автоматически обеспечиваются при одинаковых первичных ключах и РМД не может непосредственно отражать связь типа «многие ко многим», что снижает возможности реляционных баз при отображении сложных предметных областей.
Таким образом структура РМД определяется следующим набором базовых понятий:
1) таблица – отношение 2) схема таблицы отношения 3) домен 4) поле – атрибут 5) кортеж – запись(строка) 6) ключ 7) первичный ключ 8) вторичный ключ 9) внешний ключ (ссылка).
Ограничение целостности РМД разделяют на 2 группы:
1) требования целостности сущностей 2) целостность ссылок.
Первое заключается в уникальности экземпляров объектов, что соответствует уникальности каждого кортежа. Следовательно, существуют ограничения:
1. отсутствие кортежей-дубликатов (не должны совпадать первичные ключи).
2. отсутствие полей с множественным характером значений атрибутов.
Второе заключается в том, что целостность ссылок для любого кортежа с конкретным значением внешнего ключа должен соответствовать кортеж связанной таблицы с соответствующим значением первичного ключа. С целью создания условий для быстрого нахождения нужной записи при любых изменениях данных вводят индексирование полей.