Презентация на тему Проектирование баз данных

данных»

и содержании процесса проектирования баз данных;
Учебные
- изложить основные положения

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

[гриф МЧС] / А.Ю. Иванов; МЧС России. – СПб.: СПбУ

ГПС МЧС России, 2010. – 204 с.
 
Дополнительная:
1. Кузин, Александр Владимирович. Базы данных: учебное пособие: [гриф УМО] / А.В. Кузин, С.В. Левонисова. – 4-е изд., стер. – М. : Академия, 2010. – 320 с.
2. Мамаев Е.В. SQL Server 2000. – СПб.: БХВ-Петербург, 2004. – 1280 с.
3. Грэй П. Логика, алгебра и базы данных / Пер. с англ.- М.: Машиностроение, 1989. – 368 с.

(МЧС России - 2030) Доклад Министра РФ по делам

гражданской обороны, чрезвычайным ситуациям и ликвидации последствий стихийных бедствий. М.: МЧС России, 2012».
Государственный доклад «О состоянии защиты населения и территорий Российской Федерации от чрезвычайных ситуаций природного и техногенного характера в 2012 году».
Основы единой государственной политики РФ в области ГО на период 2020 года (утверждена Президентом РФ от 03.09.2011, № ПР-2613).
Стратегия инновационного развития РФ на период до 2020 года (утверждена распоряжением Правительства РФ от 08.12.2011 года, №2227-р).
Федеральный закон от 22.07.2008 г. №123 – ФЗ (ред.от 10.07.2012 ) «Технический регламент о требованиях пожарной безопасности».
Закон РФ от 29 декабря 2012 года №273-ФЗ «Об образовании в Российской Федерации» с изменениями и дополнениями на 2013 год.
Организационно-методические указания по подготовке территориальных органов, спасательных воинских формирований, подразделений федеральной противопожарной службы, военизированных горноспасательных частей, образовательных учреждений и организаций МЧС России в области гражданской обороны, предупреждения и ликвидации чрезвычайных ситуаций, обеспечения пожарной безопасности и безопасности людей на водных объектах на 2014-2016 годы.
Федеральный закон № 149 «Об информации, информационных технологиях и о защите информации» от 27 июля 2006 г.

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

реализация.

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

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

инфологической модели (ИЛМ) предметной области. Исходными данными для этого

являются результаты, полученные на предыдущем этапе, а также знания о специфике предметной области. ИЛМ должна отображать объекты (сущности) предметной области, их учитываемые характеристики – атрибуты, а также взаимные связи между объектами и атрибутами. ИЛМ представляется чаще всего в виде графической диаграммы.
Кроме формирования ИЛМ, на данном этапе дается характеристика всех атрибутов, учитываемых в базе данных. Она предполагает указание принадлежности атрибута (к объекту или к связи), типа данных, к которому относятся значения атрибутов, их длины, области допустимых значений, ограничений целостности, выводимости из значений других атрибутов и ряд других характеристик. Результаты оформляются в табличном виде.

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

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

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

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

Цели проектирования отношений
Основными целями проектирования реляционных БД являются:
достижение полноты

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

целью. Предполагается, что БД должна содержать все данные, представляющие

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

декомпозиции исходного отношения, что лежит в основе рассматриваемого ниже

метода проектирования.

тем, что разбиение одного отношения на два или более

меньших желательно для исключения определенных проблем, но является неудобным для пользователя. Таким образом, нельзя допускать неограниченный рост числа отношений. Для некоторых отношений очень важна проблема обновления (например, для отношения Ф_П_Д). Необходимо уметь обнаруживать такие отношения и «нормализовать» их посредством разбиения предписанным образом. Такое разбиение одного отношения на два или более в соответствии со специальной процедурой разбиения называется нормализацией. На нормализации основывается большинство методов проектирования схем реляционных БД.Последние две цели противоречат друг другу, поэтому в реальности определяется взаимный компромисс между ними, что является частью завершающего этапа проектирования.

схемы БД является составление единственного отношения, в которое вносятся

все учитываемые в БД атрибуты. Такое отношение носит название универсального. Примером универсального отношения является отношение РАСПИСАНИЕ (рис.3), в которое входят следующие атрибуты:
условный номер преподавателя – ПРЕП#;
фамилия преподавателя – ФАМ;
номер преподавательской – ПАУД;
номер телефона в преподавательской – ТЕЛ;
место проведения занятия – МЕСТО;
день недели - ДЕНЬ_НЕД;
время проведения занятия – ЧАСЫ;
учебная группа – ГРУППА;
шифр дисциплины – ШИФР.

