Логическая модель знаний.

Логическая модель представляет собой формальную систему - некоторое логическое исчисление. Все знания о предметной области описываются в виде формул этого исчисления или правил вывода. Описание в виде формул дает возможность представить декларатив­ные знания, а правила вывода - процедурные знания. Языки представлений знаний логического типа широко использо­вались на ранних стадиях развития интеллектуальных систем, но вскоре были вытеснены (или, во всяком случае, сильно потеснены) языками других типов. Объясняется это громоздкостью записей, опирающихся на классические логические исчисления. При формировании таких записей легко допустить ошибки, а поиск их очень сложен. Отсутствие наглядности, удобочитаемости (особенно для тех, чья деятельность не связана с точными науками) затрудняло распространение языков такого типа.

Фреймовая модель знаний .

Фрейм (англ. frame - каркас или рамка) предложен М. Минским в 1970-е гг. как структура знаний для восприятия пространственных сцен. Эта модель имеет глубокое психологическое обоснование. Под фреймом понимается абстрактный образ или ситуация. Фреймом называется также и формализованная модель для отображения образа. Различают фреймы-образцы, или прототипы, хранящиеся в базе знаний, и фреймы-экземпляры, которые создаются для отображения реальных ситуаций на основе поступающих данных. Модель фрейма является достаточно универсальной, поскольку позволяет отобразить все многообразие знаний о мире через: - фреймы-структуры, для обозначения объектов и понятий (заем, залог, вексель); - фреймы-роли (менеджер, кассир, клиент); - фреймы-сценарии (банкротство, собрание акционеров); - фреймы-ситуации (тревога, авария, рабочий режим устройства) и др. Основным преимуществом фреймов как модели представления знаний является способность отражать концептуальную основу организации памяти человека, а также ее гибкость и наглядность. Специальные языки представления знаний в сетях фреймов FRL (Frame Representation Language) и другие позволяют эффективно строить промышленные ЭС. Широко известны такие фреймоориентированные экспертные системы, как ANALYST, МОДИС.

Термин семантическая означает "смысловая", а сама семантика - это наука, устанавливающая отношения между символами и объектами, которые они обозначают, т.е. наука, определяющая смысл знаков. Семантическая сеть - это ориентированный граф, вершины которого - понятия, а дуги - отношения между ними. Характерной особенностью семантических сетей является обязательное наличие трех типов отношений: - класс - элемент класса; - свойство - значение; - пример элемента класса. Проблема поиска решения в базе знаний типа семантической сети сводится к задаче поиска фрагмента сети, соответствующего некоторой подсети, соответствующей поставленному вопросу. Основное преимущество этой модели - в соответствии современным представлениям об организации долговременной памяти человека. Недостаток модели - сложность поиска вывода на семантической сети. Для реализации семантических сетей существуют специальные сетевые языки, например NET и др. Широко известны экспертные системы, использующие семантические сети в качестве языка представления знаний - PROSPECTOR, CASNET, TORUS.

По форме описания знания подразделяются на:

Декларативные (факты) - это знания вида "А есть А". Декларативные знания подразделяются на объекты, классы объектов и отношения. Объект - это факт, который задается своим значением. Класс объектов - это имя, под которым объединяется конкретная совокупность объектов-фактов. Отношения - определяют связи между классами объектов и отдельными объектами, возникшие в рамках предметной области.

Процедурные - это знания вида "Если А, то В". К процедурным знаниям относят совокупности правил, которые показывают, как вывести новые отличительные особенности классов или отношения для объектов. В правилах используются все виды декларативных знаний, а также логические связки. При обработке правил следует отметить рекурсивность анализа отношений, т.е. одно правило вызывает глубинный поиск всех возможных вариантов объектов БЗ.

Граница между декларативными и процедурными знаниями очень подвижна, т.е. проектировщик может описать одно и то же как отношение или как правило.

Глава 12

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

В предыдущих главах предполагалось, что в базах данных хранятся сущности, у которых есть имя и атрибуты. Атрибуты имеют тип. В объектных моделях к атрибутам добавляются ещё методы. Появляются объектные типы, а сами сущности (классы) и их члены могут иметь не только предопределённые скалярные типы, но и объектные. Такая вот благостная и вполне привычная для программистского взгляда картина, немного усложненная свойством персистентности.

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

