Реферат Отчет 142 стр., 13 рис., 7 таблиц, список литературы 2 наименования
Скачать 1.46 Mb.
|
§2.4. Архитектура баз данных.Вероятно, самое важное отличие реляционных баз от процессора базы данных компании Birdstep заключается в лежащей в их основе архитектуре баз данных. Архитектура баз данных (или модель баз данных) на самом фундаментальном уровне определяет, как будет осуществляться доступ к данным и их хранение. Дальнейшая производительность и эффективность в значительной степени определяется в момент выбора лежащей в основе модели. Эта модель основана на прямом доступе к записям базы данных в противоположность индексному доступу, используемому в модели реляционных баз данных. Очень важным моментом в проектировании высокой производительности приложений со встроенными базами данных является использование сильных сторон обеих моделей. Ниже приведены для сравнения различия между моделями реляционных баз данных и сетевых баз данных, основанных на указателях. Кроме того, ниже предлагается эталонный тест, демонстрирующий преимущества в скорости и эффективности сетевой модели. Предлагаемый тест сравнивает сетевое решение Birdstep Database Manager и реляционные модели в применении к одним и тем же задачам и демонстрирует 15-кратное превосходство сетевой модели в скорости перед реляционной версией. Определение реляционных и сетевых моделей.В реляционной модели данные хранятся в таблицах, состоящих из столбцов и строк. При возникновении необходимости в данных более чем из одной таблицы одна из операций объединения связывает эти данные, используя копию столбца от каждой таблицы. Несмотря на гибкость реляционной модели, ее производительность ограничена необходимостью создавать новые таблицы для хранения результатов реляционных операций, тогда как хранение избыточных столбцов в связанных таблицах приводит к росту размера базы данных. Кроме того, обработка операций объединения расходует ценные системные ресурсы – получение объединенных данных из двух таблиц приведет к замедлению работы приложения, а запрос на получение данных более чем из двух таблиц может полностью "подвесить" систему. Рассмотрим, что происходит при переходе от одной таблицы к другой, используя реляционную связь: найдя ключевое значение в первой таблице, процессор баз данных ищет это значение в индексном файле, который в свою очередь содержит некоторый вид ссылок на вторую таблицу. Проблема заключается в том, что поиск в индексном файле может потребовать две или три итерации (т.е. два или три обращения к диску) на каждую запись, к которой осуществляется доступ. Именно здесь сетевая модель и "множества" RDM могут привести к значительной экономии времени. Фактически такое множество представляет собой связанный список, представляющий тип отношений "один-ко-многим". Указатели к следующему и предыдущему членам связывают каждый элемент данного множества. "Хозяин" множества (т.е. "один" в отношении "один-ко-многим") указывает на каждый конец связанного списка. Таким образом, переход от хозяина к первому члену требует только одну операцию доступа к диску. Подобным образом осуществляется переход к следующему члену и так далее. Каждый элемент множества обладает указателем на своего хозяина, т.е. для перехода от него к хозяину также требуется только одна операция доступа к диску. Множество указателей относительно невелико – одно такое множество использует то же или меньшее дисковое пространство, что и дублированные данные вместе с индексным файлом, ассоциированным с реляционной связью. Конечно, множества обладают им присущим порядком и поэтому полезны только тогда, когда доступ к их элементам осуществляется в таком порядке. Система RDM поддерживает как сетевые, так и реляционные модели, позволяя разработчикам использовать любой из двух типов по отдельности. Однако для настоящей производительности разработчики комбинируют сетевые и реляционные модели при проектировании системы, использующей RDM. Например, записи, требующие быстрый беспорядочный или сортированный доступ, связаны через индекс, тогда как информация, которая естественным образом может быть отнесена к таким типам отношений, как "один-ко-многим", "многие-к-одному" и рекурсивному, разбивается на множества. Чтобы увидеть преимущества в производительности, достигаемые за счет прямого доступа к записям при использовании модели сетевых баз данных, рассмотрим пример, использующий в типичной системе как реляционные, так и сетевые модели. Ниже рассматриваются вопросы, связанные с работой менеджера ресурсов (Resource Manager) базы данных RDM Server.. Содержится объяснение специальных функций Resource Manager, категорий API (таких как, функции управления потоками и функции организации очередей) и предоставлен подробный пример, иллюстрирующий использование конкретных функций Resource Manager. Разработка многопотоковых приложений предполагает использование функций операционных систем для управления потоками и обеспечения межпотоковой синхронизации и коммуникации. Многие современные операционные системы поддерживают такие функции, но поскольку доступ к ним зависит от конкретной платформы, нередко приходится сталкиваться со значительными трудностями при создании сложных, платформенно-независимых многопотоковых прикладных программ. Если разрабатываемое вами приложение не является платформенно-независимым, вы можете свободно применять соответствующие функции вашей операционной системы. Однако, если вы создаете приложение, масштабируемое для большого числа различных платформ, вам следует воспользоваться интерфейсом Resource Manager (RM) базы данных RDM Server. Многопотоковое ядро RDM Server использует все функции интерфейса RM. Это гарантирует их надежность и доступность для всех платформ, поддерживаемых RDM Server. Resource Manager предоставляет платформенно-независимый интерфейс с большим количеством функций, позволяющих решать такие сложные задачи для операционных систем, как: управление потоками; управление параллельным выполнением; организация очередей сообщений; динамическое распределение памяти; управление файлами. Все функции RM предназначены для работы в однопроцессной среде многопотоковых приложений. Полный список функций интерфейса RM приводится в следующей таблице. Таблица 2.2. – Список функций Resource Manager
|
Похожие:
 | Реферат Отчет стр., рис., таблиц, список литературы 4 наименования Директор научно-исследовательского института ядерной физики имени Д. В. Скобельцына мгу имени М. В. Ломоносова | | А. В. Брюханов летопись природы Отчет «Летопись природы национального парка «Зюраткуль» за 2002 год» содержит 187 стр., включая 6 таблиц и 5 приложений. Список использованной... |
