Под моделью данныхпонимают некоторую формальную теорию представления и обработки данных, включающую методы описания типов и логических структур данных (аспект структуры), методы манипулирования данными (аспект манипуляции) и методы описания и поддержки целостности данных (аспект целостности).
Модель данных – это способ моделировать, инструмент. Модель базы данных – это результат использования этого способа для проектирования базы данных.
Выделяют 5 моделей данных: иерархическая, сетевая, (не)реляционная и объектно-ориентированную. К ранним моделям данных принято относить иерархическую и сетевую модели. СУБД, реализующие их, появились первыми и заложили основы технологий баз данных. Общие черты ранних моделей:
- «вырастание» из практики. Сначала появлялись СУБД, а потом формулировались положения соответствующей модели данных. Как следствие, в основе иерархических и сетевых СУБД не лежит строгий и формальный матем. аппарат, а модели данных имеют скорее описательный характер.
- организация доступа к данным на уровне отдельных записей. Иерархическая и сетевая модели предполагают операции с отдельными записями – поиск конкретной записи, переходы к следующей/предыдущей записям и так далее. Соответственно, и языки для работы с данными в иерархических и сетевых – императивные (после SQL была добавлена).
- слаборазвитая (по сравнению с реляционными БД) система ограничений целостности.
Иерархическая модель является первой и появилась вместе с наиболее известной СУБД, ее реализующей – системой IMS (Information Management System) разработки компании IBM. Эта СУБД была выпущена в 1968 году и существует и развивается до сих пор. Данные организуются в виде иерархии. Основными понятиями данной модели являются база данных, сегмент и поле.
Поле – это минимальная единица данных, которая представляет собой неделимое целое. То есть, например, если нам нужно хранить в поле адрес, то выделить в нем элементы (например, регион, город, улицу) и получать доступ к ним средствами СУБД невозможно, это нужно реализовывать на уровне прикладной программы. Набор полей образует сегмент (или запись). В сегменте должен быть определен ключ – поле или набор полей, значение которого может однозначно идентифицировать конкретный экземпляр сегмента. Сегменты образуют между собой связи типа «родитель-потомок». При этом у сегмента может быть произвольное количество потомков, но только один родитель. В вершине иерархии корневой сегмент - без родителя. Все сегменты в совокупности образуют древовидную структуру, которая и является базой данных. Схема базы данных – это набор таких деревьев.
СУБД, реализующие сетевую модель данных, появились почти одновременно с иерархическими СУБД. Появилась в 1971 году. Наиболее известная СУБД, реализующая архитектуру CODASYL, IDMS (принадлежит компании Computer Associates и продается под наименованием CA IDMS/DB).
Сетевую модель данных можно считать расширением иерархической модели. Если в последней у записи-потомка может иметься только один предок, то в сетевой – произвольное количество. Сама СУБД представляет собой наборы экземпляров записей и наборы экземпляров связей. Т.е., сетевая СУБД допускает наличие между двумя наборами экземпляров записи любого количества связей. При этом две записи могут меняться ролями родителя и потомка. Хотя, структура базы данных усложняется, это с лихвой окупается за счет исключения необходимости дублирования данных, которое происходило бы при моделировании сложных связей в иерархической БД. Как и иерархические, сетевые СУБД предполагают манипуляцию данными на уровне отдельных записей. Типичные операции: поиск записей, создание, уничтожение, изменение, включение в связь, исключение из связи, изменение связи.
Т.о., сетевые СУБД предоставляют больше возможностей, но одновременно, требуют больших вычислительных ресурсов и более сложных алгоритмов для работы с данными.
Реляционная модель данных ведет свою историю с публикации в 1970 году работы Эдгара Кодда «Реляционная модель данных для больших совместно используемых банков данных». Она основывается на математическом «фундаменте». Ключевое понятие реляционной модели – отношение (англ. Relation) определено в терминах теории множеств. Соответственно, операции над отношениями также основываются на операциях над множествами. Сам Кодд предложил восемь операций, которые, в совокупности с отношениями, образуют реляционную алгебру. Предложенный набор операций избыточен, так как часть операций может быть выражена через другие. Но множество операций выбрано исходя из соображений удобства их использования. Уже из приведенного описания понятно, что реляционная модель ориентирована на работу с множествами записей, а не с отдельными экземплярами. Этим она радикально отличается от остальных моделей данных. Простота и мощь реляционной модели позволили реализующим ее СУБД завоевать первенство на рынке средств управления базами данных и вытеснить остальные решения на периферию.
Объектно-ориентированный подход. БД представляет собой набор объектов произвольного типа. Основное преимущество объектно-ориентированного подхода – повышение уровня абстракции. Однако реализация и использование объектно-ориентированных СУБД наталкивается на ряд трудностей. В первую очередь, стоит отметить, что, несмотря на довольно длительный период развития, объектно-ориентированный подход не вполне устоялся в теоретическом плане, ключевые понятия разные специалисты могут определять по-своему, а каждый язык программирования реализует их со своей спецификой. Второй проблемой на пути создания и использования объектно-ориентированных баз данных является проблема производительности. ООСУБД отстают от реляционных систем по эффективности, и разрыв этот вряд ли будет преодолен.
Наконец, возможно главным возражением является то, что объектно-ориентированные СУБД вообще не являются СУБД. В самом деле, основной целью создания баз данных как таковых было отделение данных от использующих их приложений. То есть, предполагается, что данными в базе данных можно воспользоваться из различных приложений для решения различных задач. Очевидно, что для объектно-ориентированных СУБД это вряд ли выполнимо – далеко не все приложения написаны на объектно-ориентированных языках, а если даже и написаны – не исключено, что какие-то положения объектно-ориентированного подхода реализованы в них иначе.
Наконец, имеются и серьезные вопросы с реализацией ограничений целостности данных. Их не всегда можно сформулировать на уровне базы данных, а реализация их на уровне приложения делает данные уязвимыми для возможных ошибок, если доступ осуществляется помимо приложения.
Так что, можно сказать, что объектно-ориентированные СУБД не реализуют функции, которые разработчики привыкли требовать от систем управления базами данных, и в этом, пожалуй, и заключается причина их низкой популярности.
Нереляционные СУБД – относительно недавнее пополнение множества систем для работы с данными. Их появление и растущая популярность вызваны, главным образом, развитием сетевых технологий и приложений. Современные сетевые приложения, наиболее яркими примерами которых являются социальные сети, должны поддерживать доступ одновременно для миллионов пользователей и хранить терабайты различных данных. К сожалению, при всех достоинствах, реляционные СУБД не могут обеспечить работу в таком режиме. Именно эта ситуация и вызвала значительный рост количества решений, позволяющих обеспечить эффективное хранение и обработку данных для высоконагруженных сетевых приложений. И хотя к ним в еще большей степени применимы замечания, сделанные для объектно-ориентированных СУБД, которые ставят под сомнение их статус СУБД, популярность нереляционных (или NoSQL) систем велика и растет.
