Эта запись означает, что пакет образует собственное пространство имен.
Как правило, элементы модели, входящие в пакет, логически связаны между собой.
Если количество классов в системе достаточно велико, иногда прибегают к построению диаграмм пакетов, разбивая систему на части на более высоком уровне, чем диаграммы классов.
Билет 50.
Диаграмма классов
Под классом в языке UML понимается множество объектов, обладающих одинаковой структурой, свойствами, отношениями с другими объектами.
Графически в самом общем виде класс представляется в виде прямоугольника с че-тырьмя секциями (на рис. 3.8, а показан формат, на рис. 3.8, б — пример). Любая из секций, кроме секции имени класса, может отсутствовать. В этом случае она не изображается либо оставляется пустой. Как правило, на начальном этапе проек-тирования разработчик располагает только общими представлениями о будущей структуре системы. В дальнейшем, по мере разработки, уточняются роли, свойства каждого класса, что находит отражение на соответствующих диаграммах классов.
Абстрактным классом называется класс, который не имеет экземпляров. Абстрактные классы весьма удобно использовать при конструировании иерархии в качестве промежуточных классов. Все, что касается абстрактных классов, в языке UML выделяется курсивом (в нотации Буча абстрактный класс помечается буквой А в треугольнике, обращенном вершиной вниз).
Имя класса в языке UML принято писать полужирным шрифтом в самой верхней секции графического изображения класса (имя абстрактного класса — полужирным шрифтом и курсивом). Здесь же указывается информация об отношениях этого класса к абстрактным классам, от которых он унаследован, а также служебная информация о процессе проектирования класса (лицо, ответственное за проектирование класса, язык реализации, номер версии и т. д.).
Свойства класса определяют состояние экземпляров класса (объектов). В общем виде формат записи свойства можно представить в виде строки
видимость имя_свойства [кратность]: тип_свойства = значение_гю_умолчанию Ниже перечислены аргументы этой строки.
□ видимость — видимость свойства для других классов. Допустимые значения:
■ public (или знак +) — свойство класса доступно любому другому классу;
■ protected (или знак #) — свойство класса доступно только экземплярам этого класса и потомкам данного класса;
■ private (или знак -) — свойство класса доступно только экземплярам этого класса.
Отсутствие указания на категорию доступа означает, что видимость не указы-вается.
ПРИМЕЧАНИЕ
Как уже отмечалось, диаграмма классов может использоваться для автоматической генерации программного кода на выбранном языке программирования. Следует иметь в виду, что в разных языках значения видимости свойства (атрибута), задаваемые по умолчанию, разные.
□ тип_свойства — тип свойства. Этот тип выбирается, исходя из языка реализации проекта (С++, Delphi, Java и других).
□ кратность — диапазон принимаемых свойством значений с учетом типа. Так, если в качестве кратности свойства имя_клиента указан диапазон 1..5 и тип String, то это свойство может принимать, например, следующие значения: Иван Петров, Уильям Джефферсон Клинтон, Мехти Асадулла оглы Мамедов, то есть значения/содержащие не более 5 слов. Если же в качестве кратности свойства доход указан диапазон 0..* и тип Currency, значение этого свойства может принимать любое положительное значение в денежном формате.
□ значение_по_умолчанию — начальное значение свойства, которое в последующем можно изменить программно. Если в строке определения свойства вместо одного знака равенства (=) указать два (==), то значение по умолчанию программно изменить будет нельзя.
Например, следующая запись для свойства класса Менеджер означает, что по умолчанию всем сотрудникам, замещающим эту должность, первоначально устанавливается заработная плата 700 долларов: Заработная плата [0..*]: Currency = 700 $
ПРИМЕЧАНИЕ
Язык UML помимо проектирования информационных систем, нашел применение в сфере аналитики бизнеса. Отображенная на диаграммах структура фирмы и ее деятельности позволяет выявить, например, перегруженность определенных отделов, участки, тормозящие принятие управленческих решений. На основе полученных данных вырабатываются рекомендации по совершенствованию деятельности организаций. UML-диаграммы в этом случае служат инструментом анализа и иллюстрациями сделанных выводов.
Методы класса служат для обработки свойств класса и характеризуют поведение
экземпляров класса.
Формат записи метода выглядит так:
видимость имя_метода (список параметров): тип_значения {строка-свойство} Ниже перечислены аргументы этой строки.
□ видимость — этот аргумент определяется аналогично видимости свойств.
□ имя_метода — идентификатор метода.
□ список параметров — перечень разделенных запятой формальных параметров. Наличие круглых скобок обязательно. Каждый из формальных параметров может быть представлен в следующем виде:
вид_параметра имя_параметра: тип_параметра = значение_ло_умолчанию Здесь
■ вид_параметра — входной (передаваемый методу), выходной (возвращаемый методом) или универсальный (значение параметра может изменяться методом) параметр (обозначается соответственно in, but или inout);
■ тип_параметра — тип параметра, определяемый языком реализации класса.
□ тип_значения — тип значения. Определяется языком реализации класса.
□ строка-свойство — значения свойств, которые могут относиться к данному па-раметру. Метод, не изменяющий состояния объекта, обозначается строкой-свойством {query}. Строка-свойство {concurrency = sequential} указывает на необходимость обращения к методу во время вызова другого метода, строка-свойство {concurrency = concurrent} — на возможность параллельного вызова методов. Строка-свойство {concurrency = guarded} обращает внимание на необходимость принятия дополнительных мер по контролю исключительных ситуаций.
□ Имя и тип метода с областью действия на весь класс подчеркивается. Например, изменение фона одного окна программы автоматически изменяет цвет фона всех окон системы, как это имеет место при щелчке правой кнопкой мыши на свободном участке рабочего стола и изменении вида окон Windows на вкладке Оформление окна Свойства:Экран. По умолчанию областью действия метода определяется экземпляр класса (объект). В данном случае изменение цвета фона окна (формы) затронет только это окно.
□ Абстрактные методы, то есть методы, не задействованные в данном классе, вы-деляются курсивом или помечаются строкой-свойством {abstract}.
Примером обозначения метода «открыть» класса File может служить запись
+ open ()
Этот метод не возвращает никакого результата своего выполнения.
Следующая запись может означать, что результатом вызова метода является авто-матическая генерация приказа по организации, в котором сотруднику предоставляется ежегодный оплачиваемый отпуск:
издать приказ (сотрудник): приказ по форме 1-А {"отпуск"}
В нотации UML между компонентами диаграммы классов могут существовать различные отношения.
□ Отношение зависимости (dependency relationship) указывает на общую взаимосвязь компонентов диаграммы. Графически эта связь изображается пунктирной стрелкой от зависимого класса к независимому (рис. 3.9;).
Кредит «derive»
>ч Клиент
Сумма кредита
Доход
Возраст
Профессия
У
Рис. 3.9. Графическое изображение отношения зависимости
Ключевое слово (стереотип) над стрелкой означает, что свойства класса Кредит, в частности сумма кредита, выдаваемая банком заемщику, могут быть определены, исходя из характеристик заемщика (свойств класса Клиент): ежемесячного дохода, возраста и других. Ключевое слово является необязательным элементом. Помимо значения «derive», оно может принимать следующие значения:
■ «access» — указывает недоступность свойств и методов независимого класса для зависимого;
■ «import» — открытые свойства и методы независимого класса (источника) становятся частью зависимого класса, как если бы они были объявлены не-посредственно в нем;
■ «bind» — класс может использовать другой класс в качестве шаблона;
■ «refine» — зависимый класс уточняет класс-источник-в силу исторических причин.
□ Отношение ассоциации (association relationship) устанавливает некоторую связь между классами системы. Графически это отношение обозначается сплошной линией между классами (рис. 3.10).
Клиент 0*.. Покупает 0*.. Товар
Рис. 3.10. Графическое изображение отношения ассоциации
Пример на рисунке означает, что клиент делает покупки. При этом любой по-купатель может купить любой товар или не купить никакой, и любой товар может быть продан любому покупателю или не быть купленным никем.
Отношение ассоциации может связывать большее количество классов (N-ap-ная ассоциация). На диаграмме классов такая ассоциация изображается ромбом (рис. 3.11).
Клиент 0*..
0*.. Товар
1..10
Продавец
Рис. 3.11. N-арная ассоциация
Приведенная ассоциация указывает, что покупатель может приобрести товар у любого из десяти поставщиков, входящих в данную систему продаж.
Частными случаями отношений ассоциации являются исключающая ассоциация, агрегация и композиция:
■ исключающая ассоциация (xor-association) указывает на возможность связи определенного класса только с одним из нескольких классов (рис. 3.12);
М отношение агрегации означает включение нескольких классов в другой класс (графически отношение агрегации показано на рис. 3.13 и означает, что в состав класса Сервиз в качестве самостоятельных единиц могут входить тарелки и другие столовые приборы);
Билет 51.
Диаграмма состояний
В процессе функционирования информационной системы свойства объектов системы будут принимать различные значения, а объекты системы — различные состояния. Состояния объектов, переходы объектов из одного состояния в другое, сообщения, которыми обмениваются объекты, образуют динамическую составляющую информационной системы.
Для моделирования динамики информационной системы служат диаграммы со-стояний, деятельности, последовательности и кооперации, каждая из которых по-казывает будущую систему в своем ракурсе.
Диаграмма состояний описывает процесс изменения одного класса, а точнее — одного экземпляра класса. На диаграмме отражаются состояния и переходы между состояниями объекта под воздействием внешних факторов.
Состояния (states) на диаграмме состояний показываются прямоугольниками с за-кругленными вершинами. В каждом таком прямоугольнике может быть одна (обя-зательная) секция, в которой записывается имя состояния (для имени рекомендуется использовать глаголы, причастия и деепричастия), и несколько других секций, обозначающих действия объекта в этом состоянии.
Начальное состояние изображается черным кружком, конечное — черным кружком в белом кольце. На диаграмме, показанной па рис. 3.20, объект из начального состояния переходит в некоторое другое состояние, в котором выполняется действие 1, а затем — в конечное состояние.
Начальное и конечное состояния могут отсутствовать. Примером отсутствия ко-нечного состояния может служить система, которая запускается один раз, а дальше функционирует в непрерывном режиме. Примером отсутствия начального состояния может служить функционирующая система, неизвестно когда возникшая. Примером отсутствия как конечного, так и начального состояния могут служить циклические изменения какого-либо объекта. Внутренние действия состояния описываются в следующем формате:
метка / действие
Здесь аргумент метка представляет собой одно из следующих ключевых слов:
□ entry — действие выполняется в момент перехода объекта в данное состояние;
□ exit — действие выполняется в момент выхода объекта из данного состояния;
□ do — действие выполняется во время нахождения объекта в данном состоянии;
□ include — обращение к подсостоянию (substate) данного состояния объекта.
Составное состояние (composite state), или суперсостояние, — это такое состояние объекта, которое включает в себя несколько подсостояний. Использование подсостояний удобно, например, когда на диаграмме требуется показать состояния объекта в зависимости от одного из его свойств. При этом другие свойства объекта также могут изменяться, и если такие состояния и переходы между ними показывать в качестве самостоятельных состояний, то диаграмма будет перегружена обозначениями, затрудняющими восприятие смысла диаграммы — демонстрации переходов между состояниями в зависимости от конкретного свойства.
Билет 52.
Диаграмма активности
Диаграммы активности позволяют показать движения потоков данных в проекти-руемой системе.
Диаграммы активности напоминают хорошо знакомые многим алгоритмы, только несколько модифицированные. Пример диаграммы активности показан на рис. 3.28. Диаграмма демонстрирует процесс рассмотрения заявки на получение кредита в не-которой организации.
Поясним применяемые обозначения. Начальное и конечное состояния изображаются так же,-как на диаграмме состояний. Прямоугольником с округлыми боковыми сторонами изображается действие над данными (состояние действия). Внутри такого прямоугольника указывается производимое действие (это может быть текст, математическое выражение и т. д.).
Действие может содержать несколько поддействий. Если на диаграмме их показывать нецелесообразно, используют обозначение вложенности действий. Так, в приведенном примере действие Удовлетворение заявки включает в себя несколько под-действий, среди которых могут быть оценка достоверности данных о клиенте, оценка правильности расчетов, непосредственно принятие решения.
Движение данных (переходы) изображается сплошными стрелками. Возле стрелок может быть указано сторожевое условие. Если движение данных предусматривает ветвление, то указание условия обязательно (-в примере на рис. 3.28 оно не показано). Символ ветвления графически изображается ромбом, из которого выходят две или более стрелки. Разделение потока данных и слияние параллельных потоков данных изображается сплошной жирной чертой, связывающей стрелки движения потоков данных.
Диаграммы активности позволяют показать разделение ответственности различных субъектов за выполнение операций путем введения дорожек (swimlanes). В приведенном примере таких дорожек четыре: Регистратор, Специалист по финансовым рискам, Управляющий, Служба безопасности.
Передаваемые данные могут быть указаны на диаграммах активности в явном виде. Например, передачу заказа между отделами организации иллюстрирует рис. 3.29. В качестве передаваемых данных может быть указан пользователь, например, при построении карты веб-сайта.
Вектор времени на диаграммах активности в явном виде не воспроизводится.
Билет 53.
Диаграмма последовательности
Идеология объектно-ориентированного программирования заключается в описании поставленной задачи образами некоторых самостоятельных сущностей (объектов), которые в процессе функционирования системы обмениваются сообщениями. Диа-граммы последовательности служат инструментом отображения такого обмена.
Основными компонентами диаграмм последовательности являются пользователь, объект, линия жизни объекта (object lifeline), сообщение (message) и фокус управления (focus of control). Объект графически изображается, как и на других UML-диаграммах, прямоугольником с подчеркнутым именем, линия жизни объекта — вертикальной пунктирной линией, сообщение — горизонтальной стрелкой, фокус управления — прямоугольником на линии жизни объекта.
Примеры диаграмм последовательности приведены на рис. 3.30. На рис. 3.30, а пользо-ватель создает объект, который через некоторое время уничтожается (символ уничто-жения объекта — жирный крест). Рисунок 3.30, б наглядно демонстрирует идею и па-раметры замера температурно-влажностного режима в помещении хранилища музея.
Фокус управления доказывает, какой именно элемент находится в активном со-бтоянии (действует). Фокус управления может быть одновременно как у одного, так и у нескольких объектов системы. Фокус управления может передаваться от одного объекта другому. На рис. 3.31 приведен пример передачи фокуса управления от объекта А объекту Б или В в зависимости от условия х = 0 или х > 0, записываемого возле символа ветвления. Сообщения на диаграммах последовательности могут быть помечены идентифи-каторами, поясняющими их смысловую нагрузку (стереотипы):
□ «call» — вызов объектом другого объекта;
□ «return» — возврат значения вызвавшему объекту;
□ «create» — создание объекта;
□ «destroy» — уничтожение объекта, которому передается это сообщение;
□ «send» — посылка асинхронного сигнала.
Билет 54.
Диаграмма сотрудничества
Диаграмма сотрудничества, как и диаграмма последовательности, является разно-видностью диаграмм взаимодействия. Современные программные средства по-строения диаграмм обеспечивают автоматическое преобразование диаграмм данных видов друг в друга..
Если диаграмма последовательности ориентирована на отображение временных аспектов взаимодействия, то диаграмма сотрудничества (диаграмма кооперации) показывает структурные особенности взаимодействия между объектами и является развитием идеи построения диаграмм сущность-связь. Диаграммы сотрудничества бывают двух видов.
□ Диаграммы сотрудничества уровня спецификаций оперируют классами, поль-зователями, кооперациями и ролями, которые играют пользователи и классы.. Окружность — это кооперация, пунктирная линия — роль пользователя в коо-перации, стрелка — отношение обобщения, общее для всех UML-диаграмм. Кооперация определяет взаимодействие классов. Участвуя в кооперации, классы совместно производят некоторый кооперативный результат.
□ Диаграммы сотрудничества уровня примеров оперируют экземплярами классов (объектами), связями между ними и сообщениями, которыми обмениваются объекты.
Объекты на диаграммах сотрудничества обозначаются так же, как и на других UML-диаграммах, — прямоугольниками. Однако на диаграммах данного вида имя объекта может дополняться его ролью в сотрудничестве.
Объекты, которые могут управлять другими объектами, называются активными (active object) и помечаются словом {active}.
Для обозначения группы объектов, которым адресован один и тот же сигнал, вводится понятие мультиобъекта, изображаемого графически двумя прямоугольниками, наложенными друг на друга. Между объектами диаграммы сотрудничества существуют связи (links), по которым объекты посылают друг другу сообщения. Связи не имеют названий (в терминах UML они являются анонимными), но могут быть специфицированы ключевыми словами (стереотипами):
□ «association» — связь означает некую зависимость объектов;
□ «parameter» — объект полагается параметром метода;
□ «local» — локальная переменная метода, область видимости которой ограничена соседним объектом;
□ «global» — глобальная переменная, область видимости которой ограничена ди-аграммой сотрудничества;
□ «self» — связь объекта с самим собой.
Приведенные стереотипы требуют пояснения. Связь между объектами в инфор-мационной системе на уровне программирования на определенном языке осуще-ствляется посредством передачи параметров (переменных) от одного объекта другому объекту. Например, объект Отдел продаж передает объекту Склад некоторый принятый в организации документ (переменную), в котором сообщает о необходимости выделения продукции той или иной номенклатуры. Значение передаваемых параметров является содержанием передаваемого посредством связи сообщения.
Сообщения на диаграммах сотрудничества изображаются стрелками вдоль связей. Порядок передачи сообщений может быть определен явным указанием номера сообщения возле стрелки. Вид сообщения несет дополнительную смысловую нагрузку в виде определения ролей взаимодействующих объектов. В зависимости от этого сообщения графически изображаются:
□ сплошной линией с треугольной стрелкой — такое сообщение означает вызов процедуры (метода объекта) или вызов другого потока управления;
□ сплошной линией с обычной стрелкой — такое сообщение означает простой поток управления, то есть просто передачу данных;
□ сплошной линией с полустрелкой — такое сообщение не имеет заранее обуслов-ленного времени передачи, являясь, как правило, асинхронным;
□ пунктирной линией с обычной стрелкой — такое сообщение означает возврат значения из процедуры.
Билет 55.
Диаграмма компонентов
Информационные системы на уровне программного кода могут состоять из множества приложений, справочных файлов, исходных текстов, веб-документов, динамических библиотек. То, как именно будут распределены классы и их экземпляры по файлам, а также взаимосвязи между файлами позволяют отобразить диаграммы компонентов.
ПРИМЕЧАНИЕ —
Диаграммы компонентов играют существенную роль при оптимизаций быстродействия системы. С их помощью выявляются наиболее часто используемые компоненты, определяется их оптимальное распределение по модулям. На завершающих стадиях разработки информационной системы может возникнуть ситуация, когда незначительные изменения в реализации одного из компонентов потребуют перекомпиляции всех компонентов, созданных на его основе. В этом случае пренебрежительное отношение к диаграммам данного вида может существенно сказаться на сроках сдачи проекта. Особенно это касается приложений с числом модулей от тысячи и выше.Основным элементом диаграмм компонентов является компонент (component), который графически изображается прямоугольником со встроенными слева пря-моугольными секциями. Внутри прямоугольника указывается имя компонента, которым может быть имя исполняемого файла, базы данных и т. д., а также служебная Иногда перед именем компонента указывается его спецификация:
□ library — библиотека;
□ table — база данных, отдельная таблица;
□ file — исходный текст программ;
□ document — документ;
□ executable — исполняемый файл.
Для ряда компонентов приняты специальные обозначения. К таким компонентам от-носятся динамические библиотеки (рис. 3.40, а), справочные файлы (рис. 3.40, б), ис-ходные тексты программ (рис. 3.40, в), веб-документы (рис. 3.40, г). Эти обозначения вместе с обозначениями исполняемых модулей иногда называют артефактами. Между компонентами и другими элементами диаграммы компонентов существуют отношения зависимости (рис. 3.41), показывающие, что один компонент зависит от другого и при его изменении тоже должен меняться, а также отношения реализации, изображаемые сплошной линией.
Билет 56.
Диаграмма развертывания
Диаграммы развертывания служат для иллюстрации физического размещения ин-формационной системы на серверах, компьютерах пользователей, искусственных спутниках Земли, поездах, морских судах, внутри ЭВМ, отображения физических каналов передачи информации между компонентами информационной системы.
Основным обозначением, используемым на диаграммах данного вида, является узел (node), который графически изображается аксонометрической проекцией куба (рис. 3.43). Внутри обозначения узла указываются его имя (например, Сервер) и развертываемые на нем компоненты, изображаемые так же, как на диаграмме компонентов.
Билет 57.
Реляционные
базы данных
По мере развития вычислительной техники изменялись основные направления ее использования. Первоначально средства вычислительной техники предназначались для разного рода математических вычислений, которые невозможно было выполнить «вручную» за разумное время. Развитие этого направления привело к появлению разделов математики, связанных с численными методами вычислений, и алгоритмических языков, удобных для реализации алгоритмов численных методов и ориентированных на выполнение математических расчетов (одним из наиболее популярных языков программирования такого типа является Fortran, до сих пор широко применяющийся для научных расчетов).
Затем, по мере расширения возможностей и снижения стоимости вычислительных средств, получило развитие второе направление, связанное с использованием средств вычислительной техники в автоматизированных информационных системах. Здесь вычислительные возможности компьютеров отходят на второй план — основные функции вычислительных средств в информационных системах направлены на надежное хранение информации, выполнение специфических для данного приложения преобразований информации и/или вычислений, предоставление пользователям удобного и легко осваиваемого интерфейса.
ПРИМЕЧАНИЕ
Несмотря на то что сложность вычислений, выполняемых в информационных систе-мах, несоизмеримо ниже, чем при проведении научных расчетов, требования к вы-числительной мощности компьютеров в таких системах выше. Это связано с тем, что объемы обрабатываемой информации, как правило, достаточно велики, а сама ин-формация имеет сложную структуру. Этим же объясняется существенное возрастание требований к объему оперативной памяти и устройств постоянного хранения ин-формации.
Со временем именно второе направление, связанное с хранением и обработкой данных, стало доминирующим, особенно после появления персональных компьютеров. Использование персональных компьютеров для выполнения сложных научных расчетов сейчас является скорее исключением. Интересно также отметить,
что современные персональные компьютеры, оборудованные процессорами с гро-мадными тактовыми частотами (на сегодняшний день рядовой дешевый процессор работает на частоте 1400-1500 МГц) при решении сложных научных задач могут даже уступать по вычислительным возможностям «большим» компьютерам 15-20-летней давности.
Общие сведения о базах данных
Развитие компьютерных технологий, связанных с хранением и обработкой данных, привело к появлению в конце 60-х — начале 70-х годов специализированного программного-обеспечения, получившего название систем управления базами данных, или СУБД (DataBase Management Systems, DBMS). СУБД позволяют структурировать, систематизировать и организовывать данные для их компьютерного хранения и обработки. Именно системы управления базами данных являются основой практически любой информационной системы.
СУБД можно определить как некую систему управления данными, обладающую следующими свойствами:
□ поддержанием логически согласованного набора файлов;
□ предоставлением языка манипулирования данными;
□ восстановлением информации после разного рода сбоев;
□ обеспечением параллельной работы нескольких пользователей.
Билет 58.
Основные функции систем управления базами данных
К основным функциям, выполняемым системами управления базами данных, обычно относят:
□ непосредственное управление данными во внешней памяти;
□ управление буферами оперативной памяти;
□ управление транзакциями;
□ протоколирование;
□ поддержку языков баз данных.
Рассмотрим каждую из указанных функций более подробно.
Непосредственное управление данными во внешней памяти
Функция непосредственного управления данными во внешней памяти включает предоставление необходимых структур внешней памяти (постоянных запоминающих устройств, как правило, магнитных дисков) как для хранения данных, непосредственно входящих в базу данных, так и для служебных целей, например для ускорения доступа к данным в некоторых случаях (обычно для этого используются индексы). Причем пользователям базы данных в общем случае не нужно знать, применяет ли СУБД файловую систему, а если применяет, как организованы файлы. Обычно СУБД поддерживает собственную систему именования объектов базы данных. В зависимости от способа реализации СУБД может либо использовать возможности существующих файловых систем, либо работать с устройствами внешней памяти на низком уровне.
Управление буферами оперативной памяти
Объем информации, хранящейся в базе данных, с которой работает СУБД, обычно достаточно велик и практически всегда превышает доступный объем оперативной памяти. При этом время доступа к данным, хранящимся в оперативной памяти, существенно меньше, чем к данным, хранящимся на устройствах внешней памяти. Очевидно, что если при обращении к любому элементу данных требуется обмен с внешней памятью, то вся система будет работать со скоростью функционирования устройства внешней памяти.
Повышения скорости обмена данными можно достичь, используя буферизацию данных в оперативной памяти. При этом даже если операционная система выполняет общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, у которой гораздо больше информации, позволяющей судить о полезности буферизации той или иной части базы данных. Поэтому в СУБД обычно поддерживается собственный набор буферов оперативной памяти с собственным механизмом замены буферов.
ПРИМЕЧАНИЕ
Следует отметить, что существует направление развития СУБД, ориентированное на постоянное присутствие в оперативной памяти всей информации из базы данных. Это направление основывается на предположении, что в будущем объем оперативной памяти компьютеров будет настолько велик, что буферизация станет лишней.
Дата добавления: 2015-08-29; просмотров: 20 | Нарушение авторских прав
| <== предыдущая лекция | | | следующая лекция ==> |