Шпаргалка по "Информатика"

Рисунок 2 – Графическое изображение  сетевой структуры

Реляционная модель данных.

Понятие реляционный (англ. relation – отношение) связано с разработками известного американского специалиста в области систем баз данных Е. Кодда.

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

Реляционная модель ориентирована  на организацию данных в виде двумерных  таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

- каждый элемент таблицы – одни элемент данных;

- все столбцы в таблице однородные, т.е. все элементы в столбце  имеют одинаковый тип (числовой, символьный и тд.) и длину;

- каждый столбец имеет уникальное  имя;

- одинаковые строки в таблице  отсутствуют;

- порядок следования строк и столбцов может быть произвольным.

Объектная модель данных.

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

  

6. Нормализация данных.

Ответ

 

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

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

Процесс нормализации основан на понятии  функциональной зависимости атрибутов: атрибут А зависит от атрибута В (В -> А), если в любой момент времени каждому значению атрибута В соответствует не более одного значения атрибута А.

Зависимость» при которой каждый неключевой атрибут зависит от всего составного ключа и не зависит от его частей, называется полной функциональной зависимостью. Если атрибут А зависит от атрибута 5, а атрибут В зависит от атрибута С (С -> В -> А), но обратная зависимость при этом отсутствует, то зависимость Сот А называется транзитивной.

Общее понятие нормализации подразделяется на несколько нормальных форм.

Информационный объект (сущность) находится в первой нормальной форме (1НФ), когда все его атрибуты имеют единственное значение. Если в каком-либо атрибуте есть повторяющиеся значения, объект (сущность) не находится в 1НФ, и упущен, по крайней мере, еще один информационный объект (еще одна сущность).

  

7. Разработка структуры БД.

Ответ

 

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

Для каждого поля конкретной таблицы  необходимо определить его тип и  размер и тщательно проверить, удовлетворяет ли диапазон значений выбранного типа тем значениям, которые может реально принимать данное поле. При необходимости, для некоторых полей можно установить Условие на значение и задать сообщение, выдаваемое на экран в случае несоответствия введенного значения заданному условию или присвоить значения, принимаемые по умолчанию. Можно также определить формат вводимой информации для конкретных полей.  
Заполнить соответствующей информацией каждый из разделов создаваемой структуры таблицы: Имя поля, Тип данных и Описание.

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

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

 

8. Физическая и логическая организация баз данных.

Ответ

 

Перед созданием базы данных выполняется  проектирование ее структуры на логическом и физическом уровнях. Такое проектирование выполняется с помощью средств автоматизированного проектирования информационных систем (CASE-средства). В настоящее время имеется множество средств автоматизации разработки, предназначенных как для разработки баз данных, так и для разработки клиентских приложений. Одной из наиболее распространенных программ для проектирования баз данных является ERwin [6]. С помощью ERwin можно выполнить проектирование на логическом и физическом уровне, а также создать базу данных на сервере.

На логическом уровне проектирование выполняется путем выделения сущностей (Entity), атрибутов сущностей (Attribute) и взаимосвязей между сущностями. Модель «сущность-связь» (Entity - Relationship Model, или ER-модель) была разработана Ченом (Chen) в 1976 году с целью упрощения задачи проектирования баз данных [2]. Логическая модель независима от особенностей физической реализации объекта.

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

9. Формы организации запросов.

Ответ

 

Запросы создаются пользователем  для выборки необходимых ему  данных из одной или нескольких связанных  таблиц и представления выбранных  данных также в виде таблицы. Запрос может формироваться двумя способами:

с помощью запросов по образцу — QBE (Query By Example);

с помощью инструкций языка структурированных  запросов SQL (Structured Query Language), т.е. специализированного  языка, предназначенного для организации запросов, а также для обновления и управления реляционными базами данных.

Имеется несколько видов запросов:

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

• запрос на создание таблицы, основанный на запросе на выборку, но в отличие от последнего результат этого запроса сохраняется в новой таблице;

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

При использовании в запросе  других запросов или таблиц, не представленных в логической схеме базы данных, с ними также могут быть установлены связи-объединения, т. е. связи без ключевого слова.

  

