Корпоративные СУБД. Основные характеристики, особенности использования

 

Рисунок 1 – Графическое изображение иерархической структуры БД

 

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

К каждой записи базы данных существует только один (иерархический) путь от корневой записи. Например, как видно из рис.2, для записи С4 путь проходит через записи А и В3.

Сетевая модель данных.

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

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

На рис. 2 изображена сетевая структура базы данных в виде графа.

 

Рисунок 2 – Графическое изображение сетевой структуры

 

Реляционная модель данных.

Понятие реляционный (англ. relation – отношение) связано с разработками известного американского специалиста в области систем баз данных Е. Кодда.

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

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

- каждый  элемент таблицы – одни элемент  данных;

- все  столбцы в таблице однородные, т.е. все элементы в столбце  имеют одинаковый тип (числовой, символьный и тд.) и длину;

- каждый  столбец имеет уникальное имя;

- одинаковые  строки в таблице отсутствуют;

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

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

 

№ личного дела	Фамилия	Имя	Отчество	Дата рождения	Группа
25689	Иванов	Иван	Иванович	01.01.80	111
25231	Петрова	Мария	Васильевна	08.04.75	112
25549	Сидоров	Василий	Петрович	14.02.77	111

Рисунок 3 – Пример реляционной таблицы

 

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

Поле, каждое значение которого однозначно определяет соответствующую запись, называется простым ключом (ключевым полем). Если записи однозначно определяются значениями нескольких полей, то такая таблица базы данных имеет составной ключ. В примере, показанном на рис.4, ключевые полем таблицы является «№ личного дела».

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

Пример 2. На рис.4 показан пример реляционной модели, построенной на основе отношений: СТУДЕНТ, СЕССИЯ, СТИПЕНДИЯ.

 

Рисунок 4 – Пример реляционной модели

 

Таблицы баз данных, как правило, допускают работу с гораздо большим количеством разных типов данных. Так, например, базы данных Microsoft Access работают со следующими типами данных.  Текстовый – тип данных, используемый для хранения обычного неформатированного текста ограниченного размера (до 255 символов). Числовой – тип данных для хранения действительных чисел.   Поле Мемо – специальный тип данных для хранения больших объемов текста (до 65 535 символов). Физически текст не хранится в поле. Он храниться в другом месте базы данных, а в поле храниться указатель на него, но для пользователя такое разделение заметно не всегда.    Дата/время – тип данных для хранения календарных дат и текущего времени.            Денежный – тип данных для хранения денежных сумм. Теоретически, для их записи можно было бы пользоваться и полями числового типа, но для денежных сумм есть некоторые особенности (например, связанные с правилами округления), которые делают более удобным использование специального типа данных, а не настройку числового типа.   Счетчик – специальный тип данных для уникальных (не повторяющихся в поле) натуральных чисел с автоматическим наращиванием. Естественное использование – для порядковой нумерации записей. Логический  – тип для хранения логических данных (могут принимать только два значения, например Да или Нет).      Гиперссылка – специальное поле для хранения адресов URL Web–объектов Интернета. При щелчке на ссылке автоматически происходит запуск браузера и воспроизведение объекта в его окне.    Мастер подстановок – это не специальный тип данных. Это объект, настройкой которого можно автоматизировать ввод данных в поле так, чтобы не вводить их вручную, а выбирать их из раскрывающегося списка.

 

2.Корпоративные  сети и базы данных

 