Мы попробуем расширить модель представимого концепта, введя атрибуты состояния, ресурсов и смыслов. При этом обнаружится, что концепты с обязательными и необязательными атрибутами описывают замкнутые системы. Атрибуты состояния, как и следовало ожидать, характерны для динамических объектов. Атрибуты ресурсов позволяют описать обмен энергетическими, предметными и информационными сущностями и, тем самым, моделировать открытые системы.

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

Много внимания будет уделено атрибутам смыслов, реализация которых может существенно расширить объём семантики, хранимой в базе. Мы классифицируем смыслы и опишем их реализации с помощью препроцессоров в обычных СУБД, а также предложим несложные изменения, которые необходимо внести в СУБД, чтобы получить возможность работы со смыслами.

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

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

Как далеко следует заходить в насыщении базы данных семантикой? Всё зависит от того, имеется ли необходимая информация, насколько нужна семантика, что позволит сделать используемая СУБД и имеющиеся в распоряжении дополнительные программные средства, что даёт использования внешних источников семантики, например, онтологий, и от возможностей второго слоя СУБД.

В предыдущих главах значения, хранящиеся в базе, предполагались атомарными. С точки зрения отображаемой модели бизнеса они могли быть сколько угодно сложными, но рамках использованной модели данных работать с их компонентами нельзя. В базах данных давно используются модели, которые мы будем называть двухслойными. Роль первого слоя выполняет любая модель данных, для которой организованы структуры хранения данных. Второй слой работает с данными, которые ему предоставляет первый слой, но данные в нём считаются не атомарными, а известным образом организованными. Практически во всех СУБД во втором слое применяются регулярные выражения и/или различные виды XML данных. Понятно, что второй слой не влияет на структуры хранения данных непосредственно, но может предъявлять свои требования к их организации.

Вторая возможность расширения обычных моделей данных связана с хранением дополнительной семантики данных. Можно учесть особенности использования атрибутов, выделяя их разновидности – сорта. Дальше мы отметим, что сущности с обычными (обязательными) атрибутами определяют замкнутые и статические объекты. Сущности с атрибутами других сортов могут быть открытыми и динамическими.

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

Полезно заимствовать опыт тех областей знания, в которых давно занимаются семантикой. Это лингвистика, исследующаяся естественные языки (ЕЯ), и теория языков программирования.

Прежде всего, отметим несоответствие некоторых терминов в лингвистике и информатике. Лингвисты выделяют два противопоставляемых вида элементов семантики – значения и смыслы. Значение лингвистического знака понимается как нечто стабильное, что можно сначала установить, выяснить, а затем знать. Смысл приходится всё время искать, устанавливать, разгадывать. В информатике термин ”значение” уже занят. Говоря ”переменная имеет значение” подразумеваем не семантику этой переменной, а присваивание ей конкретного экземпляра данных, или означивание, или создание экземпляра переменной, содержащего этот элемент данных. Поэтому элементы семантики мы всегда будем называть смыслами, а ”стабильность” или “контекстность” или “вариативность” смыслов будем задавать через классификацию смыслов или вводя в них дополнительные свойства.

Давно известно, что значения и смыслы -- это внеязыковые сущности. В частности, для перевода с одного естественного языка на другой ЕЯ может создаваться специальный язык функций для представления семантики, в который транслируются фразы исходного языка. А уже с этого промежуточного языка осуществляется трансляция на второй ЕЯ. Тезис о внеязыковой природе смыслов мы трансформируем для баз данных в несколько смягчённую форму как утверждение о возможности разделения данных и смыслов.

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

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

Как же отделить элементы семантики, хранимые в базе, от обычных данных? По очень простому признаку: элементы семантики, они же смыслы, обладают активностью. Данные всегда пассивны.

Поясним сказанное на простом примере. Пусть, необходимо выбрать все записи из таблицы, например, инструкцией SELECT * FROM emp. Очевидно, СУБД должна сначала проверить существование таблицы emp по словарю и, может быть, установить, имеются ли у действующего пользователя необходимые права на эту таблицу. Если таблица не существует или недоступна, выдать сообщение об ошибке. В противном случае, установить список столбцов emp и только после этого приступить к выборке данных. Как много делается того, что прямо не было указано! Всё это обеспечивает активность, которой обладают метаданные.