10. Распределенные базы данных.

Ответ

 

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

Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система.

Фундаментальный принцип имеет  следствием определённые дополнительные правила или цели. Таких целей  всего двенадцать:

1. Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.

2. Отсутствие опоры на центральный узел. Локальная независимость предполагает, что все узлы в распределённой системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса.

3. Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.

4. Независимость от расположения. Пользователи не должны знать, где именно данные хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле.

5. Независимость от фрагментации. Система поддерживает независимость от фрагментации, если данная переменная-отношение может быть разделена на части или фрагменты при организации её физического хранения. В этом случае данные могут храниться в том месте, где они чаще всего используются, что позволяет достичь локализации большинства операций и уменьшения сетевого трафика.

6. Независимость от репликации. Система поддерживает репликацию данных, если данная хранимая переменная-отношение — или в общем случае данный фрагмент данной хранимой переменной-отношения — может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах.

7. Обработка распределённых запросов. Суть в том, что для запроса может потребоваться обращение к нескольким узлам. В такой системе может быть много возможных способов пересылки данных, позволяющих выполнить рассматриваемый запрос.

8. Управление распределёнными транзакциями. Существует 2 главных аспекта управления транзакциями: управление восстановлением и управление параллельностью обработки. Что касается управления восстановлением, то чтобы обеспечить атомарность транзакции в распределённой среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов (агент — процесс, который выполняется для данной транзакции на отдельном узле) или зафиксировало свои результаты, или выполнило откат. Что касается управления параллельностью, то оно в большинстве распределённых систем базируется на механизме блокирования, точно так, как и в нераспределённых системах.

9. Аппаратная независимость. Желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределённой системы как равноправные партнёры.

10. Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами.

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

12. Независимость от типа СУБД. Необходимо, чтобы экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной и той же версии СУБД.

  

11. Объектно-ориентированные БД.

 

Ответ

 

Объектно-ориентированная база данных (ООБД) — база данных, в которой  данные моделируются в виде объектов, их атрибутов, методов и классов.

Объектно-ориентированные базы данных обычно рекомендованы для тех  случаев, когда требуется высокопроизводительная обработка данных, имеющих сложную структуру.

Обязательные характеристики

1. Поддержка сложных объектов. В системе должна быть предусмотрена возможность создания составных объектов за счет применения конструкторов составных объектов. Необходимо, чтобы конструкторы объектов были ортогональны, то есть любой конструктор можно было применять к любому объекту.
2. Поддержка индивидуальности объектов. Все объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов.
3. Поддержка инкапсуляции. Корректная инкапсуляция достигается за счет того, что программисты обладают правом доступа только к спецификации интерфейса методов, а данные и реализация методов скрыты внутри объектов.
4. Поддержка типов и классов. Требуется, чтобы в ООБД поддерживалась хотя бы одна концепция различия между типами и классами. (Термин «тип» более соответствует понятию абстрактного типа данных. В языках программирования переменная объявляется с указанием ее типа. Компилятор может использовать эту информацию для проверки выполняемых с переменной операций на совместимость с ее типом, что позволяет гарантировать корректность программного обеспечения. С другой стороны класс является неким шаблоном для создания объектов и предоставляет методы, которые могут применяться к этим объектам. Таким образом, понятие «класс» в большей степени относится ко времени исполнения, чем ко времени компиляции.)
5. Поддержка наследования типов и классов от их предков. Подтип, или подкласс, должен наследовать атрибуты и методы от его супертипа, или суперкласса, соответственно.
6. Перегрузка в сочетании с полным связыванием. Методы должны применяться к объектам разных типов. Реализация метода должна зависеть от типа объектов, к которым данный метод применяется. Для обеспечения этой функциональности связывание имен методов в системе не должно выполняться до времени выполнения программы.
7. Вычислительная полнота. Язык манипулирования данными должен быть языком программирования общего назначения.
8. Набор типов данных должен быть расширяемым. Пользователь должен иметь средства создания новых типов данных на основе набора предопределенных системных типов. Более того, между способами использования системных и пользовательских типов данных не должно быть никаких различий.