отношение используется в качестве отправной точки при проектировании БД.

Однако существует ряд причин, почему не следует использовать данное отношение в качестве единственного в БД. Это обусловлено тем, как будет использоваться БД и какое воздействие на данные в отношении РАСПИСАНИЕ будут оказывать определенные операции. Различаются три специфичные проблемы: проблема, связанная с обновлением (модификацией) данных в БД; проблема, обусловленная необходимостью удаления кортежей; проблема, обусловленная необходимостью вставки новых кортежей. Эти проблемы обычно называют аномалиями вставки, удаления и обновления, понимая под аномалией отклонение от нормы.

преподаватель, который еще не проводит занятия, то для него

необходимо включить в БД кортеж с нулевыми (пустыми) значениями для атрибутов МЕСТО, ДЕНЬ_НЕД, ЧАСЫ, ГРУППА и ШИФР. Пример такого включения представлен на рис.4. Пустые значения в полях МЕСТО и ГРУППА интерпретируются СУБД как 0 (ноль).Если теперь требуется получить ответ на запрос: «Выдать список преподавателей, которые проводят занятия в группах, номера которых меньше 130», то в этот список попадет и преподаватель Семенов, хотя он вообще не проводит ни одного занятия.

даления из БД единственного кортежа, в котором ПРЕП#=255. Он

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

преподавательской (например, в ПАУД=119), то это изменение следует проследить

не только для Иванова, находящегося в ней, но и для других преподавателей этой аудитории, например, Смирнова).Если не произвести эти обновления в полном объеме, то в результате получается противоречивая БД.

что одной из задач проектирования реляционной БД является разбиение

отношений с нежелательными аномалиями. Вопросы, которые необходимо решить при этом (т.е. в ходе нормализации), сводятся к следующим:
1) как получить исходные отношения (до начала разбиения)?
2) как распознать «плохие» отношения?
3) как выполнить разбиение?
4) что является признаком завершения разбиения?

БД, общее число хранимых атрибутов в которой невелико, исходным

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

если каждый его элемент имеет, и всегда будет иметь

атомарное значение.
Определение. Если даны два атрибута А и В и каждому значению А в отношении соответствует ровно одно значение В, то говорят, что В функционально зависит от А (В F-зависит от А, или А → B).В определении F-зависимости для атрибутов БД просматривается аналогия с определением понятия функция в математическом анализе (здесь А выступает в роли аргумента, а В – в роли функции).Если между тремя атрибутами А, В и С установлены F-зависимости А → В и В → С, то говорят, что между А и С существует транзитивная F-зависимость.

А выступает в роли первичного ключа, т.е. по значению,

