|
"“Разработка и исследование мультимедийных баз данных для использования в среде интернет”" Руководитель: Аноприенко А.Я. |
Содержание работы1. Введение 2. Содержание 3. Цель работы 4. Обзор и анализ существующих технологи базы данных 4.1. Концепция базы данных 4.2. Эволюция "развития" технологии базы данных 4.3. Риолиционные "relation" базы данных 4.4. Ситивые и Обектно орентировонные и прочии технологи базы данных 4.5. Базы данных на основе технологи интернет 5. Анализ проблемы и постановка задач исследования 5.1. Основни варианты организации интернет SQL против HTML 5.2. Основни возможности гипртекстови технологи в организации базы данных 5.3. Анализ примушеств и не достатков мульти мидейнние баз данных "на примере" базы студентов и магестров Дон ГТУ 5.4. Основные задачи исследования 6. Основные параметры эфектывности "MMБД" и их исследования 6.1. Факторы опридиляющие эфективности MMБД 6.2. Информационая полнота (насищенность) "информативность" 6.3. Удобство использование (uses) 6.4. Быстро действие 6.5. Сравнительный анализ различных технологий по основным критериям 7. Организация множиственного доступа к MMБД 7.1. Каталоговые подходы 7.2. Поисковы подходы 7.3. Интигрированные подходы 8. Основные результаты эксперименталного исследования 8.1. 8.2. 8.3. 9. Заключение ВведениеВыдений. Только небольшие организации могут обобществить данные в одной полностью интегрированной базе данных. Чаще всего администратор баз данных (даже если это группа лиц) практически не в состоянии охватить и осмыслить все информационные требования сотрудников организации (т.е. будущих пользователей системы). Поэтому информационные системы больших организаций содержат несколько десятков БД, нередко распределенных между несколькими взаимосвязанными ЭВМ различных подразделений. (Так в больших городах создается не одна, а несколько овощных баз, расположенных в разных районах.) Отдельные БД могут объединять все данные, необходимые для решения одной или нескольких прикладных задач, или данные, относящиеся к какой-либо предметной области (например, финансам, студентам, преподавателям, кулинарии и т.п.). Первые обычно называют прикладными БД, а вторые - предметными БД (соотносящимся с предметами организации, а не с ее информационными приложениями). (Первые можно сравнить с базами материально-технического снабжения или отдыха, а вторые - с овощными и обувными базами.) Предметные БД позволяют обеспечить поддержку любых текущих и будущих приложений, поскольку набор их элементов данных включает в себя наборы элементов данных прикладных БД. Вследствие этого предметные БД создают основу для обработки неформализованных, изменяющихся и неизвестных запросов и приложений (приложений, для которых невозможно заранее определить требования к данным). Такая гибкость и приспосабливаемость позволяет создавать на основе предметных БД достаточно стабильные информационные системы, т.е. системы, в которых большинство изменений можно осуществить без вынужденного переписывания старых приложений. Основывая же проектирование БД на текущих и предвидимых приложениях, можно существенно ускорить создание высокоэффективной информационной системы, т.е. системы, структура которой учитывает наиболее часто встречающиеся пути доступа к данным. Поэтому прикладное проектирование до сих пор привлекает некоторых разработчиков. Однако по мере роста числа приложений таких информационных систем быстро увеличивается число прикладных БД, резко возрастает уровень дублирования данных и повышается стоимость их ведения. Таким образом, каждый из рассмотренных подходов к проектированию воздействует на результаты проектирования в разных направлениях. Желание достичь и гибкости, и эффективности привело к формированию методологии проектирования, использующей как предметный, так и прикладной подходы. В общем случае предметный подход используется для построения первоначальной информационной структуры, а прикладной - для ее совершенствования с целью повышения эффективности обработки данных. При проектировании информационной системы необходимо провести анализ целей этой системы и выявить требования к ней отдельных пользователей (сотрудников организации). Сбор данных начинается с изучения сущностей организации и процессов, использующих эти сущности (подробнее в приложении Б). Сущности группируются по "сходству" (частоте их использования для выполнения тех или иных действий) и по количеству ассоциативных связей между ними (самолет - пассажир, преподаватель - дисциплина, студент - сессия и т.д.). Сущности или группы сущностей, обладающие наибольшим сходством и (или) с наибольшей частотой ассоциативных связей объединяются в предметные БД. (Нередко сущности объединяются в предметные БД без использования формальных методик - по "здравому смыслу".) Для проектирования и ведения каждой предметной БД (нескольких БД) назначается АБД, который далее занимается детальным проектированием базы. Далее будут рассматриваться вопросы, связанные с проектированием отдельных реляционных предметных БД. Основная цель проектирования БД - это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте. Так называемый, "чистый" проект БД ("Каждый факт в одном месте") можно создать, используя методологию нормализации отношений. И хотя нормализация должна использоваться на завершающей проверочной стадии проектирования БД, мы начнем обсуждение вопросов проектирования с рассмотрения причин, которые заставили Кодда создать основы теории нормализации. Цель работы Целью данной магистерской работы является Изучить проанализировать использования совримены web-технологии, для организации оперативного доступа болшим массивом разнородим мультимединным информации.
Научная новизна работы состоит в том, что данная работа ориентирована на параллельную архитекту Архитектура Система Управления Баз Данных СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о: · физическом размещении в памяти данных и их описаний; · механизмах поиска запрашиваемых данных; · проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами); · способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа; · поддержании баз данных в актуальном состоянии и множестве других функций СУБД. При выполнении основных из этих функций СУБД должна использовать различные описания данных. А как создавать эти описания? Естественно, что проект базы данных надо начинать с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Подробнее этот процесс будет рассмотрен ниже, а здесь отметим, что проектирование обычно поручается человеку (группе лиц) - администратору базы данных (АБД). Им может быть как специально выделенный сотрудник организации, так и будущий пользователь базы данных, достаточно хорошо знакомый с машинной обработкой данных. Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. АБД может при необ ходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений. Литература The last modification date is May 3, 2002 |