| Реферат Отчет 120с., 13 рис., 19 таблиц в тексте, 39 источников Фундаментальные исследования, организация управления фундаментальными исследованиями, масштабы, тенденции развития фундаментальных... | | Реферат Отчет 25 стр., 1 рис Ключевые слова: космология, внегалактическая астрономия, звезды, межзвездная среда, активные ядра |
| Реферат Отчёт изложен на 36 страницах, включает 12 таблиц, 3 рисунка,... «Мониторинг и прогнозирование состояния продовольственной безопасности на территории Калужской области. Практические рекомендации... | | Реферат Требование к структуре реферату Реферат должен быть выполнен самостоятельно каждым студентом на 5 или более листах формата А4 (не включая титульный лист, содержание,... |
| Реферат Отчет: 180 стр., 11 рис., 12 табл., 72 источника ... | | Тематическое планирование стр. 7 2 Требования к уровню подготовки... В числе приоритетных целей изучения музыкального искусства в начальной школе выступают |
| Реферат Баранов К. Г., Игнатенков А. И. Дипломный проект на тему... Общий объем проекта составляет 78 страниц. Дипломный проект содержит 1 рисунок, 16 таблиц. Список литературы представлен 30 источниками... | | Реферат (18 стр., рис., 3 табл.) Объектом исследования являлись системы централизованного и локального водоотведения мо ракитинское |
| Реферат Отчет с. 22, рис., 3 табл Объектом исследования являлись системы централизованного водоснабжения мо г п. Одоев | | Реферат. Отчет…23с., рис., 4 табл Объектом исследования являлись системы централизованного и локального водоотведения мо кожинское |
| Федеральное государственное образовательное учреждение высшего профессионального образования Отчет о нир 65 с., 2 рис., 1 табл., приложений 2, источников использованной литературы 58 | | Федеральное государственное образовательное учреждение высшего профессионального образования Отчет о нир 65 с., 2 рис., 1 табл., приложений 2, источников использованной литературы 58 |
| Федеральное государственное образовательное учреждение высшего профессионального образования Отчет о нир 65 с., 2 рис., 1 табл., приложений 2, источников использованной литературы 58 |  | Реферат Отчет 35 с., 3 главы, 16 рис., 1 табл., 12 источников, 5 прил Объектом разработки является программа восстановления каркасных 3D объектов по 2D проекциям |