которое принимает атрибут А, можно однозначным образом выбрать из отношения единичную запись.Определение. Если в отношении существует А → В, причем А является составным атрибутом, но ни для какого подмножества А'= А не выполняется условие А'→ В, то говорят, что А является детерминантом (или определителем) В.Рассмотрим введенные определения на примере отношения РАСПИСАНИЕ (см. рис.3). Условно обозначим имена атрибутов буквами А, В, C, D, E, F, G, H и I в таком порядке, как они представлены в отношении (т.е. ПРЕП# обозначим А, ФАМ – В и т.д.).

B
A → C
A → D
C → D
D → C
F,

G, H → A
F, G, H → E
F, G, H → I.
Отношение имеет единственный возможный ключ и четыре детерминанта: , , и .

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

аномалий в БД устраняется в случае преобразования каждого отношения в нормальную форму Бойса-Кодда.
Определение. Отношение находится в нормальной форме Бойса-Кодда (НФБК), если и только если каждый детерминант отношения является его возможным ключом.В нашем примере имеются детерминанты, которые не являются возможным ключом. Следовательно, отношение РАСПИСАНИЕ не находится в НФБК и должно быть подвергнуто нормализации.

баз данных существуют и другие нормальные формы, наиболее известными

из которых являются 2НФ, 3НФ и 4НФ. Между всеми этими формами существует определенное взаимное соответствие. Приведем его, опуская комментарии, чтобы показать место НФБК в ряду нормальных форм:
2НФ – это 1НФ, в которой каждый непервичный атрибут полностью зависит от каждого первичного ключа;
3НФ – это 2НФ, в которой ни один из непервичных атрибутов не является транзитивно зависимым от первичного ключа;
НФБК – это 3НФ, в которой никакой атрибут не зависит транзитивно ни от одного ключа (это другое определение НФБК);
4НФ – это НФБК, в которой устранены так называемые многозначные F-зависимости.

методов нормализации отношений. Сущность его заключается в следующем. Пусть

имеется отношение R(A,B,C,D,E,...), которое не находится в НФБК.Декомпозиция без потерь производится в два шага.
Шаг 1. Выделяется F-зависимость, которая является причиной отсутствия НФБК. Предположим, такой F-зависимостью является C→D.
Шаг 2. Отношение R(A,B,C,D,E,...) разделяется на следующие два: R1(A,B,C,E,...) и R2(С,D).Отношение R2 иначе называется проекцией R по атрибутам F-зависимости C→D.Декомпозиция называется «без потерь», т.к. исходное отношение R восстанавливается из отношений R1 и R2 путем применения к последним реляционной операции соединения по общему полю.Простым правилом выбора функциональной зависимости для проекции на первом шаге декомпозиции является поиск транзитивной зависимости вида A→C→D с последующим использованием C→D для проекции.

БД, очень велико (считается, что достаточным пороговым числом является

число 20), возникают определенные трудности применения метода декомпозиции, равно как и других методов, в которых анализ F-зависимостей производится на начальном этапе (метода синтеза, например).Одним из методов, широко используемым в настоящее время для нормализации БД с большим числом атрибутов, является метод «сущность-связь». В этом методе F-зависимости анализируются на конечном этапе, когда уже получен набор отношений путем преобразования по заранее известным правилам инфологической модели (ИЛМ), представленной в форме диаграммы «сущность-связь» (entity-relation diagram), иначе обозначаемой как ER-диаграмма.

в три этапа:
1) формирование ИЛМ в виде ER-диаграммы (осуществляется

на этапе инфологического моделирования);
2) преобразование ER-диаграммы в первоначальную схему БД;
3) анализ каждого отношения первоначальной схемы БД на предмет нахождения в НФБК с последующей декомпозицией найденных ненормализованных отношений.

ER-диаграммы на втором этапе осуществляется по правилам, позволяющим практически

всегда получать отношения в НФБК.Приведем основные понятия ER-диаграммы на основе примера, приведенного на рис.6.

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

друга значениями этих свойств. Экземпляры одной сущности должны допускать однозначную идентификацию.На ER-диаграмме сущности обозначаются прямоугольниками.Сущностями, представленными на рис.6, являются ПРЕПОДАВАТЕЛЬ и КУРС.Определение. Связь представляет собой логическое соединение между двумя или более сущностями. Связь имеет экземпляры. Экземпляры связи соединяют экземпляры сущностей.На ER-диаграмме связи обозначаются ромбами, связанными с соответствующими сущностями.На рис.6 представлена одна связь – ЧИТАЕТ, соединяющая сущности ПРЕПОДАВАТЕЛЬ и КУРС.

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

сущности, называется ключом сущности. Ключом связи, позволяющим однозначно идентифицировать экземпляр связи, является набор ключей связанных сущностей.На ER-диаграмме атрибуты подписываются под сущностями или связями, которые они определяют. Ключи подчеркиваются или помечаются знаком #.На рис.6 сущность ПРЕПОДАВАТЕЛЬ имеет атрибуты ПРЕП# (ключ), ФАМ, ПАУД, ТЕЛ, ДОЛЖНОСТЬ, АДРЕС. Сущность КУРС имеет атрибуты ШИФР# (ключ), НАИМЕНОВАНИЕ, КОЛ_ЧАСОВ. Ключом для связи ЧИТАЕТ является пара ПРЕП#, ШИФР#. Неключевыми атрибутами связи ЧИТАЕТ являются ДЕНЬ_НЕД и ЧАСЫ.

(один-ко-многим), М:1 (многие-к-одному) или M:N (многие-ко-многим), которое указывает на

возможность или невозможность одновременной связи одного экземпляра одной сущности со многими экземплярами другой (рис.7).

показана степень связи M:N.Определение. Класс принадлежности сущности к связи

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

взятой в рамку, а необязательный – точкой без рамки,