Ещё один пример. Пусть мы вставляем строку в таблицу, имеющую первичный ключ. Поскольку ограничение ”первичный ключ” активно, СУБД сначала проверит уникальность вводимого значения ключа, и только если это условие выполнено, сделает то, что ей приказали – введёт запись.

Заметим, что активность смыслов выводит модели данных со смыслами за рамки обычных чисто алгебраических моделей данных.

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

При проектировании баз данных используются семантическое моделирование для создания концептуальной модели предметной области и отражение ее спецификаций в среде конкретной СУБД. Однако зачастую полученная концептуальная схема базы данных существенно отличается от первоначальной концептуальной модели.
В 70-е годы реляционная модель данных возникла как ответ на потребность в простой СУБД, соответствующей уровню развития компьютерной технологии своего времени. Реляционная база данных - это совокупность отношений, содержащих всю информацию, которая должна храниться в БД; пользователи могут воспринимать такую базу данных как совокупность таблиц.Сегодня гораздо важнее удобство проектирования и эксплуатации баз данных, а то, что когда-то казалось простым, математически строгим и логичным, стало восприниматься как неудобное. Семантическое расширение реляционной модели
Большая часть данных, возникающих в ходе деятельности, например, предприятия, представляется в виде электронных и бумажных документов. С точки зрения манипулирования этими данными все аспекты хозяйственной деятельности либо являются документооборотом, либо могут быть формально к нему сведены. Сегодня доминирующее положение занимают реляционные СУБД, которые обеспечивают удобный способ хранения информации в виде таблиц.Структуру данных большинства реальных документов можно представить как произвольное иерархическое дерево с горизонтальными связями. Документы полностью хранятся в одной ячейке таблицы реляционной базы либо разбиваются на множество таблиц, а некоторые таблицы из разных документов объединяются. Однако в реляционной базе данных мы уже имеем дело с другими документами, поэтому алгоритм обработки реального документа нельзя сделать основой алгоритма программного кода хранимой процедуры. Реальные документы снова появляются лишь на уровне приложения. Здесь, по сути, мы имеем дело не с отображением, а с перепроектированием документов и, соответственно, документооборота.Как известно, целью реляционного подхода было преодоление ограничений ранних систем — иерархических и сетевых. Реляционная модель достаточна для моделирования предметных областей, но само проектирование базы в терминах отношений часто оказывается очень сложным. Потребность проектировщиков в более удобных и мощных средствах представления предметной области вызвала появление семантического моделирования .Основная цель исследований в этой области состоит в том, чтобы сделать СУБД более «разумными», максимально отражающими особенности прикладной области. Если в основу СУБД будет положена модель данных, более соответствующая семантике предметной области, то и построенные на ее основе базы данных будут больше соответствовать реальным системам, а проектирование баз данных значительно упростится. Семантическое моделирование представляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship). Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом. В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др.). Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями.По сути, все варианты диаграмм сущность-связь исходят из одной идеи - рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.Основные понятия ER-диаграмм (близко к нотации Баркера)Определение 1. Сущность - это класс однотипных объектов, информация о которых должна быть учтена в модели.Каждая сущность должна иметь наименование, выраженное существительным в единственном числе.Примерами сущностей могут быть такие классы объектов как "Поставщик", "Сотрудник", "Накладная".Каждая сущность в модели изображается в виде прямоугольника с наименованием:Определение 2. Экземпляр сущности - это конкретный представитель данной сущности.Например, представителем сущности "Сотрудник" может быть "Сотрудник Иванов".Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности .Определение 3. Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности.Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными).Примерами атрибутов сущности "Сотрудник" могут быть такие атрибуты как "Табельный номер", "Фамилия", "Имя", "Отчество", "Должность", "Зарплата" и т.п.Атрибуты изображаются в пределах прямоугольника, определяющего сущность:Определение 4. Ключ сущности - это неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Неизбыточность заключается в том, что удаление любого атрибута из ключа нарушается его уникальность.Сущность может иметь несколько различных ключей.Ключевые атрибуты изображаются на диаграмме подчеркиванием:Определение 5. Связь - это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою.Связи позволяют по одной сущности находить другие сущности, связанные с нею.Например, связи между сущностями могут выражаться следующими фразами - "СОТРУДНИК может иметь несколько ДЕТЕЙ", "каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ".Графически связь изображается линией, соединяющей две сущности:Каждая связь имеет два конца и одно или два наименования. Наименование обычно выражается в неопределенной глагольной форме: "иметь", "принадлежать" и т.п. Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности.Каждая связь может иметь один из следующих типов связи:Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней.Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи , допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.Каждая связь может иметь одну из двух модальностей связи :Модальность "может" означает, что экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.Модальность "должен" означает, что экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности.Связь может иметь разную модальность с разных концов.Описанный графический синтаксис позволяет однозначно читать диаграммы, пользуясь следующей схемой построения фраз:Каждый экземпляр СУЩНОСТИ 1 МОДАЛЬНОСТЬ СВЯЗИ НАИМЕНОВАНИЕ СВЯЗИ ТИП СВЯЗИ экземпляр СУЩНОСТИ 2 .Каждая связь может быть прочитана как слева направо, так и справа налево. Например,
Слева направо: "каждый сотрудник может иметь несколько детей".
Справа налево: "Каждый ребенок обязан принадлежать ровно одному сотруднику".Разработкa простой ER-модели При разработке ER-моделей мы должны получить следующую информацию о предметной области:*Список сущностей предметной области.
*Список атрибутов сущностей.
*Описание взаимосвязей между сущностями.ER-диаграммы удобны тем, что процесс выделения сущностей, атрибутов и связей является итерационным. Разработав первый приближенный вариант диаграмм, мы уточняем их, опрашивая экспертов предметной области. При этом документацией, в которой фиксируются результаты бесед, являются сами ER-диаграммы.Например, проектируемая система должна выполнять следующие действия:Хранить информацию о покупателях.
Печатать накладные на отпущенные товары.
Следить за наличием товаров на складе.Выделим все существительные в этих предложениях - это будут потенциальные кандидаты на сущности и атрибуты, и проанализируем их (непонятные термины будем выделять знаком вопроса):Покупатель - явный кандидат на сущность.
Накладная - явный кандидат на сущность.
Товар - явный кандидат на сущность
(?)Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.
(?)Наличие товара - это, скорее всего, атрибут, но атрибут какой сущности?
Сразу возникает очевидная связь между сущностями - "покупатели могут покупать много товаров" и "товары могут продаваться многим покупателям". Первый вариант диаграммы выглядит так:Куда поместить сущности "Накладная" и "Склад" и с чем их связать? Спросим себя, как связаны эти сущности между собой и с сущностями "Покупатель" и "Товар"? Покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара. Каждый покупатель может получить несколько накладных. Каждая накладная обязана выписываться на одного покупателя. Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждый товар, в свою очередь, может быть продан нескольким покупателям через несколько накладных. Кроме того, каждая накладная должна быть выписана с определенного склада, и с любого склада может быть выписано много накладных. Таким образом, после уточнения, диаграмма будет выглядеть следующим образом:Пора подумать об атрибутах сущностей:Каждый покупатель является юридическим лицом и имеет наименование, адрес, банковские реквизиты.
Каждый товар имеет наименование, цену, а также характеризуется единицами измерения.
Каждая накладная имеет уникальный номер, дату выписки, список товаров с количествами и ценами, а также общую сумму накладной. Накладная выписывается с определенного склада и на определенного покупателя.
Каждый склад имеет свое наименование.Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:Юридическое лицо - термин риторический, мы не работаем с физическими лицами. Не обращаем внимания.
Наименование покупателя - явная характеристика покупателя.
Адрес - явная характеристика покупателя.
Банковские реквизиты - явная характеристика покупателя.
Наименование товара - явная характеристика товара.
(?)Цена товара - похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?
Единица измерения - явная характеристика товара.
Номер накладной - явная уникальная характеристика накладной.
Дата накладной - явная характеристика накладной.
(?)Список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность.
(?)Количество товара в накладной - это явная характеристика, но характеристика чего? Это характеристика не просто "товара", а "товара в накладной".
(?)Цена товара в накладной - опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?
Сумма накладной - явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную.
Наименование склада - явная характеристика склада.С возникающим понятием "Список товаров в накладной" все довольно ясно. Сущности "Накладная" и "Товар" связаны друг с другом отношением типа много-ко-многим. Такая связь, как мы отмечали ранее, должна быть расщеплена на две связи типа один-ко-многим. Для этого требуется дополнительная сущность. Этой сущностью и будет сущность "Список товаров в накладной". Связь ее с сущностями "Накладная" и "Товар" характеризуется следующими фразами - "каждая накладная обязана иметь несколько записей из списка товаров в накладной", "каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную", "каждый товар может включаться в несколько записей из списка товаров в накладной", " каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром". Атрибуты "Количество товара в накладной" и "Цена товара в накладной" являются атрибутами сущности " Список товаров в накладной".Точно также поступим со связью, соединяющей сущности "Склад" и "Товар". Введем дополнительную сущность "Товар на складе". Атрибутом этой сущности будет "Количество товара на складе". Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.Теперь можно внести все это в диаграмму:Концептуальные и физические ER-модели Разработанный выше пример ER-диаграммы является примером концептуальной диаграммы. Это означает, что диаграмма не учитывает особенности конкретной СУБД. По данной концептуальной диаграмме можно построить физическую диаграмму, которая уже будут учитываться такие особенности СУБД, как допустимые типы и наименования полей и таблиц, ограничения целостности и т.п. Приведенный физический вариант диаграммы может выглядеть, например, следующим образом:На данной диаграмме каждая сущность представляет собой таблицу базы данных, каждый атрибут становится колонкой соответствующей таблицы. Обращаем внимание на то, что во многих таблицах, например, "CUST_DETAIL" и "PROD_IN_SKLAD", соответствующих сущностям "Запись списка накладной" и "Товар на складе", появились новые атрибуты, которых не было в концептуальной модели - это ключевые атрибуты родительских таблиц, мигрировавших в дочерние таблицы для того, чтобы обеспечить связь между таблицами посредством внешних ключей.Таким образом, реальным средством моделирования данных является не формальный метод нормализации отношений, а так называемое семантическое моделирование.В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship).Диаграммы сущность-связь позволяют использовать наглядные графические обозначения для моделирования сущностей и их взаимосвязей.Сущности, определенные в концептуальной диаграмме становятся таблицами, атрибуты становятся колонками таблиц (при этом учитываются допустимые для данной СУБД типы данных и наименования столбцов), связи реализуются путем миграции ключевых атрибутов родительских сущностей и создания внешних ключей .Основное достоинство метода состоит в том, модель строится методом последовательных уточнений первоначальных диаграмм.Не рассматривались более сложные аспекты построения диаграмм, такие как подтипы, роли, исключающие связи, непереносимые связи, идентифицирующие связи и т.п.

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

