Проектирование баз данных и работа с ними Веб-приложений. Введение в БД, SQL Server, ADO.NET

9.1.2.1.2. Сетевые

Если структура данных оказывалась сложнее, чем обычная иерархия, простота структуры иерархической базы данных становилась ее недостатком [16].

Основные принципы сетевой модели данных были разработаны в середине 60-х годов, эталонный вариант сетевой модели данных описан в отчетах рабочей группы по языкам баз данных (COnference on DAta SYstem Languages) CODASYL в 1971 г. [12].

Сетевая модель данных определяется в тех же терминах, что и иерархическая.

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

Основным недостатком сетевых баз данных (как и иерархических) является то, что они очень "жесткие" [16]. Изменение структуры базы данных обычно означало перестройку всей базы данных.

9.1.2.1.3. Реляционные

Недостатки иерархической и сетевой моделей привели к появлению новой, реляционной модели данных, созданной Э. Коддом в 1970 году [16]. Кодд первым предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение) и показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение [1].

Реляционная модель данных (РМД) – логическая модель данных, прикладная теория, описывающая структурный аспект, аспект целостности и аспект обработки данных в реляционных базах данных [17]:

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

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

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

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

В ответ на неправильное использование термина "реляционный" Кодд в 1985 году написал статью, где сформулировал 12 правил, которым должна удовлетворять любая база данных, претендующая на звание реляционной [15]:

1. Правило информации. Вся информация в базе данных должна быть предоставлена исключительно на логическом уровне и только одним способом – в виде значений, содержащихся в таблицах.
2. Правило гарантированного доступа. Логический доступ ко всем и каждому элементу данных (атомарному значению) в реляционной базе данных должен обеспечиваться путем использования комбинации имени таблицы, первичного ключа и имени столбца.
3. Правило поддержки недействительных значений. В реляционной базе данных должна быть реализована поддержка недействительных значений, которые отличаются от строки символов нулевой длинны, строки пробельных символов и от нуля или любого другого числа и используются для представления отсутствующих данных независимо от типа этих данных.
4. Правило динамического каталога, основанного на реляционной модели. Описание базы данных на логическом уровне должно быть представлено в том же виде, что и основные данные, чтобы пользователи, обладающие соответствующими правами, могли работать с ним с помощью того же реляционного языка, который они применяют для работы с основными данными.
5. Правило исчерпывающего подъязыка данных. Реляционная система может поддерживать различные языки и режимы взаимодействия с пользователем, однако должен существовать, по крайней мере, один язык, операторы которого можно представить в виде строк символов в соответствии с некоторым четко определенным синтаксисом и который в полной мере поддерживает следующие элементы:
   • определение данных;
   • определение представлений;
   • обработку данных (интерактивную и программную);
   • условия целостности;
   • идентификация прав доступа;
   • границы транзакций (начало, завершение и отмена).
6. Правило обновления представлений. Все представления, которые теоретически можно обновить, должны быть доступны для обновления.
7. Правило добавления, обновления и удаления. Возможность работать с отношением как с одним операндом должна существовать не только при чтении данных, но и при добавлении, обновлении и удалении данных.
8. Правило независимости физических данных. Прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться нетронутыми при любых изменениях способов хранения данных или методов доступа к ним.
9. Правило независимости логических данных. Прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться нетронутыми при внесении в базовые таблицы любых изменений, которые теоретически позволяют сохранить нетронутыми содержащиеся в этих таблицах данные.
10. Правило независимости условий целостности. Должна существовать возможность определять условия целостности, специфические для конкретной реляционной базы данных, на подъязыке реляционной базы данных и хранить их в каталоге, а не в прикладной программе.
11. Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.
12. Правило единственности. Если в реляционной системе есть низкоуровневой язык (обрабатывающий одну запись за один раз), то должна отсутствовать возможность использования его для того, чтобы обойти правила и условия целостности, выраженные на реляционном языке высокого уровня (обрабатывающем несколько записей за один раз).

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

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

9.1.2.1.4. Постреляционные

Постреляционная модель данных представляет собой расширенную реляционную модель, в которой отменено требование атомарности атрибутов [12]. Поэтому постреляционную модель называют "не первой нормальной формой " (NF2) или "многомерной базой данных". Она использует трехмерные структуры, позволяя хранить в полях таблицы другие таблицы. Тем самым расширяются возможности по описанию сложных объектов реального мира. В качестве языка запросов используется несколько расширенный SQL, позволяющий извлекать сложные объекты из одной таблицы без операций соединения.

Существует несколько коммерческих постреляционных СУБД, самыми известными из которых являются системы Adabas, Pick и Universe.

9.1.2.1.5. Объектно-ориентированные

В основу объектной модели положена концепция объектно-ориентированного программирования, в которой данные представляются в виде набора объектов и классов, связанных между собой родственными отношениями, а работа с объектами осуществляется с помощью скрытых (инкапсулированных) в них методов [1].

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

Некоторые объектно-ориентированные базы данных разработаны для плотного взаимодействия с такими объектно-ориентированными языками программирования как Python, Java, C#, Visual Basic .NET, C++, Objective-C и Smalltalk; другие имеют свои собственные языки программирования (например, Cache Object Script).

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

Примеры объектно-ориентированных СУБД: Cache, GemStone, ONTOS.

9.1.2.1.6. Объектно-реляционные

В последнее время производители СУБД стремятся соединить два этих подхода и проповедуют объектно-реляционную модель представления данных [1]. Примеры таких СУБД – IBM DB2 for Common Servers, Oracle 10, SQL Server 2008.

Один из способов объединения возможностей реляционного и объектно-ориентированного подхода к управлению данными предложил известный американский ученый Майкл Стоунбрейкер [12]. Согласно его воззрениям реляционную СУБД нужно просто дополнить средствами доступа к сложным данным. При этом ядро СУБД не требует переработки, как в случае с SQL3, и сохраняет все присущие реляционным системам достоинства. Объектные расширения реализуются в виде надстроек, которые динамически подключаются к ядру.