Функциональная модель - данные
Cтраница 1
Функциональная модель данных использует такой подход для определения объекта. Вместо того чтобы представлять объект записью с определенным содержанием или же кортежем в В-дереве, функциональная модель сообщает, какие функции ( или операции) определены на этом объекте. Представление объекта - это дело реализации, и оно определяется на более низком уровне абстракции. Этот же принцип используется в предложениях ANSI / SPARC ( Комитета по планированию Американского национального института стандартов) по отделению деталей кодасиловских структур хранения данных от концептуальной схемы ( см. гл. [1]
 |
Архитектура схемы ANSI / SPARC. [2] |
С другой стороны, если мы реализуем концептуальную схему функциональной модели данных, используя существующую реляционную СУБД, например, INGRES, то способ такой реализации становится внутренней схемой. Основная идея заключается в том, что большое число внешних представлений отображается в единственную концептуальную схему, Это обеспечивает ее непротиворечивость, в то же время изолирует пользователей от деталей реализации. Эти детали могут быть изменены для улучшения эффективности. [3]
В действительности этот метод представляет функцию, сопоставляющую владельцу набор, т.е. многозначную функцию, такую как используемые в функциональной модели данных. Набор может, конечно, иметь нуль, один или более элементов; иными словами, соответствующее множество может быть пустым или содержать единственный элемент или же несколько элементов. [4]
Мигры для перехода по ссылкам, а сами ссылки остаются скрытыми от прикладного программиста. Та же идея используется, конечно, и ь функциональной модели данных, но в схеме на Адаплексе ( см. рис. 10.3) функции, следующие по ссылкам от записи к записи, выглядят как обычные селекторы атрибутов записи, и там они перечислены все вместе, а не описаны каждая в отдельности. [5]
Главный смысл MANDATORY AUTOMATIC заключается в обеспечении существенной поддержки целостности. С точки зрения функциональной модели данных это эквивалентно тому, что соответствующая функция является всюду определенной, а не частичной. Рассматриваемое ограничение также дает нам возможность использовать способ размещения ( LOCATION) VIA, поскольку член всегда будет иметь владельца, и поэтому его местоположение всегда известно. [6]
Мы уже рассматривали функциональный язык запросов FQL, разработанный Бунеманом. Этот язык основан на применении ( аппликации) функций к потокам объектов. Как и FQL, функциональная модель данных оперирует с понятием объекта и функции из объектов в объекты, но она использует теоретико-множественную терминологию, а не терминологию потоков. Запросы записываются на языке Даплекс ( Daplex), в стиле исчисления предикатов, а не аппликативного программирования. Тем не менее этот язык использует композицию функций, результатом которой являются множества, что очень похоже на композицию функций в языке FQL. Существенное преимущество функциональной модели данных состоит в том, что она объединяет вычислительную способность аппликативного программирования с возможностями определения и абстракции данных, которые обеспечиваются стандартными языками для работы с базами данных. [7]
Естественно проблемы, связанные с выбором пути доступа, возникают не только в реляционных базах данных, но и в любых системах, где допускаются запросы достаточно высокого уровня. В отличие от базы данных, поддерживающей реляционную модель, в которой связи межг ду отношениями не представлены явно, в графо-теорети-ческих моделях для решения этой проблемы не требуется привлечение каких-либо дополнительных средств: семантических графов, графов отношений, фреймов или взаимосвязей сравнимости. Рассмотрим, например, как подобная проблема может быть решена в базе данных с функциональной моделью данных. [8]
В тех случаях, когда какая-либо модель данных рассматривается как серьезная альтернатива реляционной модели, она также должна иметь четко определенное концептуальное представление для того, чтобы на ее основе создать базу данных. Наличие такого представления упрощает размышления о предполагаемых операциях. Это необходимо для эффективной работы программистов и конечных пользователей. В моделях данных, в которых используются такие понятия, как объекты ( entities) и отношения, или в функциональных моделях данных такое представление если и обсуждается, то очень редко. В таких моделях часто вообще нет операторов. Тем не менее такие модели могут быть полезны при некоторых способах анализа типов данных, который приходится делать при создании новых баз данных, и на совсем ранних этапах работы, когда предварительно на неформальном уровне определяются способы ее организации. Все это приводит к вопросу: а что же это такое - модель данных. [9]
Кроме того, появляется меньше ошибок во время исполнения неправильных программ. Эта информация ценна и для верификации программ. В случае баз данных появляется богатое многообразие типов данных. Поэтому нужны дальнейшие исследования, чтобы объединить обшиость описания типов, имеющуюся в НОРЕ и ML, с богатством иерархии типов и подтипов, описываемых функциональной моделью данных и реляционной моделью, которые вводятся во второй половине этой книги. [10]
Недавние разработки улучшают положение в этой области. Бунеман разработал очень простой и эффективный доступ к базе данных SEED CODASYL посредством функционального языка FQL. Сие-1 тема Астрид [46] позволяет получать ответы на сложные запросы в расширенной реляционной алгебре, эффективно пользуясь кодасиловскими связями между записями. В [117] показано, как представить схему Кодасил в виде набора виртуальных записей, соответствующих отношениям, и как применить методы обработки реляционных запросов в языках типа SQL. Наконец, функциональная модель данных ( ФМД) дает теоретическое обоснование кодасиловской модели. Поскольку ФМД можно отобразить и на QUEL, эта модель может стать основой для общего языка запросов в распределенной базе данных, объединяющей локальные кодасиловские и реляционные базы. [11]
Мы уже рассматривали функциональный язык запросов FQL, разработанный Бунеманом. Этот язык основан на применении ( аппликации) функций к потокам объектов. Как и FQL, функциональная модель данных оперирует с понятием объекта и функции из объектов в объекты, но она использует теоретико-множественную терминологию, а не терминологию потоков. Запросы записываются на языке Даплекс ( Daplex), в стиле исчисления предикатов, а не аппликативного программирования. Тем не менее этот язык использует композицию функций, результатом которой являются множества, что очень похоже на композицию функций в языке FQL. Существенное преимущество функциональной модели данных состоит в том, что она объединяет вычислительную способность аппликативного программирования с возможностями определения и абстракции данных, которые обеспечиваются стандартными языками для работы с базами данных. [12]
Страницы: 1