34 . 1. Иерархическая модель данных.

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

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

3. Реляционная модель данных. Концепции реляционной модели впервые были сформулированы в работах американского ученого Э. Ф. Кодда. Откуда происходит ее второе название - модель Кодда В реляционной модели объекты и взаимосвязи между ними представляются с помощью двумерных таблиц (рис. 3). Реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

3. каждый элемент таблицы — один элемент данных;

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

5. каждый столбец имеет уникальное имя;

6. одинаковые строки в таблице отсутствуют;

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

35. Хронология развития Справочных Правовых Систем

	ГАРАНТ	КонсультантПлюс
Год создания системы	1990	1992
Комментарии в тексте документов подготовлены профессиональными юристами и помогают получить нужную информацию без дополнительного поиска	1990	1995 С опозданием на 5 лет. До сих пор значительно уступают комментариям в системе ГАРАНТ
Поиск документов по ситуации позволяет находить ответы на любые вопросы, связанные с законодательством, даже если Вы не знаете, какие именно нормы права их регулируют	1990	2003 На 13 лет позже, неполноценный аналог со значительными ограничениями
Законодательство РФ на английском языке есть только в ГАРАНТе. За качество текстов, включаемых в Английскую базу, отвечают высокопрофессиональные переводчики и корректоры – носители языка	1992	ОТСУТСТВУЕТ
Интеллектуальные ссылки дают возможность перейти к документам, на которые законодатель ссылается, но не перечисляет их в тексте. При нажатии на такую ссылку система ГАРАНТ строит для Вас список документов или направляет в конкретный документ	1997	2009 Позже на 12 лет, в значительно меньшем количестве
Показ графических изображений в тексте документов дает возможность видеть все иллюстрации, рисунки и схемы, которые сопровождают тот или иной документ	2000	2002 С опозданием на 1,5 года
Бланки в форматах Word и Excel в системе ГАРАНТ формы документов приводятся не только в исходном текстовом формате, но также в виде, делающем их пригодными для заполнения и получения качественной распечатки	2000	2002 Только через 1,5 года после ГАРАНТа
Доступ из системы к копиям официальных публикаций позволяет Вам прямо из текста документа перейти к его графической копии. Распечатка графической копии документа может использоваться как аргумент в судебном разбирательстве	2002	ОТСУТСТВУЕТ
Машина времени работа с редакциями документов, которые действовали в заданный период. Чтобы перейти к ним, Вам достаточно ввести нужную дату в окно Машины времени	2004	2006 На 2 года позже, неполноценный аналог
Индивидуальная новостная лента ПРАЙМ новости, аннотации, обзоры, собранные специально для Вас, – ежедневно в Вашей почте!	2005	ОТСУТСТВУЕТ
Правовой консалтинг Эта услуга позволяет прямо в системе ГАРАНТ задать свой вопрос ведущим экспертам – высококвалифицированным специалистам в области бухгалтерского учета, налогообложения, гражданского и трудового права и получить на него индивидуальный письменный ответ	2006	ОТСУТСТВУЕТ
Базовый поиск удобная и привычная поисковая строка, как в Интернете. Система понимает Вас, даже если Вы допускаете опечатки	2007	2009 Неполноценный аналог, скопированный только через 2 года
Поиск похожих, близких по смыслу, документов функция, позволяющая Вам мгновенно получить представление о том, как применялась одна и та же норма права при разрешении различных споров в суде, узнать мнение авторитетных специалистов по такому же или похожему вопросу	2007	ОТСУТСТВУЕТ
Мобильная версия на CD появилась в ГАРАНТе в 1993 году, а уже в 2007 году – на современном флеш-носителе	1993	2008 Поставка на рабочем CD отсутствует. Флеш-версия появилась в КонсультантПлюс только в 2008 году
Словарь популярных поисковых запросов позволяет лучше сформулировать запрос и быстрее заполнить поисковую строку	2008	ОТСУТСТВУЕТ
«Законодательство в схемах» уникальная разработка ГАРАНТа, позволяющая Вам мгновенно получить комплексное представление о правовом регулировании любого вопроса благодаря понятным схемам и современным интерактивным возможностям	2009	ОТСУТСТВУЕТ

36.

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

Физическое проектирование является третьим и последним этапом создания проекта базы данных, при выполнении которого проектировщик принимает решения о способах реализации разрабатываемой базы данных. Во время предыдущего этапа проектирования была определена логическая структура базы данных (которая описывает отношения и ограничения в рассматриваемой прикладной области). Хотя эта структура не зависит от конкретной целевой СУБД, она создается с учетом выбранной модели хранения данных, например реляционной, сетевой или иерархической. Однако, приступая к физическому проектированию базы данных, прежде всего необходимо выбрать конкретную целевую СУБД. Поэтому физическое проектирование неразрывно связано с конкретной СУБД. Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных.

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

В случае реляционной модели данных под этим подразумевается следующее:

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

• определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;

• разработка средств защиты создаваемой системы.

Этапы концептуального и логического проектирования больших систем следует отделять от этапов физического проектирования. На это есть несколько причин.

• Они связаны с совершенно разными аспектами системы, поскольку отвечают на вопрос, что делать, а не как делать.

• Они выполняются в разное время, поскольку понять, что надо сделать, следует прежде, чем решить, как это сделать.

• Они требуют совершенно разных навыков и опыта, поэтому требуют привлечения специалистов различного профиля.

Проектирование базы данных — это итерационный процесс, который имеет свое начало, но не имеет конца и состоит из бесконечного ряда уточнений. Его следует рассматривать прежде всего как процесс познания. Как только проектировщик приходит к пониманию работы предприятия и смысла обрабатываемых данных, а также выражает это понимание средствами выбранной модели данных, приобретенные знания могут показать, что требуется уточнение и в других частях проекта. Особо важную роль в общем процессе успешного создания системы играет концептуальное и логическое проектирование базы данных. Если на этих этапах не удастся получить полное представление о деятельности предприятия, то задача определения всех необходимых пользовательских представлений или обеспечения защиты базы данных становится чрезмерно сложной или даже неосуществимой. К тому же может оказаться затруднительным определение способов физической реализации или достижения приемлемой производительности системы. С другой стороны, способность адаптироваться к изменениям является одним из признаков удачного проекта базы данных. Поэтому вполне имеет смысл затратить время и энергию, необходимые для подготовки наилучшего возможного проекта.

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

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

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

Структура индекса связана с определенным ключом поиска и содержит записи, состоящие из ключевого значения и адреса логической записи в файле, содержащей это ключевое значение. Файл, содержащий логические записи, называется файлом данных, а файл, содержащий индексные записи, — индексным файлом. Значения в и