При ограниченном числе объектов и отношений между ними предметные области достаточно эффективно описываются реляционными языками и семантическими сетями. [c.196]
Будем считать, что в качестве исходных объектов выступают описания ситуаций на некотором реляционном языке, например, на языке ситуационного управления. Пусть S — некий фрагмент описания ситуации. Если известно, что для какой-то ситуации S надо принимать решение U, а фрагмент S входит в описание ситуации S, то гипотеза S = >+U имеет право на существование. Если на основании анализа положительных примеров мы убеждаемся, что фрагмент S имеется в большинстве описаний ситуаций, для которых принимается решение U, то достоверность гипотезы S =>+ / должна увеличиваться. Она растет особенно сильно, если этот фрагмент отсутствует в отрицательных примерах, соответствующих случаю принятия других решений по управлению, отличных от U. Если же это не так, то можно считать, что принятие других решений, отличных от U, при наличии фрагмента S, влияет на некоторый фрагмент S , играющий роль тормоза для S. Идеология такого типа может распространяться на тормоз второго и более высоких уровней (тормоз тормоза и т. д.). Тормозы порождают отрицательные гипотезы S => /. [c.186]
В реляционной БД основной структурной единицей данных является таблица данных, состоящая из полей. Таблица имеет линейную структуру данных, так называемый плоский файл. В общем случае логическая структура реляционной БД рассматривается как совокупность объектов БД таблицы, формы, запросы, отчеты, макросы и модули. Между таблицами БД устанавливаются связи, с помощью которых реализуются различные комбинации структур данных, используются реляционно-полные языки манипулирования данными (языки запросов). Реляционные модели данных являются наиболее распространенными и перспективными для БД различного масштаба и сферы действия, они реализованы для всех классов ЭВМ, особенно много различных моделей реляционных СУБД для персональных вычислительных машин. [c.526]
Язык SQL является стандартом языков запросов большинства реляционных СУБД, обеспечивает как определение данных, так и манипулирование данными. Любой запрос QBE транслируется в запрос SQL, но не наоборот. [c.675]
С помощью определенности информации обеспечивается процесс коммуникации. Поскольку использование таблиц никакого нового языка не предполагает, а довольствуется естественными (в таблицу помещается обыкновенный текст), определенность в известном смысле слова можно считать уже заданной. Она требует уточнения лишь тогда, когда в качестве значений используются, скажем, порядковые номера. Это весьма характерно при работе с идентификаторами. Если мы обозначили наших контрагентов порядковыми номерами, очевидно, что каждая цифра должна отождествляться с определенным контрагентом и должно быть известно, какая цифра с каким контрагентом отождествлена. Обычно такой список контрагентов помещается в отдельную таблицу, которая по идентификатору устанавливает отношение с основной. Для реляционного способа отображения информации это азбучные истины, но в нашем случае они не имеют значения, поскольку мы предполагаем наличие всей информации в одной таблице. [c.162]
Современная СУБД содержит в своем составе программные средства создания баз данных, средства работы с данными и дополнительные, сервисные средства (рис, 4.10) [48]. С помощью средств создания БД проектировщик, используя язык описания данных (ЯОД), переводит логическую модель БД в физическую структуру, а на языке манипуляции данными (ЯМД) разрабатывает программы, реализующие основные операции с данными (в реляционных БД - это реляционные операции). При проектировании привлекаются визуальные средства, т.е. объекты, и программа-отладчик, с помощью которой соединяются и тестируются отдельные блоки разработанной программы управления конкретной БД. [c.159]
Средства генерации схем проектируемой базы данных МИС для конкретной информационной модели проекта МИС используют язык запросов (SQL-скрипт) для создания таблиц, хранимых процедур и триггеров, задающих семантику реляционных отношений объектов базы данных МИС. [c.206]
Многие разработчики сегодня выделяют ряд негативных моментов в реляционной модели, в частности, невозможность представления и манипулирования данными сложной структуры (тексты, пространственные данные). Это заставляет вести работы по совершенствованию систем второго поколения или созданию новой модели данных. Для СУБД третьего поколения характерны использование предложений, касающихся управления объектами и правилами, управления распределенными данными, языков программирования четвертого поколения (4GL), технологии тиражирования данных и других достижений в области обработки данных. Сегодня СУБД этого поколения применяются в деловой сфере достаточно активно не только как незаконченные технические решения, а как готовые продукты, дающие возможности разработчикам активно использовать мощные средства управления данными. [c.472]
Важно, что для выполнения действий над базой пользователю достаточно обладать элементарным запасом языковых средств, чтобы понимать и использовать возможности всего языка. Синтаксис языка прост, тем не менее охватывает широкий спектр сложных операций. Это достигается за счет использования одинаковых операций для извлечения, манипулирования, определения и контроля данных. Операции языка подражают ручному манипулированию таблицами, сохраняя при этом все требования реляционной модели. Формирование операций должно следовать процессу рассуждений пользователя, предоставляя тем самым свободу при их построении. Архитектура языка QBE направлена на удовлетворение сформулированных требований. [c.479]
Первый стандарт этого языка — SQL-89 появился в 1989 г. и поддерживался практически всеми коммерческими реляционными СУБД. Он имел весьма общий характер и допускал широкое толкование. Достоинствами SQL- 9 можно считать стандартизацию синтаксиса и семантики операторов выборки и манипулирования данными, [c.480]
Несмотря на то, что реляционные СУБД давно и прочно заняли основные позиции на рынке программного обеспечения по обработке данных, в этой области остается много нерешенных проблем. Во-первых, это касается нового стандарта языка SQL-Ъ, возможности которого должны быть расширены за счет включения в него возможности определения триггеров, работы с объектами, расширения типов данных. Во-вторых, движение в сторону концепции открытых систем предполагает пересмотр организации серверов баз данных, допустив в них внутреннюю параллельность. В-третьих, решение проблемы использования старых баз данных в рамках новых программных продуктов. [c.498]
Отдельный раздел в СУБД следующего поколения занимают объектно-ориентированные базы данных. Возникновение данного направления определяется, прежде всего, потребностями практики необходимостью разработки сложных информационных систем, для которых технология предшествующих баз данных не была удовлетворительной. В таких СУБД должны быть решены проблемы поддержки иерархии и наследования типов, возможность управления сложными объектами. Однако для решения этих задач существуют значительные ограничения, а именно отсутствие общепринятой объектно-ориентированной модели данных, декларативного языка запросов и т. п. Разработчики в области баз данных определяют объектно-реляционным [c.498]
Потребность в эффективной обработке учетно-эконо-мической информации, для которой характерны простые логические и арифметические преобразования больших объемов информации, привела к развитию новых программных и технических средств. Поиски этих средств привели к созданию реляционных СУБД, обеспечивающих пользователям простой язык общения с хранимыми данными. Особенности реляционного подхода заключаются в том, что информационное содержание данных рассматривается вне всякой связи со способами их представления в памяти, и база данных представляется в виде набора изменяющихся во времени отношений, ко- [c.115]
На втором этапе производится построение концептуальной модели. В качестве исходной информации используются результаты семантического (информационного) анализа учетных данных, формы и содержание входных и выходных документов, а также виды запросов к БД, что образует множество описаний внешних моделей. В качестве языка, на котором формализуются объекты и связи, описываемые концептуальной моделью, целесообразно выбрать язык реляционной теории данных [37, с. 203]. [c.117]
Теория и практика проектирования баз данных в настоящее время показывает, что в качестве формального языка для описания концептуальной модели учетных данных целесообразно воспользоваться аппаратом теории отношений [22, с. 152]. Используя теорию отношений, будем стремиться построить так называемую реляционно-сетевую концептуальную модель данных по учету товаров. Эта модель не относится к числу моделей данных, непосредственно используемых в существующих языках определения данных, хотя и тесно связана с некоторыми из них. В настоящей работе она служит только для представления информационных структур учетных данных. Реляционно-сетевая модель позволяет наглядно представить объекты учета, их свойства и связи между объектами. [c.120]
Отношения. Отношения фиксируют связи между понятиями и именами, а также между другими функциональными группами языка, о которых речь пойдет ниже. В отличие от других функциональных групп, отношения могут задаваться не только с помощью лексики языка, но и с помощью грамматических связей, выражаемых средствами языка. В силу большой важности отношений для построения языка ситуационного управления и других языков реляционного типа х), опишем группы отношений языка более детально. [c.48]
Объектно-ориентированный подход явился результатом сближения двух областей исследований семантического моделирования данных и объектно-ориентированных языков. Семантическое моделирование уделяет наибольшее внимание структуре данных, что позволяет эффективно отображать значения реальных фактов в конструкции модели и легко создавать логические схемы для сетевых, иерархических и реляционных баз данных. Объектно-ориентированные языки изучали поведение объектов данных. Сближение этих двух областей позволило применить понятия объектно-ориентированных языков к семантическим структурам данных. [c.6]
В процессе реализации выбирается и приобретается СУБД. Затем подробная концептуальная модель превращается в проект реализации БД создается словарь данных, БД наполняется данными, создаются прикладные программы и обучаются пользователи. В данном случае была выбрана реляционная СУБД. С помощью процедур проектировщик преобразовал концептуальную модель в проект реализации и получил таблицы с помощью языка , [c.121]
Логическое проектирование реляционных БД заключается в распределении информации по файлам. Конечным результатом диалогического проектирования является описание логической структуры БД на языке описания данных. [c.136]
О QBE (Query By Example) — запрос по примеру, построенный на основе реляционного языка запросов графического типа [c.580]
Использование реляционного языка SQL поддерживает основные виды обработки данных таблиц. Самым мощным оператором языка SQL является оператор SELE T, обеспечивающий формирование результирующих таблиц. Структура выходной таблицы задается перечислением полей исходных таблиц или выражений над полями [c.677]
Системы управления базами данных, ориентированные на персональные компьютеры, как правило, поддерживают реляционную модель данных, предложенную в 1969 году Е. Коддом. Реляционная модель освобождает пользователей от взаимодействия с физической структурой данных. Вместо этого, она основывается на логических взаимоотношениях, выраженных с помощью реляционных языков, которые расширяют математическую теорию множеств для работы с реляционной моделью данных. [c.248]
Формирование реляционно-сетевой концептуальной модели учетных данных уже на стадии семантического (информационного) анализа объектов позволяет четко определить действия, которые придется выполнять отдельными пользователями над рассматриваемыми объектами. Совокупность действий над объектами концептуальной модели, представляющих интерес для конкретного пользователя или прикладной задачи в терминах выбранных языков описания и манипулирования данными, будем называть внешней моделью. Если в качестве таких языков выбраны реляционные языки, то как на стадии проектирования БД, так и ее внедрения можно успешно использовать программные средства серии малых машин, например ДИАМС и ФОБРИН для СМ ЭВМ [67, с. 9 19, с. 82]. [c.124]
Малпас Дж. Реляционный язык Пролог и его применение / Пер. с англ. Под ред. В. Н. Соболева. М. Наука, 1990. [c.492]
Как указывалось, математическим термином для обозначения таблицы является отношение (relation), и реляционные системы берут свое начало в математической теории отношений. Основы реляционной модели данных были первоначально сформулированы доктором Э.Ф. Коддом из фирмы IBM и опубликованы в 1970 г. Эти идеи оказали широкое влияние на технологию баз данных во всех ее аспектах, а также и на другие области информационных технологий (например, искусственный интеллект и обработку текстов на естественных языках). [c.147]
PolyAnalyst 3.3. Система Data mining анализирует реляционные базы данных и обнаруживает в сырых данных ранее неизвестные многофакторные закономерности, выражая их в виде аналитических формул, структурных правил и алгоритмов решений, которые позволяют не только прогнозировать поведение сложных объектов, но и получать новое понимание их устройства и поведения. Отличительная черта системы — представление знаний на символьном математическом языке, легко понимаемом человеком. Области применения пакета в финансовой сфере [c.150]
Генерация схем базы данных основана на открытых менеджеру как конечному пользователю интерпретируемых программах, представляемых обычно на специальных языках (например, на языке Tools ommand Language — T L). При необходимости могут быть применяемы оригинальные реляционные отношения в базе данных предметных областей. [c.206]
Разработка Е. Коддом реляционной теории подтолкнула к созданию следующего класса СУБД. Особенностями второго поколения являются применение реляционной модели данных и развитый язык запросов SQL. Простота и гибкость модели данных позволили стать ей доминирующей и занять лидирующие позиции на соответствующем секторе рынка. [c.472]
Основная функция компилятора языка БД — компиляция операторов языка БД в некоторую выполняемую программу. Основной проблемой реляционных СУБД является наличие непроцедурного языка, т. е. в операторе такого языка специфицируется некоторое дей [c.475]
Его появление и развитие как средства описания доступа к базе данных связано с созданием теории реляционных баз данных. Прообраз языка возник в 1970 г. в лаборатории Санта-Тереза фирмы IBM в рамках научно-исследовательского проекта System/R. Сегодня — это фактический стандарт интерфейса с современными СУБД. Популярность его настолько велика, что разработчики нереляционных СУБД (например, ADABAS) снабжают свои системы /--интерфейсом. [c.480]
БАЗА ДАННЫХ — логически организованная совокупность данных (как правило, большая по объему), ориентированная на их эффективное хранение, накопление и обработку (в частности, поиск) с помощью ЭВМ. Для создания и ведения Б.д. используются программные системы управления (СУБД). Организация СУБД на высоком уровне должна опираться на простой и ясный язык общения с Б.д., понятный даже лицу, не знакомому с программированием. На низком же уровне она требует применения сложных алгоритмов, максимально использующих все технические и программные возможности ЭВМ для быстрого и безошибочного исполнения запроса по Б.д. Важнейшие принципы организации Б.д. — иерархический, сетевой и реляционный. Первые два опираются на геометрические представления (представление данных в виде некоторых графов), а последний — на алгебраическую теорию. Однако основополагающие работы Э. Кодда по теории реляционных Б.д. сделали последний принцип их реализации доминирующим. [c.19]
При этом достигается высокая степень взаимной независимости прикладных программ и БД, и модель данных максимально приближена к языку пользователя. Значительные преимущества реляционного подхода связаны с представлением БД в виде совокупности отношений. Такое представление, являясь простым и естественным, дает возможность применить аппарат современной прикладной алгебры и математической логики к задачам проектирования БД и построению простых средств общения пользователей-непрограммистов с БД. [c.116]
На третьем этапе производится построение внутренней логической модели. При формализации такой модели следует опираться на язык описания данных КО-ДАСИЛ. Это объясняется тем, что подход КОДАСИЛ хорошо согласуется с существующей технологией обработки данных и допускает эффективную реализацию в существующих системах обработки данных. Подход КОДАСИЛ гораздо более соответствует реляционной теории, чем ОКА или СЕДАН [43, с. 205]. Описание внешних моделей в дальнейшем при построении базы учетных данных будем производить как в терминах реляционной теории, так и подхода КОДАСИЛ. [c.117]
На третьем симпозиуме в центре внимания были проблемы, связанные с -созданием математического обеспечения для систем ситуационного управления. Именно этот вопрос был тогда самым актуальным, ибо от решения его зависела сама возможность применения идей ситуационного управления в системах управления реальными объектами. Участники дискуссий по этим проблемам указывали на необходимость использования языков, способных работать с данными, обладающими сложной внутренней структурой и ориентированных на такие прогрессивные в то время ЭВМ, как БЭСМ-6 и ЕС РЯД. Было высказано немало предложений, многие из которых существенно позже реализовались в языках представления знании типа реляционных или фреймовых языков. [c.256]
Еще одной моделью данных, имеющей конкретную реализацию (InfoModeller), является модель "объектов-ролей", предложенная еще в начале 1970-х гг., но востребованная лишь недавно. В отличие от реляционной модели в ней нет атрибутов, а основные понятия - это объекты и роли, описывающие их. Роли могут быть как "изолированные", присущие исключительно какому-нибудь объекту, так и существующие как элемент какого-либо отношения между объектами. Модель служит для понятийного моделирования, что отличает ее от реляционной модели. Имеются и другие отличия и интересные особенности например, для нее помимо графического языка разработано подмножество естественного языка, не допускающее неоднозначностей, и, таким образом, пользователь (заказчик) не только общается с аналитиком на естественном языке, но и видит представленный на том же языке результат его работы по формализации задачи. (Можно заметить, что многие пользователи, в отличие от аналитиков, с трудом разбираются в описывающих их деятельность рисунках и схемах.) Модель "объектов-ролей" сейчас привлекает большое внимание специалистов, однако до промышленных масштабов ее использования, сравнимых с двумя предыдущими, ей пока далеко. [c.79]
Дается характеристика компонентов экономических информационных систем (ЭИС)—вычислительной системы, базы данных, программного обеспечения рассматриваются этапы нежизненного цикла — проектирование, внедрение, эксплуатация, развитие. Моделирование представлений информации в ЭИС предполагает использование синтаксических моделей данных (реляционной, сетевой и иерархической) и семантических моделей (семантические сети, фреймы и др.). Моделирование процессов опирается на сети Петри. Теоретические методы проектирования иллюстрируются практическими задачами. Для иллюстрации методов обработки данных используются языки Паскаль, SQL, dBASE и Пролог (3-е изд.—1993 г.). [c.2]