установленной на линии связи. На рис.6 сущность ПРЕПОДАВАТЕЛЬ имеет необязательный класс принадлежности (т.е. полагается, что может быть преподаватель, не читающий никакой курс), а сущность КУРС имеет обязательный класс принадлежности (все курсы должны читаться каким-либо преподавателем).Построением ER-диаграммы предметной области завершается первый этап проектирования схемы БД.

наличия атрибутов связи и арности связи каждая связь на

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

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

атрибутов и она имеет степень 1:1, то существует четыре варианта ее преобразования в схему БД.

то связь преобразуется в одно отношение – расширенное отношение

связи, включающее все атрибуты связываемых сущностей;2. Если первая сущность имеет обязательный, а вторая – необязательные классы принадлежности, то связь преобразуется в два отношения: первое – расширенное отношение первой сущности, второе – обычное отношение второй сущности.3. Третий вариант аналогичен второму с изменением номеров сущностей.4. Если обе сущности имеют необязательные классы принадлежности, то связь преобразуется в три отношения: обычное отношение первой сущности, обычное отношение связи и обычное отношение второй сущности.Остальные варианты, приведенные в табл.1 для других степеней и арностей связи, расшифровываются аналогичным образом.

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

ограничениями целостности. Такие правила проявляются в различных формах.
Контроль значений атрибутов отношения. Здесь могут выполняться различные виды проверок:
1)проверка типа данных (не должно быть возможности ввода текстовой информации в поле, предназначенное для хранения чисел);
2)проверка интервала (вводимое значение не должно выпадать из указанных границ значений);

значению другого (например, дата приема сотрудника на работу не

должна быть меньше даты его рождения).
Целостность ключа. Означает требование, чтобы поля первичного ключа не были пустыми. Кроме того, значения первичного ключа в отношении не должны повторяться.
Ссылочная целостность. Требует, чтоб значению внешнего ключа некоторого кортежа некоторого отношения обязательно соответствовало бы такое же значение первичного ключа другого отношения.

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

ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.

составленному фирмой Systems Development Inc. в 1996 г. по

результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий. Ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно.

множество примеров их неудачного внедрения, в результате чего CASE-средства

становятся «полочным» ПО (shelfware). В связи с этим необходимо отметить следующее:
-CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;
-реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;
-CASE-средства обеспечивают возможности для получения существенной выгоды только после успешного завершения процесса их внедрения.

безоговорочные утверждения относительно реального удовлетворения тех или иных ожиданий

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

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

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

проектируемых баз данных
Оценка объема БД является неотъемлемой частью общей

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

атрибутов соответствующего отношения. Файлы-таблицы содержат служебную часть с описанием

структуры отношения и область данных, содержащую кортежи значений атрибутов.
Файлы-индексы содержат первичные или вторичные индексы для быстрого доступа к данным файлов-таблиц.
Остальные файлы (файлы-запросы, файлы-отчеты и прочие файлы) предназначены для реализации предопределенных запросов пользователей, отчетов и прочих документов.
Расчет объема проектируемой БД основывается на расчете объема, отводимого для областей данных файлов-таблиц. Объем остальной части БД полагается не превышающим 10-20% от этого значения.

возможное число кортежей (записей) в нем.
Используя это понятие, объем

области данных i-го файла-таблицы рассчитывается по формуле
, (1)
где Ni –мощность i-го файла-таблицы; Di – длина кортежа i-го файла-таблицы.
Длина кортежа i-го файла равняется сумме длин (размеров) всех атрибутов, составляющих схему отношения этого файла, т.е.
, (2)

где dij – размер j-го поля (атрибута) в i-м файле БД (j=1,...,ni).
Итоговая оценка объема БД, содержащей M файлов, определяется выражением
, (3)

модели БД (заданной, например, в виде ER-диаграммы) и ее

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

связываемая мощность равна непосредственно мощности сущности, а для сущностей

с необязательным классом принадлежности – меньше мощности сущности.
Мощностью связи на ER-диаграмме называется максимально возможное число экземпляров этой связи.
Если степень связи равна 1:1, то мощность связи равна связываемым мощностям охватываемых ею сущностей.
Если степень связи равна 1:M, то мощность связи равна связываемой мощности второй сущности или произведению связываемой мощности первой сущности на количественное значение параметра M степени связи.
Если степень связи равна M:N, то мощность связи равна произведению связываемой мощности одной сущности на количественное значение параметра M (или N) степени связи другой сущности.

оценке оперативности выполнения запросов в качестве основного показателя чаще

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

ОП (в дальнейшем по тексту – просто обменов) используется

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