Эпитет "корпоративный" часто используется для характеристики продуктов вычислительных систем. Корпоративными могут быть названы почти все типы элементов вычислительной системы, от концентраторов и маршрутизаторов до серверов и операционных систем - разве что сетевые адаптеры редко удостаиваются такой чести. Эта характеристика также применяется и к системам управления базами данных : Oracle, Informix, Sybase, DB2 - все это примеры СУБД, которые часто называются корпоративными. Имеется несколько устоявшихся признаков корпоративности, и их можно применять универсально, как к аппаратуре, так и к программным продуктам, в том числе и базам данных. Наличие этих признаков гарантирует хорошую работу продуктов в корпоративной сети. Эти признаки тесно связаны с особенностями и спецификой корпоративных сетей, поэтому для четкого формулирования требований к корпоративным базам данных необходимо ясное понимание особенностей корпоративных сетей.           Корпоративные сети интересны для специалистов, занимающихся системами управления базами данных и по другой причине. В широком смысле вычислительная сеть тождественна вычислительной системе - к ней относятся компьютеры, коммуникационное оборудование, операционные системы, системы управления базами данных и приложения. Сеть в узком смысле - это программно-аппаратный комплекс, организующий надежную и быструю доставку сообщений между взаимодействующими приложениями. Для базы данных сеть является универсальной транспортной платформой, которая берет на себя выполнение рутинных коммуникационных задач, подобно тому, как файловая система освобождает СУБД от необходимости заниматься низкоуровневыми вопросами форматирования диска, физическими и логическими аспектами организации файлов и т.п.  
Многие СУБД для достижения высоких эксплуатационных показателей могут подменять и "исправлять" существующие операционные системы.  В англоязычной литературе этот вид сетей чаще называется "enterprise-wide networks" (дословно - сеть масштаба предприятия), а в нашей стране прижился другой термин иностранного происхождения - корпоративные сети, что, на наш взгляд, больше соответствует самой сути таких сетей. Появление корпоративных сетей - это хорошая иллюстрация известного философского постулата о переходе количества в качество. При объединении отдельных сетей крупного предприятия, имеющего подразделения в различных городах и странах, в единую сеть, многие количественные характеристики объединенной сети часто превосходят некоторый критический порог, за которым начинается новое качество. При этом число пользователей и компьютеров может измеряться тысячами, число серверов - превышать несколько сотен, число записей в базе данных - несколько миллионов, а расстояния между сетями могут оказаться такими, что использование глобальных связей становится необходимость. Корпоративные сети возникли не на пустом месте. Сначала на предприятиях создавались небольшие локальные сети, используемые только небольшой группой сотрудников - так называемые сети рабочих групп, затем они вырастали в сети отделов и кампусов (площадок).

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

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

• масштабируемость, то есть способность одинаково хорошо работать в большом диапазоне различных количественных характеристик сети,
• совместимость с другими продуктами, то есть способность работать в сложной гетерогенной среде интерсети в режиме plug-and-play.

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

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

2.1.Пользователи  баз данных

После создания логинов следующая  задача администратора — спуститься на уровень базы данных и создать объекты пользователей базы данных. Пользователи баз данных — это специальные объекты, которые создаются на уровне базы данных и используются для предоставления разрешений в базе данных (на таблицы, представления, хранимые процедуры). Для пользователей используется термин database users(или просто users), в отличие от логинов (logins) — учетных записей для подключения к SQL Server. Логины и пользователи баз данных — это совершенно разные объекты.        Теоретически такое решение, видимо, вполне возможно. Но на практике разделение логинов и пользователей баз данных обеспечивает большую гибкость. Например, пользователь, который входит от имени одного и того же логина, сможет работать в разных базах данных от имени разных пользователей.

Создать пользователя базы данных можно:

1.      на графическом экране из контейнера Имя_базы_данных | Security | Users в Management Studio;

2.      при помощи команды CREATE USER (хранимая процедура sp_adduser, которая использовалась для этой цели в предыдущих версиях SQL Server, оставлена только для обеспечения обратной совместимости). Например, команда на создание пользователя User1, которому будет соответствовать логин SQL Server Login1 со схемой по умолчанию dbo, может выглядеть так:

CREATE USER User1 FOR LOGIN Login1 WITH DEFAULT_SCHEMA = dbo;

При создании пользователя вам нужно  будет указать:

1.      имя пользователя (User name), к которому применяются те же правила, что и для других объектовSQL Server;

2.      логин (SQL Server или Windows), которой будет назначен пользователю этой базы данных. После создания пользователя назначенный ему логин изменять будет нельзя. Можно создать пользователя, которому не будет назначен никакой логин (при помощи переключателя Without login). Такому пользователю уже не получится назначить логин. Пользователи этого типа — без логинов — используются только для дополнительной настройки безопасности в Service Broker. Отметим также, что если какой-то логин уже был назначен пользователю, то другому пользователю одновременно назначить его нельзя;