III. Научно-популярный текст

Задача: увлечь информацией

Источник: в зависимости от конкретного текста индивидуальный/групповой

Реципиент: разный: взрослые, подростки, дети

Информация: ведущий тип когнитивная, языковые средства те же

Плотность информации ниже, больше картинок.

Нейтральный фон меньше, но его границы размыты.

1) сближение с читателем: повествование от 1-го лица, прямое обращение к читателю, риторические вопросы, разговорная и даже сниженная лексика

2) инверсия – синтаксический прием

3) интертекстуализмы: ссылки на других писателей

4) фразеологизмы

5) столкновение несовместимых языковых средств: эффект неожиданности, комизм, ирония

6) условные вымышленные персонажи

7) много метафор

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

 

IV Энциклопедические тексты

Тип информации: примарно-когнитивный

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

Автор: коллектив экспертов. За составление статей отвечает редакция.

Ведущая информация: когнитивная. Номинативность, терминология.

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

Фон: литературная норма.

Термины имеются, но самые распространенные или со ссылками на другие статьи.

В основном текст лишен эмоциональности, но есть необходимость в общепринятых оценках, следовательно имеется оценочная лексика.

Мера переводимости высокая.

 

28. Релятивные базы данных и возможности их использования в прикладных лингвистических целях. Типовая структура релятивной базы данных (таблицы и типы полей, нормализация, запросы, типы запросов). Access-приложения как релятивные базы данных.

Реляционная модель данных

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

Реляционная база данных — это совокупность таблиц, содержащих всю информацию, которая должна храниться в БД.

1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.

2. Строки имеют фиксированное число полей (столбцов) и значений. В каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или ничего.

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

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

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

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

Реляционная модель была разработана в конце 60-х годов математиком Э.Коддом на основе математического аппарата теории множеств. Рассмотрим формальное описание этого аппарата.

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

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

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

Отношение (таблица) на доменах D₁, D₂, ..., D_n (не обязательно, чтобы все они были различны) состоит из заголовка и тела.

Заголовок состоит из такого фиксированного множества атрибутов A₁, A₂, ..., A_n, что существует взаимно однозначное соответствие между этими атрибутами A_i и определяющими их доменами D_i (i=1, 2,..., n).

Тело состоит из меняющегося во времени множества кортежей (строк), где каждый кортеж состоит в свою очередь из множества пар атрибут-значение (A_i: V_i), (i=1, 2,..., n), по одной такой паре для каждого атрибута A_i в заголовке. Для любой заданной пары V_i является значением из единственного домена D_i, который связан с атрибутом A_i.

Степень отношения — это число его атрибутов. Отношение степени один называют унарным, степени два — бинарным, степени три — тернарным, а степени n — n-арным.

Кардинальное число или мощность отношения — это число его кортежей. Кардинальное число отношения изменяется во времени в отличие от его степени.

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

1. Уникальность: в произвольный заданный момент времени никакие две различных строки не имеют одних и тех же значений во всех этих столбцах.

2. Минимальность: ни один из столбцов не может быть исключен без нарушения уникальности.

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

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

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

1. Каждая сущность представляется в виде таблицы, столбцами которой становятся атрибуты сущности. Для этой таблицы выбирается первичный ключ.

2. Связь типа 1: M реализуется путем включения в таблицу со стороны «много» дополнительного столбца, представляющего собой внешний ключ к таблице со стороны «один».

3. Связь типа «многие-ко-многим» реализуется путем создания дополнительной таблицы, состоящей из внешних ключей к обеим таблицам, участвующим в связи (а при необходимости и столбцов с атрибутами самой связи).

Модель, построенная в примере 2 для салона видеопроката, будет представлена в виде совокупности следующих таблиц:

Целостность реляционной БД

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

Эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1, 2, 3, 4, 5, 6, 7).

Для реляционной БД выделяют три группы правил целостности:

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

2. Целостность по ссылкам (значение внешнего ключа должно либо быть равным значению первичного ключа цели, либо быть полностью неопределенным, т.е. каждое значение атрибута, участвующего во внешнем ключе должно быть неопределенным).

3. Целостность, определяемая пользователем. Для любой конкретной базы данных существует ряд дополнительных специфических правил, которые относятся к ней одной и определяются разработчиком. Чаще всего контролируются: уникальность тех или иных атрибутов; диапазон значений (экзаменационная оценка от 2 до 5); принадлежность набору значений (пол " М" или " Ж" ).

Для того чтобы была обеспечена целостность по ссылкам, для каждого внешнего ключа необходимо решить три вопроса:

1. Может ли данный внешний ключ принимать неопределенные значения (NULL-значения)? Иначе говоря, может ли существовать некоторый экземпляр сущности данного типа, для которого неизвестна целевая сущность, указываемая внешним ключом?

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

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

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

— каскадируется — операция удаления " каскадируется" с тем, чтобы удалить также заказы этого клиента;

— ограничивается — удаляются лишь те клиенты, у которых нет на руках фильмов. Иначе операция удаления отвергается (для рассматриваемого внешнего ключа это наиболее логичный вариант);

— устанавливается — для всех заказов удаляемого клиента внешний ключ устанавливается в неопределенное значение, а затем этот клиент удаляется. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений (как в данном случае).

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

— каскадируется — операция удаления " каскадируется" с тем, чтобы обновить также заказы этого клиента (этот вариант подходит для абсолютного большинства внешних ключей);

— ограничивается — обновляются первичные ключи лишь тех клиентов, которые еще не осуществляли поставок, иначе операция обновления отвергается;

— устанавливается — для всех заказов такого клиента внешний ключ устанавливается в NULL-значение, а затем обновляется первичный ключ клиента.

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

 

⇐ Предыдущая123456789

Поделиться: