 |
Архитектура базы данных
|
|
|
|
В SQL Server 2000 информация хранится в базах данных. Она организована в доступные пользователю логические компоненты, а сама база данных физически реализована в виде двух или более файлов на диске. Обращаясь к базе данных, вы главным образом имеете дело с логическими компонентами (таблицами, представлениями, процедурами и учетными именами). Физическая реализация файлов во многом прозрачна. Как правило, лишь администратор базы данных работает с ее физической реализацией. На рис. 142 показаны различия между тем, как база данных представляется пользователю, и ее физической реализацией.
У каждого экземпляра SQL Server есть четыре системных базы данных (master, tempdb, msdb и model) и одна или несколько пользовательских. В одних организациях все данные содержатся в единственной пользовательской базе данных, а в других для каждой группы создана собственная база данных. Также у каждой базы данных может быть свое приложение, использующее ее. Например, в организации иногда отдельная база данных предназначена для учета продаж, другая — для платежных ведомостей, третья — для работы приложения управления делопроизводством и т. д. Некоторые приложения используют только одну базу данных, а другие могут обращаться к нескольким. На рис. 143 показаны системные и несколько пользовательских баз данных SQL Server.
Нет необходимости запускать несколько копий механизма баз данных SQL Server, чтобы предоставить доступ к базе данных на сервере нескольким пользователям. Единственный экземпляр SQL Server Standard Edition или Enterprise Edition способен обрабатывать запросы тысяч пользователей, одновременно работающих с разными базами данных. Каждый экземпляр SQL Server делает все свои базы данных доступными всем, кто подключается к нему (в зависимости от определенных для них прав доступа).
При подключении к экземпляру SQL Server соединение ассоциируется с определенной базой данных на сервере. Эта БД называется текущей. Обычно соединение устанавливается с базой данных по умолчанию, которую определяет системный администратор. Но, настроив параметры соединения из API баз данных, можно задать и другую БД. Можно переключаться с одной базы данных на другую с помощью оператора Transact SQL USE <имя_БД> или функции API, которая меняет текущий контекст базы данных.
SQL Server 2000 позволяет отключить базу данных от одного экземпляра SQL Server, а затем подключить ее к другому экземпляру или вернуть обратно. При наличии файла с базой данных можно дать SQL Server указание подключать этот файл при установлении соединения под определенным именем.
|
|
|
Поскольку есть разные производители, и разные СУБД, существует разнообразные архитектуры.
1. Однобазовая архитектура – применяется в больших СУБД (Oracle и т.д.). преимущество такой БД – управление и контролирование БД происходит с одного сервера. Недостаток в том, что с течением времени, БД становится все больше и больше. Усложняются проблемы с резервным копированием и т.д.
2. Многобазовая архитектура – основное преимущество такой архитектуры в том, что упрощается проектирование. Для каждого приложения можно фактически создать свою базу данных. СУБД как программное обеспечение может управлять большим набором баз данных – InterBase, SQL-server – десятки тысяч СУБД могут поддерживаться одним сервером, а баз как файлов м.б. много – главное, чтобы сервер их видел. Недостатком таких СУБД является то, что при записи данных организаций в разные БД, считать данные из них представляет проблему.
3. Каталоговая архитектура – Desktop’овские СУБД. Базой данных является отдельный каталог: таблицы – отдельный файл, индекс – отдельный файл. Все расположено в отдельном каталоге, которых может быть много. Есть интересные решения в MS Access в одном файле таблицы, индексы, запросы находятся в одном файле. Есть свои плюсы и минусы. Трудно настраивать ПО постороннему – он должен сидеть в этой БД. Не каждая организация даст копию своей базы данных.
|
|
|
Такие однобазовые архитектуры, как в Oracle, позволяют создавать БД, хранящихся в нескольких физических файлах. Для того, чтобы назвать базой данных нечто, состоящее из нескольких файлов, вводят понятие табличного пространства, которое может покрывать несколько файлов. Сейчас, средние СУБД (SQL-сервер, например) начинают поддерживать такого рода табличные пространства.
. Уровень внешних моделей — самый верхний уровень, где каждая модель имеет свое «видение» данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению. Например, система распределения работ использует сведения о квалификации сотрудника, но ее не интересуют сведения об окладе, домашнем адресе и телефоне сотрудника, и наоборот, именно эти сведения используются в подсистеме отдела кадров.
2. Концептуальный уровень — центральное управляющее звено. Здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически, концептуальный уровень отражает обобщенную логическую модель предметной области, для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов предметной области. Концептуальная модель является моделью логического уровня и не зависит от особенностей используемой СУБД. Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных.
3. Физический уровень — собственно данные, расположенные в файлах или в страничных структурах, расположенных на внешних носителях информации. Физическое представление БД относится к внутреннему уровню. Он описывает способы организации данных на внешних носителях информации (в виде файловых или страничных структур) и предназначен для достижения оптимальной производительности и эффективности использования ресурсов вычислительной системы. Описание физической структуры БД называется схемой хранения, а соответствующий этап проектирования БД – физическим проектированием.
|
|
|
Проектирование базы данных состоит из двух основных фаз: логического и физического моделирования. Во время фазы логического моделирования разработчик собирает требования к разрабатываемой БД, составляет описание предметной области и разрабатывает модель, не зависящую от конкретной СУБД. Во время фазы физического моделирования разработчик создает модель, оптимизированную для СУБД и конкретных приложений пользователей. В настоящее время внутренний уровень практически полностью обеспечивается СУБД. Основной акцент при проектировании БД переносится на создание модели концептуального уровня. Такая архитектура позволяет обеспечивать логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными.
Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных, и реорганизации механизма доступа к физическим данным.
Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с базой данных.
БД имеют определенную архитектуру, т.е. данные, хранимые в базе, описываются некоторой моделью представления данных. К числу классических относятся следующие модели данных: иерархическая, сетевая, реляционная.
В конце 70-х гг. были разработаны иерархические и сетевые СУБД.
Иерархические СУБД - использовали модели данных, в которой связи между данными имеют вид иерархии.
Такую архитектуру характеризует наличие однонаправленных связей между объектами базы данных, т.е. это упорядоченный набор деревьев, где есть корень-предок и потомки-поддеревья. Последняя существующая иерархическая архитектура. СУБД DIAMS. У каждого потомка имеется только один предок. В иерархической СУБД все файлы связаны между собой физическими указателями, т.е. физическими адресами, где запись находится на диске.
|
|
|
Связи между данными в иерархической модели показаны на рис. 1.1.
|
Рис. 1. 1. Представление связей в иерархической модели
В этой модели каждая запись базы данных представляла конкретную деталь, между записями существовали отношения предок-потомок, связывающие каждую часть с деталями, входящими в нее, чтобы получить доступ к данным программа могла:
1. найти конкретную деталь по ее номеру.
2. перейти вниз к 1-му потомку.
3. Перейти вверх к предку.
4. Перейти в сторону к другому потомку.
Т.о. для чтения данных из базы данных требовалось перемещение по записям. Перемещение осуществлялось за счет указателей.
Между предками и потомками автоматически поддерживается контроль целостности связей, т.е.: потомок не может существовать без родителя, а у некоторых родителей может не быть потомков. Механизмы поддержания целостности связей между записями различных деревьев отсутствуют.
Достоинства: 1)эффективное использование памяти ЭВМ. 2)модель данных удобна для работы с иерархически упорядоченной информацией.
Недостатки: 1) громоздкость для обработки информации с достаточно сложными логическими связями, а также сложность понимания для обычного пользователя. 2) не все связи между данными можно представить в виде иерархии.
Сетевые архитектуры - характеризует то, что связи между объектами базы данных не упорядочены и представляют сеть, т.е. поддеревья-потомки, могут иметь любое число корней. В таких моделях также использовались физические указатели. Последняя существующая структура подобной архитектуры- базы данных. DB Vista.
Сетевая модель данных позволяет отображать разнообразные взаимосвязи элементов данных в виде произвольного графа, обобщая тем самым иерархическую модель данных (рис. 1.2).
|
Рис. 1.2. Представление связей в сетевой модели
Сетевая БД состоит из набора записей и набора соответствующих связей. Если в иерархических структурах запись √ потомок могла иметь только одну запись предка, то в сетевой модели данных запись √ потомок может иметь произвольное число записей √ предков (сводных родителей).
╚+╩: 1)возможность эффективной реализации по показателям затрат памяти и оперативности. 2)большие возможности в смысле допустимости образования произвольных связей.
╚-╩:1)высокая сложность схемы БД, построенной на ее основе, 2) сложность для понимания и выполнения обработки информации в БД обычным пользователем. 3)ослаблен контроль целостности данных связей.
|
|
|
В 1970 г. Е.Ф.Кодд предложил, что данные можно связывать в соответствии с их внутренними логическими взаимоотношениями, а не физическими указателями. Эта теория стала революционным событием в развитии базы данных.
Кодд предложил модель данных, в которой все данные связаны в таблицы, состоящие из строк и столбцов. Эти таблицы получили название реляций, а модель стала называться реляционной.
Для работы с ней в основе лежит аппарат реляционной алгебры и реляционного исчисления, которые обеспечивают работу с данными на основе логических характеристик, а не физических указателей.
В реляционной БД пользователь указывает данные которые для него необходимы, а не то, как осуществить доступ к этим данным. Процесс перемещения по БД осуществляется автоматически. Реляционные БД выполняют и функцию каталога, в нем содержится описание всех объектов из которых состоит БД: триггеры, индекс, процедуры и таблицы.
В 1970 г. Кодд разработал правила реляционной модели:
1. Вся информация представлена в виде реляционных таблиц
2. Реляционная СУБД поддерживает три реляционных оператора (Выбор, Проектирование и Объединение), с помощью которых пользователь получает данные. Модель также поддерживает теоретико √ множественные операции (Объединение, Пересечение, Дополнение).
3. Поддерживает логическую структуру данных не зависимо от их физического представления.
4. Использует язык высокого уровня для структурирования, выполнения запросов и изменения информации.
5. Поддерживает виртуальные таблицы, обеспечивая пользователям альтернативный способ просмотра данных
6. Обеспечивает механизмы для поддержки целостности, транзакции и восстановления данных.
Элементы РМД и формы их представления приведены в таблице 1.
Таблица.1 Элементы реляционной модели
| Элемент реляционной модели | Форма представления |
| Отношение | Таблица |
| Схема отношения | Строка заголовков столбцов таблицы (заголовок таблицы) |
| Кортеж | Строка таблицы |
| Сущность | Описание свойств объекта |
| Атрибут | Заголовок столбца таблицы |
| Домен | Множество допустимых значений атрибута |
| Значение атрибута | Значение поля в записи |
| Первичный ключ | Один или несколько атрибутов |
| Тип данных | Тип значений элементов таблицы |
Итак, каждая таблица состоит из строк и столбцов, каждая строка описывает отдельный объект, каждый столбец характеризует объект.
Каждый элемент данных или значения определяется пересечением строки и столбца. Для того, чтобы знать требуемый элемент надо знать: 1) имя табл. 2) значение РК или уникального идентификатора.
Для реляционных БД характерна независимость на физическом и логических уровнях.
Свойства отношений:
1. Отношение не должно содержать двух одинаковых картежей.
2. Картежи не упорядочены сверху вниз
3. Атрибуты в заголовке располагаются произвольно
4. Значения атрибутов состоят из логически не делимых единиц.
Реляционная модель представляет собой логически связанные между собой сущности.
Типы связей:
1. один √ ко √ многим. (каждому значению одного объекта соответствует множество значений другого объекта)
2. один √ к √ одному
3. многие √ ко √ многим. (Надо разбивать)
Примером Объектно-реляционной СУБД можно считать продукты Oracle 8.x
Дальнейшим развитием реляционной базы данных является создание объектно-ориентированной базы данных и переход в работе на технологию клиент-сервер.
Система клиент-сервер - это локальная сеть, состоящая из клиентов-компьютеров, которую обслуживает компьютер-сервер.
Сервер базы данных - это программа, которая запускается на машине-сервере и обслуживает доступ клиентов к базе данных.
Сервер обслуживает запросы клиентов по доступу к базе данных,обновлению данных, защите данных, резервному копированию и т.д., сервер обслуживает сразу несколько клиентов.
Клиент - обрабатывает информацию. Возможны следующие конфигурации:
Положительным моментом организации ИС по архитектуре клиент √ сервер является удачное сочетание централизованного хранения, обслуживания и коллективного доступа к общей корпоративной информации и индивидуальной работой пользователей над персональной информацией.
Исторически первыми появились распределенные ИС с применением файл √ сервера (рис.2). Файлы БД передаются на персональные компьютеры, где производится их обработка. Недостаток такого варианта архитектуры - передача избыточных данных.
Структура распределенной ИС, построенной по архитектуре клиент √ сервер с использованием сервера БД, показана на рис..3. При такой архитектуре сервер БД обеспечивает выполнение основного объема обработки данных. Формируемые пользователем или приложением запросы поступают к серверу БД в виде инструкций языка SQL. Сервер БД выполняет поиск и извлечение нужных данных, которые затем передаются на компьютер пользователя. ╚+╩ такого подхода в сравнении с предыдущим является заметно меньший объем передаваемых данных.
Для создания и управления персональными БД и приложений, работающих с ними, используются СУБД, такие как Access и Visual FoxPro фирмы Microsoft, Paradox фирмы Borland.
Корпоративная БД создается, поддерживается и функционирует под управлением сервера БД, например Microsoft SQL Server или Oracle Server.
В зависимости от размеров организации и особенностей решаемых задач ИС может иметь одну из следующих конфигураций:
1. компьютер √ сервер, содержащий корпоративную и персональные базы;
2. компьютер √ сервер и персональные компьютеры с ПБД;
3. несколько компьютеров √ серверов и персональных компьютеров с ПБД.
Использование архитектуры клиент √ сервер дает возможность постепенного наращивания ИС предприятия, во-первых, по мере развития предприятия, во-вторых, по мере развития самой ИС.
Разделение общей БД на корпоративную БД и персональные БД позволяет уменьшить сложность проектирования БД, а значит снизить вероятность ошибок при проектировании и стоимость системы.
Важнейшим достоинством применения БД в ИС является обеспечение независимости данных от прикладных программ.
Реляционная модель данных (РМД) — логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики как теории множеств и логика первого порядка.
На реляционной модели данных строятся реляционные базы данных.
Реляционная модель данных включает следующие компоненты:
§ Структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений.
§ Аспект (составляющая) целостности — отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостностиуровня домена (типа данных), уровня отношения и уровня базы данных.
§ Аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).
Кроме того, в состав реляционной модели данных включают теорию нормализации.
Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину «отношение» часто встречается слово таблица. Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, авизуальное представление отношения на бумаге или экране. Некорректное и нестрогое использование термина «таблица» вместо термина «отношение» нередко приводит к недопониманию. Наиболее частая ошибка состоит в рассуждениях о том, что РМД имеет дело с «плоскими», или «двумерными» таблицами, тогда как таковыми могут быть только визуальные представления таблиц. Отношения же являются абстракциями, и не могут быть ни «плоскими», ни «неплоскими».
Для лучшего понимания РМД следует отметить три важных обстоятельства:
§ модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;
§ для реляционных баз данных верен информационный принцип: всё информационное наполнение базы данных представлено одним и только одним способом, а именно — явным заданием значений атрибутов в кортежах отношений; в частности, нет никаких указателей (адресов), связывающих одно значение с другим;
§ наличие реляционной алгебры позволяет реализовать декларативное программирование и декларативное описание ограничений целостности, в дополнение к навигационному (процедурному) программированию и процедурной проверке условий.
Принципы реляционной модели были сформулированы в 1969—1970 годах Э. Ф. Коддом (E. F. Codd). Идеи Кодда были впервые публично изложены в статье «A Relational Model of Data for Large Shared Data Banks»[1], ставшей классической.
Строгое изложение теории реляционных баз данных (реляционной модели данных) в современном понимании можно найти в книге К. Дж. Дейта. «C. J. Date. An Introduction to Database Systems» («Дейт, К. Дж. Введение в системы баз данных»).
Наиболее известными альтернативами реляционной модели являются иерархическая модель, и сетевая модель. Некоторые системы, использующие эти старые архитектуры, используются до сих пор. Кроме того, можно упомянуть об объектно-ориентированной модели, на которой строятся так называемые объектно-ориентированные СУБД, хотя однозначного и общепринятого определения такой модели нет.
| Основные сведения об архитектуре реляционной СУБД | ||||||||||
SQL Server 2000 хранит информацию в базах данных. На физическом уровне БД состоит из двух или более файлов, размещенных на одном или нескольких дисках. Такая структура БД видна только администраторам БД, пользователи видят БД как единое целое. Как правило, выбор оптимального способа физической организации БД, в частности размещения на дисках файлов, из которых состоит БД, входит в обязанности администратора БД.
Системные и пользовательские базы данных
При установке одного экземпляра SQL Server 2000 на компьютер создаются четыре системные БД.
Табл. 1.4. Системные базы данных SQL Server 2000
Кроме того, у каждого установленного экземпляра SQL Server 2000 имеется одна или несколько пользовательских БД. Вместе с SQL Server 2000 поставляются пользовательские БД pubs и Northwind, предназначенные для обучения работе с SQL Server 2000. При достаточных системных ресурсах каждый установленный экземпляр SQL. Server 2000 поддерживает одновременную работу нескольких тысяч пользователей со многими БД (рис. 1_5).
|
|
|
|
