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

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

Недостатки прямого доступа к памяти.

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

2. Значительно замедляется время работы БД, при появлении большого числа синонимов в БД устранение этого эффекта – открытая адресация и метод цепочек .

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

Алгоритм поиска свободного места в БД.

Последующий просмотр памяти до свободного места.

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

Проектирование структуры БД

Должно включать определенные ее состав и структуры

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

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

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

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

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

ТАБЛИЦА.

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

Построение датологической модели БД.

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

Если для данной СУБД имеется система автоматизации СУБД CASE-ALLE – Средство проектирования БД, то с целью оценки качества проекта и целенаправленности воздействия на созданную структуру БД, желательно сформировать алгоритм проектирования положенный в ее основу.

При проектировании ДМ БД используется графическая (диаграммо - логическая) структура и аналитическая (описание на ЯОД схем, подсхем, форм ее представления БД).

При ручном проектировании построение ДМ начинают с графического построения структуры БД со всевозможными внутренними и внешними связями.

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

ГРАФИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ СТРУКТУРЫ БД.

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

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