Прежде чем мы коротко рассмотрим особенности распространенных семантических моделей, остановимся на их возможных применениях.

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

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

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

Семантическая модель Entity-Relationship (Сущность-Связь)

Одной из наиболее популярных семантических моделей данных является модель "Сущность-Связь" (часто ее называют кратко ER-моделью).

На использовании разновидностей модели ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных.

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

Термин «объект» не поддается всеобъемлющему определению. Достаточно сказать, что объект -это нечто существующее и различимое, т. е. мы можем отличать один объект от другого. Например, каждый стул есть объект. Объектами являются также конкретные человек и автомобиль. Можно считать объектом любого муравья, если имеется способ отличать его от других муравьев. В противном случае мы не воспринимаем муравья как объект. Объектами могут быть и понятия более высокого уровня, например, паук, грызун, бабуин и растение в биологической базе данных. Если не быть слишком строгими, то к объектам можно отнести и такие понятия, как любовь и ненависть.

Группа всех подобных объектов образует набор объектов. Так, наборами объектов могут быть все люди, все автомобили, все животные, все эмоции.

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

Атрибуты и ключи

Объекты обладают свойствами, называемыми атрибутами, которые ассоциируют некоторое значение из домена значений данного атрибута с каждым объектом в наборе объектов. Обычно домен атрибута является множеством целых чисел, действительных чисел или строк литер, но мы не исключаем и другие типы значений. Например, можно сказать, что объекты в наборе объектов «люди» имеют такие атрибуты, как имя (строка литер), рост (действительное число) и т. д.

