Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
db-shpora.doc
Скачиваний:
14
Добавлен:
08.11.2018
Размер:
1.44 Mб
Скачать
  1. Управление параллельной обработкой в ms sql Server

SQL Server 2000 предоставляет исчерпывающий набор возможностей для управ­ления параллельной обработкой. Количество вариантов выбора велико, и итого­вое поведение определяется взаимодействием трех факторов: уровня изоляции транзакции, характеристик курсора и блокировочных подсказок, заданных в пред­ложении SELECT. Блокировочное поведение зависит также от того, обрабатывает­ся ли курсор как часть транзакции, является ли оператор SELECT частью курсора и как подаются команды на обновление – из транзакции или независимо.

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

  1. Xml как язык разметки. Общие черты и различия html и xml. Разделение между структурой документа, его содержимым и материализацией

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

Кроме того, хотя XML стандартизирован, этот стандарт может расширяться разработчиками, как следует из названия. В XML вы не ограничены фиксированным набором элементов вроде <TITLE>, <H1> и <Р>, а можете определять свои собственные элементы.

Одной из проблем HTML является то, что он предоставляет слишком большую свободу. Рассмотрим следующий HTML-код:

<h2>Здравствуй, мир!</h2>

Хотя тег <h2> может обозначать заголовок второго уровня в структуре документа, его также можно использовать для того, чтобы просто вывести слова «Здравствуй, мир!» определенным стилем. Из-за этого обстоятельства мы не можем положиться на теги в деле определения истинной структуры HTML-страницы. Использование тегов носит слишком произвольный характер: <h2> может означать заголовок, а может не означать ничего.

Как вы увидите, в XML структура документа формально определена. Если мы находим тег <street>, мы знаем точно, где этот тег расположен и как он соотносится с другими тегами в структуре документа. Таким образом, про XML-документы говорят, что они в точности передают семантику содержащихся в них данных.

  1. Описание содержимого xml-документа с помощью dtd.

Для описания содержимого XML-документов используется два способа: опре­деление типа документа (DTD) и XML-схема.В листинге 1 приведен пример XML-документа. Обратите внимание, что документ имеет два раздела. В первом разделе определяется структура документа; этот раздел называется определением типа документа, или DTD (Document Type Declaration). Второй раздел содержит собственно данные.

Листинг .1. XML-документ Customer с вложенным определением типа

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE customer [

<!ELEMENT customer (name, address)>

<!ELEMENT name (firstname, lastname)>

<!ELEMENT firstname (#PCDATA)>

<!ELEMENT lastname (#PCDATA)>

<!ELEMENT address (street+, city, state, zip)>

<!ELEMENT street (#PCDATA)>

<!ELEMENT city (#PCDATA)>

<!ELEMENT state (#PCDATA)>

<!ELEMENT zip (#PCDATA)>

]>

<customer> <name> <firstname>Michelle</firstname> <lastname>Correlli</lastname> </name>

<address> <street>1824 East 7th Avenue</street> <street>Suite 700</street> <city>Memphis</city>

<state>TN</state> <zip>32123-7788</zip> </address> </customer>

DTD начинается с ключевого слова DOCTYPE, за которым следует имя типа документа — customer. Далее идет описание содержимого документа customer. В нем есть две группы: name и address. Группа name состоит из двух элементов — firstname и lastname. Эти элементы определены как #PCDATA, то есть строки символьных данных. Ниже описывается элемент address, состоящий из четырех элементов: street, city, state и zip. Каждый из этих элементов также определен как символьные данные. Знак + после имени элемента street указывает на то, что этот элемент обязан иметь по крайней мере одно значение, но может иметь несколько значений.Экземпляр данных типа customer, показанный в листинге 1, соответствует DTD, поэтому данный документ называется XML-документом, допустимым по типу (type-valid XML document). Если бы он не соответствовал DTD, он назывался бы недопустимым по типу документом (not-type-valid XML document). Недопустимые по типу документы могут тем не менее быть абсолютно правильными с точки зрения XML: они просто не являются допустимыми экземплярами своего типа. Например, если бы документ в листинге 1 содержал два элемента city, он был бы по-прежнему правильным с точки зрения XML, но недопустимым по типу.

Хотя DTD почти всегда желательны, они не являются обязательными в XML-документах. Документ, не имеющий DTD, по определению является недопустимым по типу, поскольку не существует типа, относительно которого можно было бы проверить его допустимость.Раздел DTD не обязательно должен содержаться в самом документе. В листинге 2 изображен документ типа customer, в котором DTD берется из файла C:\DB9E\First Draft\Chapter 13\XML\Docs\customer.dtd. Преимущество внешнего хранения DTD в том, что можно проверять допустимость множества документов относительно одного и того же DTD.

Листинг 2. XML-документ Customer с внешним определением типа

<!DOCTYPE customer SYSTEM "C:\DB9e\First Draft\Chapter 13\XML Docs\customer.dtd"> <customer>

<name>

<firstname>Michelle</fnrstname>

<lastname>Correlli</lastname>

</name> <address> <street>1824 East 7th Avenue</street> <street>Suite 700</street>

<city>Memphis<city>

<state>TN</state>

<zip>32123-7788</zip>

</address>

</customer>

Создатель DTD может определять любые элементы по своему желанию. Следовательно, XML-документы могут расширяться, но расширяться стандартизированным и контролируемым способом.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]