Реферат по предмету "Информатика"


Информационные ресурсы Интернет относящиеся к области бизнеса и коммерции

--PAGE_BREAK--Пакеты прикладных программ, предназначенные для ввода, обработки, поиска и обновления текстов, называют информационно-поисковой системой (ИПС).
5. Сетевые базы данных.
Одним из наиболее эффективных методов представления знаний  являются сетевые модели.
В основе моделей лежит понятие сети, вершинами которой являются понятия, соответствующие объектам, событиям, процессам, явлениям, а дугами – отношения между этими понятиями.
Узлы и связи можно наглядно изображать в виде диаграмм.
Если вершины сети не имеют своей внутренней структуры, то сеть будет простой. Если же вершины обладают некоторой структурой в виде сети, то сеть называется иерархической. Если отношения между вершинами одинаковые, то сеть однородна, в противном случае – сеть неоднородна. Характер отношений, приписываемый дугам, может быть различен. В соответствии с этим выделяют следующие типы сетей:
·              Функциональные сети отражают декомпозицию определенной вычислительной или информационной процедуры, а дуги показывают функциональную связь между декомпонированными частями; этот язык недостаточно богат для представления знаний;
·              Сценарии, представляющие собой однородные сети с единственным отношением в виде нестрогого порядка. Семантика отношений может быть различной. Отношение может трактоваться как классифицирующее, временное и т.п. Сценарии часто используются при формировании допустимых планов по достижению цели;
·              Семантические сети используют отношения разных типов, а вершины  в них могут иметь разную интерпретацию, По сути дела семантическая сеть является классом, в который включаются как сценарии, так и функциональные сети. Наиболее часто используются в сети связи типа «это есть». Они позволяют построить в виде сети иерархию понятий, в которых узлы низших уровней наследуют свойства узлов более высоких уровней. Именно таким механизмом переноса свойств обусловлена эффективность семантических сетей.
6. Реляционные базы данных.
Базы данных называютсяреляционными, если управление ими основано на математической модели, использующей методы реляционной алгебры и реляционного исчисления. С. Дейт дает следующее неформальное определение реляционных баз данных:
·              Вся информация в базе данных представлена в виде таблиц.
·              Поддерживаются три реляционных оператора – выбора, проектирования и объединения, с помощью которых можно получить любые необходимые данные, заложенные в таблицы.
Доктор И.Ф. Кодд, автор реляционной модели, разработал целый список критериев, которым должна удовлетворять реляционная модель. Описание этого списка, часто называемого «12 правилами Кодда», требует введения сложной терминологии и выходит за рамки дипломной работы. Тем не менее можно назвать некоторые правила Кодда для реляционных систем. Чтобы считаться реляционной по Кодду, система управления базами данных должна:
·              Представлять всю информацию в виде таблиц;
·              Поддерживать логическую структуру данных, независимо от их физического представления;
·              Использовать язык высокого уровня для структурирования, выполнения запросов и изменения информации в базах данных;
·              Поддерживать основные реляционные операции (выбор, проектирование и объединение), а также теоретико-множественные операции, такие как объединение, пересечение и дополнение;
·              Поддерживать виртуальные таблицы, обеспечивая пользователям альтернативный способ просмотра данных в таблицах;
·              Различать в таблицах неизвестные значения (nulls), нулевые значения и пропуски в данных;
·              Обеспечивать механизмы для поддержки целостности, авторизации, транзакций и восстановления данных.
Первое правило Кодда гласит, что вся информация в реляционных базах данных представляется значениями в таблицах. В реляционных системах таблицы состоят из горизонтальных строк и вертикальных столбцов. Все данные представляются в табличном формате – другого способа просмотреть информацию в базе данных не существует. Набор связанных таблиц образует базу данных. Таблицы в реляционной базе разделены, но полностью равноправны. Между ними не существует никакой иерархии.
Каждая таблица состоит из строк и столбцов. Каждая строка описывает отдельный объект или сущность – ученика, предмет, день недели или что-нибудь другое. Каждый столбец описывает одну характеристику объекта –имя или фамилию ученика, его адрес, оценку, дату. Каждый элемент данных, или значение, определяется пересечением строки и столбца. Чтобы найти требуемый элемент данных, необходимо знать имя содержащей его таблицы, столбец и значение его первичного ключа, или уникального идентификатора. 
В реляционной базе данных существует  два типа таблиц – пользовательские таблицы и системные таблицы.   Пользовательские таблицы содержат информацию,  для поддержки которой собственно и создавались реляционные базы данных. Системные таблицы обычно поддерживаются самой СУБД, однако доступ к ним можно получить так же, как и к любым другим таблицам. Возможность получения доступа к системным таблицам, по аналогии с любыми другими таблицами, составляет основу другого правила Кодда для реляционных систем. 
Реляционная модель обеспечивает независимость данных на двух уровнях – физическом и логическом. Физическая независимость данных означает с точки зрения пользователя, что представление данных абсолютно не зависит от способа их физического хранения. Как следствие этого, физическое перемещение данных никоим образом не может повлиять на логическую структуру базы данных. Другой тип независимости, обеспечиваемый реляционными системами -  логическая независимость – означает, что изменение взаимосвязей между таблицами и строками не влияет на правильное функционирование программных приложений и текущих запросов.
В определении системы управления реляционными базами данных упоминаются три операции по выборке данных – проектирование, выбор и объединение, которые позволяют строго указать системе, какие данные необходимо показать. Операция проектирования выбирает столбцы, операция выбора – строки, а операция объединения собирает вместе данные из связанных таблиц.
Виртуальные таблицы можно рассматривать как некоторую перемещаемую по таблицам рамку, через которую можно увидеть только необходимую часть информации. Виртуальные таблицы можно получить из одной или нескольких таблиц базы данных ( включая и другие виртуальные таблицы), используя любые операции выбора, проектирования и объединения. Виртуальные таблицы, в отличие от «настоящих», или базовых таблиц, физически не хранятся в базе данных. В то же время необходимо осознавать, что виртуальные таблицы это не копия некоторых данных, помещаемая в другую таблицу. Когда вы изменяете данные в виртуальной таблице, то тем самым изменяете данные в базовых таблицах. В идеальной реляционной системе свиртуальными таблицами можно оперировать как и с любыми другими таблицами. В реальном мире на виртуальные таблицы накладываются определенные ограничения, в частности на обновление. Одно из правил Кодда гласит, что в истинно реляционной системе над виртуальными таблицами можно выполнять все «теоретически» возможные операции. Большинство  современных систем управления реляционными базами данных не удовлетворяют этому правилу полностью.
В реальном мире управления информацией данные часто являются неизвестными или неполными: неизвестен телефонный номер, не захотели указать возраст. Такие пропуски информации создают «дыры» в таблицах. Проблема, конечно, состоит не в простой неприглядности подобных дыр. Опасность состоит в том, что из-за них база данных может стать противоречивой. Чтобы сохранить целостность данных в реляционной модели, так же, как и в правилах Кодда, для обработки пропущенной информации используется понятие нуля.
«Нуль» не означает пустое поле или обычный математический нуль. Он отображает тот факт, что значение неизвестно, недоступно или неприменимо. Существенно, что использование нулей инициирует переход с двухзначной логики (да/нет) на трехзначную (да/нет/может быть). С точки зрения другого эксперта по реляционным системам, Дейта, нули не являются полноценным решением проблемы пропусков информации. Тем не менее они являются составной частью большинства официальных стандартов различных реляционных СУБД.
Целостность – очень сложный и серьезный вопрос при управлении реляционными базами данных. Несогласованность между данными может возникать по целому ряду причин. Несогласованность или противоречивость данных может возникать вследствие сбоя системы – проблемы с аппаратным обеспечением, ошибки в программном обеспечении или логической ошибки в приложениях. Реляционные системы управления базами данных защищают данные от такого типа несогласованности, гарантируя, что команда либо будет исполнена до конца, либо будет полностью отменена. Этот процесс обычно называют управлением транзакциями.
Другой тип целостности, называемый объектной целостностью, связан с корректным проектированием базы данных. Объектная целостность требует, чтобы ни один первичный ключ не имел нулевого значения.
Третий тип целостности, называемой ссылочной целостностью,  означает непротиворечивость между частями информации, повторяющимися в разных таблицах. Например, если вы изменяете неправильно введенный номер карточки страхового полиса в одной таблице, другие таблицы, содержащие эту же информацию, продолжают ссылаться на старый номер, поэтому необходимо обновить и эти таблицы. Чрезвычайно важно, чтобы при изменении информации в одном месте, она соответственно изменялась и во всех других местах. Кроме того, по определению Кодда, ограничения на целостность должны:
·              Определяться на языке высокого уровня, используемом системой для всех других целей;
·              Храниться в словаре данных, а не в программных приложениях.
Эти возможности в том или ином виде реализованы в большинстве систем.
7. Проектирование  баз  данных
Процесс, в ходе которого решается, какой вид будет у вновь создаваемой БД, называется проектированием базы данных. На этапе проектирования необходимо предусмотреть все возможные действия, которые могут возникнуть на различных этапах жизненного цикла БД (рис.2).
Процедуры, выполняемые на этапах жизненного цикла БД
  Проектирование