Выбор подходящих атрибутов для наборов объектов является вторым ключевым моментом в проектировании модели реального мира. Атрибут или множество атрибутов, значения которых уникально идентифицируют каждый объект в наборе объектов, называется ключом этого набора объектов. В принципе, каждый набор объектов имеет ключ, поскольку мы приняли гипотезу о том, что каждый объект отличим от остальных. Но если для набора объектов мы выбрали совокупность атрибутов, не содержащую ключа, то отличить один объект в наборе от другого окажется невозможным. Часто в качестве атрибута, который служит ключом, предоставляется произвольно выбранный последовательный номер. Например, в наборе объектов, включающем только граждан США, может использоваться в качестве ключа единственный атрибут -«номер социальной безопасности».

Возможны случаи, когда объекты в наборе различаются не по атрибутам, а по их связи с объектами другого типа. Наиболее важным видом «встроенных» связей (связи, определенные пользователем, будут описаны позднее) является связь “есть”. Мы говоримAесть В и записываем «AестьB», если набор объектов В является обобщением набора объектовA, или, что равносильно,Aесть специальный вид В.

Рассмотрим базу данных автомобилей с набором объектов МАРКИ, имеющим атрибуты ТИП и МОДЕЛЬ. Объектом в наборе МАРКИ является, например, «Datsun-280».Мы могли бы рассмотреть и набор объектов АВТОМОБИЛИ с атрибутом СЕРИЙНЫЙ-НОМЕР, который можно было бы считать ключом этого набора. Однако вполне вероятно, что два типа автомобилей используют одни и те же серийные номера. Чтобы сделать объекты в наборе АВТОМОБИЛИ уникальными, нам потребуется связь между наборами АВТОМОБИЛИ и МАРКИ, представляющая тот факт, что любой автомобиль имеет конкретную марку. Тогда каждый экземпляр из набора объектов АВТОМОБИЛИ будет однозначно определяться по его СЕРИЙНОМУ-НОМЕРУ и атрибуту ТИП связанного с ним объекта из набора МАРКИ.

