Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Любой записи СУБД присваивается внутренний номер. Ключ БД не приравнивают к ключу записи. При задачи значения ключа записей пользователем – RID устанавливается системой при размещении.

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

При описании типа записи (имя таблицы) администратором БД определяется область хранения. ОХ – участок памяти (совокупность страниц) внутри которого размещаются записи нужного типа. За пределами области хранения размещение записей не возможно.

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

Характеристики файла данных: Параметры блокирования страниц.

Формат и длина страницы

Запись может быть сегментирована, если она не помещается на одной странице.

Файл БД представлен на рисунке 3.

Рисунок 3 – Файл БД

Определение месторасположение записи с данным ключом по первичному ключу

1. Блочный поиск – записи упорядочиваются по ключу. И при сканировании файла рассматривается не любая запись, а каждая сотая в последовательности возрастания ключей. Далее область поиска снижается.

2. Последовательное сканирование файла – сканируется файл с проверкой ключа каждой записи. Эффективен лишь только для файлов с последовательным доступом. Записи обязаны быть упорядочены по ключу.

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

4. Индекс на произвольные файлы – записи располагаются в произвольной последовательности (в порядке ввода в БД). Непоследовательный файл– индексируется точно так же, как и последовательный. Но для этого требуется больший по размеру индекс, т.к. он должен содержать по одному элементу для каждой записи файла, а не для блока записей. Кроме того, в нем должны содержаться полные абсолютные адреса.

5. Двоичный поиск – рассматривает запись в середине области, в которой выполняется поиск и ее запись сравнивается с поисковым ключом. Делится пополам.

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

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

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

1.7.2 Организация индексных таблиц

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

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

Имеет смысл различать индексирование по первичному ключу и вторичное индексирование.

Первичное индексирование

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

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

Особенности первичного индексирования:

1. первая начальная загрузка обязана быть выполнена обязательно с предварительной сортировкой;

2. ключ индексирования обязан иметь уникальное неизменное значение;

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

Вторичное индексирование

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

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

КБД – ключ БД.

Особенности вторичного индексирования:

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

• таблицы вторичного индексирования создаются в любое время;

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

2 Разработка базы данных

2.1 Техническое задание

Сущностью дипломного проекта является создание базы данных для предприятия, оказывающего услуги в сфере землеустройства. Предприятие (заказчик) имеет организационно-правовую форму – общество с ограниченной ответственностью. Полное название предприятие: ООО «Вяземский землеустроитель». Фирма основана 20 октября 2011 года. Регистратор – Межрайонная Инспекция Федеральной Налоговой Службы №4 по ХАБАРОВСКОМУ краю, по адресу 682950, Хабаровский край, г Вяземский, ул Ленина, д 26, оф 44. Предприятие ООО «Вяземский землеустроитель» руководствуется Федеральным закон Российской Федерации от 24 июля 2007 г. N 221-ФЗ «О государственном кадастре недвижимости».

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

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

1) удобство в использовании;

2) база данных находится на одном ПО;

3) простота в обслуживание;

4) предоставление необходимой коммуникации.

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

1. Фамилия Имя Отчество;

2. дата рождения;

3. серия и номер паспорта;

4. кем выдан паспорт;

5. код подразделения;

6. дата выдачи;

7. номер СНИЛС;

8. номер телефона.

Рисунок 4 – База данных предприятия ООО «Вяземский землеустроитель»

Необходимо создать БД, содержащую данную информацию о всех заказчиках.

База данных должна удовлетворять следующим требованиям:

1. налаженная процедура поиска определенного заказчика;

2. максимальное удобство пользователя при работе (понятный интерфейс);

3. возможность запуска дополнительной информации( договора, распоряжения, план кадастрового участка и т.д.);

4. возможность фильтрации клиентов.

Прежде чем приступить к созданию объектов базы данных, как таблицы, формы и отчеты, нужно разработать их проект. Основное предназначение проекта – выработка четкого пути реализации. База данных – довольно трудный объект, и время, которое будет затрачено на ее планирование, может значительно сократить сроки ее разработки. Если продуманной структуры базы данных нет, то это может привести к необходимости постоянной переделки и перенастраиванию объектов базы данных [26].

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

При разработке эскиза необходимо ответить на следующие вопросы:

1. таблицы, необходимые для базы данных;

2. данные необходимые для создания базы данных;

3. как эти таблицы будут связаны друг с другом;

4. тип данных, которые должны иметь поля таблиц;

5. информация, необходимая для получения из форм и отчетов;

6. нужны ли в запросах вычисляемые поля;

7. запросы, необходимые для создания форм и отчетов;

8. создание макросов необходимых для автоматизации работы с БД.

2.2 Разработка базы данных

Процесс проектирования базы данных определяется в два шага: разработку логической организации базы данных и создание ее на носителе [9].

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

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

В нынешнее время разрабатываются и используются на ПК около двадцати СУБД. Они имеют развитый язык программирования и предоставляют пользователю возможность использовать удобные средства интерактивного взаимодействия с БД. Самая популярная из программных СУБД является Microsoft Access.

Одной из ведущих причин известности Access является по сути то, что она настольная СУБД и данное приложение вобрало в себя почти все возможности систем управления реляционными базами данных архитектуры клиент-сервер, называемой также SQL базой данных. Access включают в себя сложные функции и имеет возможность прослужить великолепным инструментом для проф. создателя приложений БД и не смотря на это его использование не вызывает проблем не у непрофессиональных пользователей, и не у тех, кто никогда не работал с СУБД. Кнопки на панелях инструментов копируют главные команды меню, расширенный набор мастеров и настроек управляет буквально всеми параметрами создания и изменения объектов БД [13]. С помощью Access имеется возможность создавать многопользовательских приложений, в которых файлы БД могут быть разделяемыми ресурсами в локальной сети. Microsoft Access для хранения объектов БД имеет личную индивидуальную структуру для хранения всех связанных отчетов, таблиц, форм, запросов в одном файле.

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

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

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

• наглядность представления информации;

• возможность использования информации, введенной в другую базу;

• простота ввода информации;

• удобство поиска и отбора информации;

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

При разработке базы данных выделяют следующие этапы работ [23].

I этап. Постановка проблемы

Формирование задания по созданию БД. Подробное описание состава базы, назначение и цели ее создания, виды работ в этой базе (отбор, изменение данных дополнение, печать или вывод отчета и т.д.).

II этап. Анализ объекта

Характеристики

Список файлов ВКР