Создание
Эксплуатация
Анализ предметной области и запросов к БД
Генерация схемы БД
Реорганизация БД
Организация доступа к  базам данных
Контроль состояния БД
Интеграция пользовательских представлений
Подготовка среды хранения
Реструктуризация БД
Поиск и обновление данных
Сбор и анализ статистики использования БД
Выбор средства реализации
Ввод и контроль данных
Реформатизация БД
Вывод отчетов
Контроль целостности БД
Логическое проектирование
Загрузка и корректировка БД
Разграничение доступа
Копирование и восстановление БД

Физическое проектирование
Инициирование и завершение работы с СУБД
Рис. 2
8. Анализ предметной области и запросов к  БД.
На данном этапе необходимо проанализировать запросы пользователей, выбрать информационные объекты и их характеристики и на основе анализа структурировать предметную область (рис. 3).
Анализ предметной области целесообразно разбить на три фазы:
·              Анализ концептуальных требований и информационных потребностей;
·              Выявление информационных объектов и связей между ними;
·              Построение концептуальной модели предметной области и проектирование концептуальной схемы БД

                Описание            Уровень физической                 Библиотека        Библиотека
                базы                                 реализации                   входных и           запросов
                данных                                                                  вых. форм
Рис. 3
9. Анализ концептуальных требований
На этапе анализа концептуальных требований и информационных потребностей необходимо решить следующие задачи:
·              Анализ требований пользователей к БД (концептуальных требований);
·              Выявление имеющихся задач по обработке информации, которая должна быть представлена в БД (анализ приложений);
·              Выявление перспективных задач (перспективных приложений);
·              Документирование результатов анализа.
Требования пользователей к разрабатываемой  БД представляют собой список запросов с указанием их интенсивности и объемов данных. Эти сведения разработчики получают в диалоге с будущими пользователями БД. Здесь же выясняются требования к вводу, обновлению и корректировке информации. Требования пользователей уточняются и дополняются при анализе имеющихся и перспективных приложений.
Например, в случае разработки БД для ведения электронной документации отдела кадров учебного заведения необходимо получить ответы на вопросы:
1.           Сколько студентов учится в ВУЗе?
2.           Сколько штатных преподавателей и сколько совместителей?
3.           Сколько сформировано учебных групп?
    продолжение
--PAGE_BREAK--


Не сдавайте скачаную работу преподавателю!
Данный реферат Вы можете использовать для подготовки курсовых проектов.

Поделись с друзьями, за репост + 100 мильонов к студенческой карме :

Пишем реферат самостоятельно:
! Как писать рефераты
Практические рекомендации по написанию студенческих рефератов.
! План реферата Краткий список разделов, отражающий структура и порядок работы над будующим рефератом.
! Введение реферата Вводная часть работы, в которой отражается цель и обозначается список задач.
! Заключение реферата В заключении подводятся итоги, описывается была ли достигнута поставленная цель, каковы результаты.
! Оформление рефератов Методические рекомендации по грамотному оформлению работы по ГОСТ.

Читайте также:
Виды рефератов Какими бывают рефераты по своему назначению и структуре.