Связь между наборами объектов представляет собой просто упорядоченный список наборов объектов. Конкретный набор объектов может появляться в этом списке более одного раза. Если имеется связь RELмежду наборами объектов Е 1 , Е 2 , ..., E k ,то предполагается, что существует множество кортежей размерности k,имя которого REL.Такое множество мы называем набором связей. Каждый кортеж (е 1 , е 2 , ...,е k) в множествеRELподразумевает, что объекты е 1 , е 2 , ...,е k , где е i принадлежит набору E i , находятся в связи RELдруг с другом как группа. Наиболее общим, несомненно, является случай, когда k=2, но иногда списки состоят из трех или более наборов объектов.

Допустим, мы имеем набор объектов ЛЮДИ и связь ЯВЛЯЕТСЯ- МАТЕРЬЮ, список наборов объектов которой есть ЛЮДИ, ЛЮДИ. Мы предполагаем, что набор связей ЯВЛЯЕТСЯ-МАТЕРЬЮ включает все пары (p i ,р j), такие, что человек р i является матерью человека p j .

§ 1. Понятие и основные модели перевода

Модель перевода – это теоретический конструкт, алгоритм, описывающий деятельность переводчика в процессе перевода.

Основные модели:

трансформационно-семантическая

денотативно-ситуативная

коммуникативная

Трансформационносемантическая:

два это преобразованиеварианта объектовмодели и структур одного языка в

объекты и структуры другого по определенным правилам, т.е. с использованием разных видов

соответствий и трансформаций, без обращения к внеязыковой действительности (Л.С. Бархударов).

преобразование по правилам внутриязыковых трансформаций 1)структур ИЯ для обеспечения прямого перевода на ПЯ; или 2)пословного перевода на ПЯ с

целью получения идиоматичного грамотного перевода на ПЯ (О.И. Бродович, А.Д. Швейцер)

Переведите:

Before the invention of fashion in 1350 A.D., tailors were unnecessary: Clothing didn"tacknowledge the body"s shape.

Mosquitoes are attracted to the color blue twice as much as to any other color.

Разновидности модели, построенные на различных

теориях 1) Порождающая грамматика:языка теория

постулирует наличие у человека некоей языковой способности, состоящей из знания базовых структур языка и правил их преобразования в поверхностные.

Для английского языка характерны 6 ядерных/базовых структур: NV

There (be) N (D) N be N

при построении речевых высказываний т.н. ядерные предложения преобразуются (трансформируются) в поверхностные путем

преобразования синтаксической структуры одного предложения:

John sent Bill a letter. ↔ The letter was sent to bill by John.

или соединения нескольких ядерных с возможным опущением элементов или с использованием слов-заменителей

Having sent a letter to Bill, John went home.

Схема модели перевода, построенной на основе порождающей грамматики

Преимущества и

недостатки требует минимального привлечениямодели внелингвистических знаний для интерпретации языковых структур

позволяет сократить все многообразие языка до нескольких базовых структур.

позволяет привести два языка к семантическому “общему знаменателю”

на стадии анализа ИТ они помогают снять неоднозначность, поскольку ядерные структуры однозначны, т.к. эксплицируют смысловую структуру

poor worker (х-ка лица или процесса?)

television channel award (субъект или объект действия?)the foundation of the school (процесс или предмет?)

на стадии синтеза позволяют преодолеть такие проблемы как:

1) отсутствие соответствующей морфологической формы в ПЯ (герундий – His handling the millitary operation appears to be lax ← It apperaed that he handled … Создается впечатление, что военной операцией он руководил нечетко.

2) невозможность передать словообразовательное значение слова морфологическим способом (the rent raiser, disturber )

3) различия в лексической сочетаемости (She spoke about the waste of human resources ).

4) для сохранения тема-рематического членения или когда русское предложение начинается с косвенного дополнения (Американцам внушают, что… - Americans have been led to believe that…) и др.

2) Компонентный

анализ: значения всех словтеория во всех языках могут быть описаны с помощью одного и того же ограниченного набора из нескольких десятков элементов –семантических примитивов , соответствующих значениям слов,

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

Семы делятся на три вида: общие, дифференциальные и дополнительные . Общие семы – те компоненты, которые объединяют все лексико-семантические варианты одного слова или синонимы одного синонимического ряда (напр.,give во всех значениях - это let+have ); дифференциальные – те компоненты, кот. обеспечивают включение рассматриваемых ЛСВ в разные синонимические ряды (дарить – «безвозмездность», покупать «брать за деньги»); дополнительные – те несущественные для логикопредметного значения элементы значения, которые часто служат базой для метафорического/метонимического переноса.

Схема модели, основанной на теории компонентного

Преимущества и недостатки модели

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

В sibling по сравнению сбрат, сестра отсутствует сема «пол»

В рисунок (неспец.) по сравнению сdrawing отсутствует сема «карандашом»

Свояченица, золовка (сестра мужа/жены) – sister-in-law

объясняет случаи конкретизации значения исходной единицы ввиду разницы в конфигурации семантических полей

purple – any colour between red and blue: в переводе фиолетовый, лиловый, сиреневый.

BUT! не раскрывает механизма синтаксических и лексикосинтаксических преобразований

3) Семантическая модель «смысл↔текст»

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

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

Глубинная лексика включает лишь самостоятельные (первичные слова), а

остальное интерпретируется в терминах лексических функций, которые делятся на две категории: эквивалентные замены (синонимы, конверсивы типа «дать-получить», синтаксические дериваты) исемантические параметры ,выражающие некоторые элементарные смыслы при ключевом слове :

Oper1 (типовая ситуация, присоединитель субъекта в роли подлежащего) – задать при вопрос, сделать при шаг;

Oper2 (присоединитель объекта в роли подлежащего) – подвергнуться нападению, понести наказание.

Inctp – начинаться (вспыхнуть, подниматься), Fin – заканчиваться (улеглась, отошла),

Magn - высокая степень – (грубая ошибка, жгучий брюнет).