СУБД используют различные модели данных . Самые старые системы можно разделить на иерархические и сетевые базы данных - это пререляционные модели.
В иерархической модели элементы организованы в структуры, связанные между собой иерархическими или древовидными связями. Родительский элемент может иметь несколько дочерних элементов. Но у дочернего элемента может быть только один предок.
«Система управления информацией » (Information Management System ) компании IMB - пример иерархической СУБД.
Иерархическая модель организует данные в форме дерева с иерархией родительских и дочерних сегментов. Такая модель подразумевает возможность существования одинаковых (преимущественно дочерних ) элементов. Данные здесь хранятся в серии записей с прикреплёнными к ним полями значений. Модель собирает вместе все экземпляры определённой записи в виде «типов записей » - они эквивалентны таблицам в реляционной модели, а отдельные записи — столбцам таблицы. Для создания связей между типами записей иерархическая модель использует отношения типа «родитель-потомок » вида 1:N . Это достигается путём использования древовидной структуры - она «позаимствована » из математики, как и теория множеств, используемая в реляционной модели.
Рассмотрим в качестве примера иерархической модели данных организацию, хранящую информацию о своём работнике: имя, номер сотрудника, отдел и зарплату. Организация также может хранить информацию о его детях, их имена и даты рождения.
Данные о сотруднике и его детях формируют иерархическую структуру, где информация о сотруднике – это родительский элемент, а информация о детях — дочерний элемент. Если у сотрудника три ребёнка, то с родительским элементом будут связаны три дочерних. В иерархической базе данных отношение «родитель-потомок » - это отношение «один ко многим ». То есть у дочернего элемента не может быть больше одного предка.
Иерархические БД были популярны, начиная с конца 1960-х годов, когда компания IBM представила свою СУБД «Система управления информацией. Иерархическая схема состоит из типов записей и типов «родитель-потомок »:
В сетевой модели данных у родительского элемента может быть несколько потомков, а у дочернего элемента - несколько предков. Записи в такой модели связаны списками с указателями. IDMS («Интегрированная система управления данными ») от компании Computer Associates international Inc. - пример сетевой СУБД.
Иерархическая модель структурирует данные в виде древа записей, где есть один родительский элемент и несколько дочерних. Сетевая модель позволяет иметь несколько предков и потомков, формирующих решётчатую структуру.
Сетевая модель позволяет более естественно моделировать отношения между элементами. И хотя эта модель широко применялась на практике, она так и не стала доминантной по двум основным причинам. Во-первых, компания IBM решила не отказываться от иерархической модели в расширениях для своих продуктов, таких как IMS и DL/I . Во-вторых, через некоторое время её сменила реляционная модель, предлагавшая более высокоуровневый, декларативный интерфейс.
Популярность сетевой модели совпала с популярностью иерархической модели. Некоторые данные намного естественнее моделировать с несколькими предками для одного дочернего элемента. Сетевая модель как раз и позволяла моделировать отношения «многие ко многим». Её стандарты были формально определены в 1971 году на конференции по языкам систем обработки данных (CODASYL ).
Основной элемент сетевой модели данных - набор, который состоит из типа «запись-владелец », имени набора и типа «запись-член ». Запись подчинённого уровня («запись-член ») может выполнять свою роль в нескольких наборах. Соответственно, поддерживается концепция нескольких родительских элементов.
Запись старшего уровня («запись-владелец ») также может быть «членом » или «владельцем » в других наборах. Модель данных - это простая сеть, связи, типы пересечения записей (в IDMS они называются junction records , то есть «перекрёстные записи ). А также наборы, которые могут их объединять. Таким образом, полная сеть представлена несколькими парными наборами.
В каждом из них один тип записи является «владельцем » (от него отходит «стрелка» связи ), и один или более типов записи являются «членами » (на них указывает «стрелка» ). Обычно в наборе существует отношение 1:М , но разрешено и отношение 1:1 . Сетевая модель данных CODASYL основана на математической теории множеств.
Известные сетевые базы данных:
В реляционной модели, в отличие от иерархической или сетевой, не существует физических отношений. Вся информация хранится в виде таблиц (отношений ) , состоящих из рядов и столбцов. А данные двух таблиц связаны общими столбцами, а не физическими ссылками или указателями. Для манипуляций с рядами данных существуют специальные операторы.
В отличие от двух других типов СУБД, в реляционных моделях данных нет необходимости просматривать все указатели, что облегчает выполнение запросов на выборку информации по сравнению с сетевыми и иерархическими СУБД. Это одна из основных причин, почему реляционная модель оказалась более удобна. Распространённые реляционные СУБД: Oracle , Sybase , DB2 , Ingres , Informix и MS-SQL Server .
«В реляционной модели, как объекты, так и их отношения представлены только таблицами, и ничем более ».
РСУБД - реляционная система управления базами данных, основанная на реляционной модели Э. Ф. Кодда. Она позволяет определять структурные аспекты данных, обработки отношений и их целостности. В такой базе информационное наполнение и отношения внутри него представлены в виде таблиц - наборов записей с общими полями.
Реляционные таблицы обладают следующими свойствами:
Некоторые поля могут быть определены как ключевые. Это значит, что для ускорения поиска конкретных значений будет использоваться индексация. Когда поля двух различных таблиц получают данные из одного набора, можно использовать оператор JOIN для выбора связанных записей двух таблиц, сопоставив значения полей.
Часто у полей будет одно и то же имя в обеих таблицах. Например, таблица «Заказы » может содержать пары «ID-покупателя » и «код-товара ». А в таблице «Товар » могут быть пары «код-товара » и «цена ». Поэтому чтобы рассчитать чек для определённого покупателя, необходимо суммировать цену всех купленных им товаров, использовав JOIN в полях «код-товара » этих двух таблиц. Такие действия можно расширить до объединения нескольких полей в нескольких таблицах.
Поскольку отношения здесь определяются только временем поиска, реляционные базы данных классифицируются как динамические системы.
Первая модель данных, иерархическая, имеет древовидную структуру («родитель-потомок »), и поддерживает только отношения типа «один к одному » или «один ко многим ». Эта модель позволяет быстро получать данные, но не отличается гибкостью. Иногда роль элемента (родителя или потомка ) неясна и не подходит для иерархической модели.
Вторая, сетевая модель данных , имеет более гибкую структуру, чем иерархическая, и поддерживает отношения «многие ко многим ». Но быстро становится слишком сложной и неудобной для управления.
Третья модель - реляционная - более гибкая, чем иерархическая и проще для управления, чем сетевая. Реляционная модель сегодня используется чаще всего.
Объект в реляционной модели определяется как позиция информации, хранимой в базе данных. Объект может быть осязаемым или неосязаемым. Примером осязаемого объекта может быть сотрудник организации, а примером неосязаемой сущности - учётная запись покупателя. Объекты определяются атрибутами - информационным отображением свойств объекта. Эти атрибуты также известны как столбцы, а группа столбцов - как ряд. Ряд также можно определить как экземпляр объекта.
Объекты связываются отношениями, основные типы которых можно определить следующим образом:
В этом виде отношений один объект связан с другим. Например, Менеджер -> Отдел .
У каждого менеджера может быть только один отдел, и наоборот.
В моделях данных отношение одного объекта с несколькими. Например, Сотрудник -> Отдел .
Каждый сотрудник может быть только в одном отделе, но в самом отделе может быть больше одного сотрудника.
В заданный момент времени объект может быть связан с любым другим. Например, Сотрудник -> Проект .
Сотрудник может участвовать в нескольких проектах, и каждый проект может объединять несколько сотрудников.
В реляционной модели объекты и их отношения представлены двухмерным массивом или таблицей.
Каждая таблица представляет объект.
Каждая таблица состоит из рядов и столбцов.
Отношения между объектами представлены столбцами.
Каждый столбец представляет атрибут объекта.
Значения столбцов выбираются из области или набора всех возможных значений.
Столбцы, которые используются для связи объектов, называются ключевыми. Есть два типа ключей - первичные и внешние.
Первичные служат для однозначного определения объекта. Внешний ключ - это первичный ключ одного объекта, существующий как атрибут в другой таблице.
Преимущества реляционной модели данных:
Недостатки:
В последнее время на рынке СУБД появились продукты, представленные объектными и объектно-ориентированной моделью данных, такие как Gem Stone и Versant ОСУБД. Также производятся исследования в области многомерных и логических моделей данных.
Особенности объектно-ориентированных систем управления базами данных (ООСУБД):
А также поддержку классов объектов и наследование свойств и методов классов подклассами и их объектами.
Ядром любой базы данных является модель данных. Модель данных - совокупность структур данных и операций их обработки.
СУБД основывается на использовании иерархической, сетевой или реляционной модели, на комбинации этих моделей или не некотором их подмножестве.
Иерархическая модель данных.
К основным понятиям иерархической структуры относятся: уровень, элемент, связь. Узел это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину (корень дерева), не подчиненную никакой другой вершине и находящуюся на самом верхнем (первом) уровне (см. рис. 5).
Рис. 5. Иерархическая модель данных
К каждой записи базы данных существует только один (иерархический) путь от корневой записи. Например, для записи С4 путь проходит через записи А и В3.
Пример иерархической структуры. Каждый студент учится в определенной (только одной) группе, которая относится к определенному (только одному) факультету (см. рис. 6).
Рис. 6. Пример иерархической организации данных
Сетевая модель данных
В сетевой структуре каждый элемент может быть связан с любым другим элементом (см. рис 7).
Рис. 7. Сетевая модель данных
Пример сетевой структуры. База данных, содержащая сведения о студентах, участвующих в научно-исследовательских работах (НИРС). Возможно участие одного студента в нескольких НИРС, а также участие нескольких студентов в разработке одной НИРС (см. рис. 8).
Рис. 8. Пример сетевой организации данных
Реляционная модель данных
Эти модели характеризуются простотой структуры данных, удобным для пользователя представлением и возможностью использования формального аппарата алгебры отношений.
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица (отношение) представляет собой двумерный массив и обладает следующими свойствами:
· каждый элемент таблицы - один элемент данных;
· все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;
· каждый столбец имеет уникальное имя;
· одинаковые строки в таблице отсутствуют;
· порядок следования строк и столбцов может быть произвольным.
Пример. Реляционной таблицей можно представить информацию о студентах, обучающихся в вузе.
Поле, каждое значение которого однозначно определяет соответствующую запись, называется простым ключом (ключевым полем). Если записи однозначно определяются значениями нескольких полей, то такая таблица базы данных имеет составной ключ.
Чтобы связать две реляционные таблицы, необходимо ключ первой таблицы ввести в состав ключа второй таблицы (возможно совпадение ключей); в противном случае нужно ввести в структуру первой таблицы внешний ключ - ключ второй таблицы.
Одни и те же данные могут группироваться в таблицы различными способами. Группировка атрибутов в таблицах должна быть рациональной, т.е. минимизирующей дублирование данных и упрощающей процедуры их обработки.
Нормализация отношений - формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных.
Выделяют пять нормальных форм отношений. Эти формы предназначены для уменьшения избыточности информации от первой до пятой нормальных форм. Поэтому каждая последующая нормальная форма должна удовлетворять требованиям предыдущей формы и некоторым дополнительным условиям. При практическом проектировании баз данных четвертая и пятая формы, как правило, не используются.
Процедуру нормализации рассмотрим на примере проектирования многотабличной БД Продажи , содержащей следующую информацию:
· Сведения о покупателях.
· Дату заказа и количество заказанного товара.
· Дату выполнения заказа и количество проданного товара.
· Характеристику проданного товара (наименование, стоимость, марка).
Таблица 2. Структура таблицы Продажи
Таблицу Продажи можно рассматривать как однотабличную БД. Основная проблема заключается в том, что в ней содержится значительное количество повторяющейся информации. Такая структура данных является причиной следующих проблем, возникающих при работе с БД:
· Приходится тратить значительное время на ввод повторяющихся данных. Например, для всех заказов, сделанных одним покупателем, придется каждый раз вводить одни и те же данные о покупателе.
· При изменении адреса или телефона покупателя необходимо корректировать все записи, содержащие сведения о заказах этого покупателя.
· Наличие повторяющейся информации приведет к неоправданному увеличению размера БД. В результате снизится скорость выполнения запросов. Кроме того, повторяющиеся данные нерационально используют дисковое пространство компьютера.
· Любые нештатные ситуации потребуют значительного времени для получения требуемой информации.
Иерархические базы данных имеют форму деревьев с дугами-связями и узлами-элементами данных. Иерархическая структура предполагала неравноправие между данными - одни жестко подчинены другим. Подобные структуры, безусловно, четко удовлетворяют требованиям многих, но далеко не всех реальных задач.2. Сетевая модель данных. В сетевых БД наряду с вертикальными реализованы и горизонтальные связи. Однако унаследованы многие недостатки иерархической и главный из них, необходимость четко определять на физическом уровне связи данных и столь же четко следовать этой структуре связей при запросах к базе.
3. Реляционная модель. Реляционная модель появилась вследствие стремления сделать базу данных как можно более гибкой. Данная модель предоставила простой и эффективный механизм поддержания связей данных.
Во-первых , все данные в модели представляются в виде таблиц и только таблиц. Реляционная модель - единственная из всех обеспечивает единообразие представления данных. И сущности, и связи этих самых сущностей представляются в модели совершенно одинаково - таблицами . Правда, такой подход усложняет понимание смысла хранящейся в базе данных информации, и, как следствие, манипулирование этой информацией.
Избежать трудностей манипулирования позволяет второй элемент модели - реляционно-полный язык (отметим, что язык является неотъемлемой частью любой модели данных, без него модель не существует). Полнота языка в приложении к реляционной модели означает, что он должен выполнять любую операцию реляционной алгебры или реляционного исчисления ( полнота последних доказана математически Э.Ф. Коддом). Более того, язык должен описывать любой запрос в виде операций с таблицами, а не с их строками. Одним из таких языков является SQL .
Третий элемент реляционной модели требует от реляционной модели поддержания некоторых ограничений целостности . Одно из таких ограничений утверждает, что каждая строка в таблице должна иметь некий уникальный идентификатор , называемый первичным ключом. Второе ограничение накладывается на целостность ссылок между таблицами. Оно утверждает, что атрибуты таблицы, ссылающиеся на первичные ключи других таблиц, должны иметь одно из значений этих первичных ключей.
4. Объектно-ориентированная модель. Новые области использования вычислительной техники, такие как научные исследования, автоматизированное проектирование и автоматизация учреждений, потребовали от баз данных способности хранить и обрабатывать новые объекты - текст, аудио- и видеоинформацию, а также документы. Основные трудности объектно-ориентированного моделирования данных проистекают из того, что такого развитого математического аппарата, на который могла бы опираться общая , не существует. В большой степени, поэтому до сих пор нет базовой объектно-ориентированной модели. С другой стороны, некоторые авторы утверждают, что общая объектно-ориентированная модель данных в классическом смысле и не может быть определена по причине непригодности классического понятия модели данных к парадигме объектной ориентированности. Несмотря на преимущества объектно-ориентированных систем - реализация сложных типов данных , связь с языками программирования и т.п. - на ближайшее время превосходство реляционных СУБД гарантировано.
Рассмотрим более подробно эти модели данных далее.
Иерархические базы данных - самая ранняя модель представления сложной структуры данных. Информация в иерархической базе организована по принципу древовидной структуры, в виде отношений "предок- потомок ". Каждая запись может иметь не более одной родительской записи и несколько подчиненных. Связи записей реализуются в виде физических указателей с одной записи на другую. Основной недостаток иерархической структуры базы данных - невозможность реализовать отношения " многие-ко-многим ", а также ситуации, когда запись имеет несколько предков.
Иерархические базы данных . Иерархические базы данных графически могут быть представлены как перевернутое дерево , состоящее из объектов различных уровней. Верхний уровень ( корень дерева ) занимает один объект , второй - объекты второго уровня и так далее.
Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка ( объект , более близкий к корню) к потомку ( объект более низкого уровня), при этом объект -предок может не иметь потомков или иметь их несколько, тогда как объект - потомок обязательно имеет только одного предка. Объекты, имеющие общего предка, называются близнецами.
Иерархической базой данных является Каталог папок Windows , с которым можно работать, запустив Проводник. Верхний уровень занимает папка Рабочий стол . На втором уровне находятся папки Мой компьютер , Мои документы, Сетевое окружение и Корзина , которые являются потомками папки Рабочий стол , а между собой является близнецами. В свою очередь , папка Мой компьютер является предком по отношению к папкам третьего уровня -папкам дисков ( Диск 3,5(А:), (С:), (D:), (Е:), (F:)) и системным папкам ( сканер , bluetooth и.т.д.) - на рис. 4.1 .
Рис.
4.1.
Организация данных в СУБД иерархического типа определяется в терминах: элемент, агрегат, запись ( группа ), групповое отношение , база данных .
| Атрибут (элемент данных) | - наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем. |
| Запись | - именованная совокупность атрибутов. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип записи определяется составом ее атрибутов. Экземпляр записи - конкретная запись с конкретным значением элементов. |
| Групповое отношение | - иерархическое отношение между записями двух типов. Родительская запись (владелец группового отношения) называется исходной записью, а дочерние записи (члены группового отношения) - подчиненными. Иерархическая база данных может хранить только такие древовидные структуры. |
Корневая запись каждого дерева обязательно должна содержать ключ с уникальным значением. Ключи некорневых записей должны иметь уникальное значение только в рамках группового отношения. Каждая запись идентифицируется полным сцепленным ключом, под которым понимается совокупность ключей всех записей от корневой, по иерархическому пути.
При графическом изображении групповые отношения изображают дугами ориентированного графа, а типы записей - вершинами ( диаграмма Бахмана).
Для групповых отношений в иерархической модели обеспечивается автоматический режим включения и фиксированное членство. Это означает, что для запоминания любой некорневой записи в БД должна существовать ее родительская запись .
Рассмотрим следующую модель данных предприятия (см. рис. 4.2): предприятие состоит из отделов, в которых работают сотрудники. В каждом отделе может работать несколько сотрудников, но сотрудник не может работать более чем в одном отделе.
Поэтому, для информационной системы управления персоналом необходимо создать групповое отношение, состоящее из родительской записи ОТДЕЛ (НАИМЕНОВАНИЕ_ОТДЕЛА, ЧИСЛО_РАБОТНИКОВ) и дочерней записи СОТРУДНИК (ФАМИЛИЯ, ДОЛЖНОСТЬ, ОКЛАД). Это отношение показано на рис. 4.2 (а) (Для простоты полагается, что имеются только две дочерние записи).
Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры: заказчик - контракты с ним - сотрудники, задействованные в работе над контрактом. Это дерево будет включать записи ЗАКАЗЧИК (НАИМЕНОВАНИЕ_ЗАКАЗЧИКА, АДРЕС), КОНТРАКТ(НОМЕР, ДАТА,СУММА), ИСПОЛНИТЕЛЬ (ФАМИЛИЯ, ДОЛЖНОСТЬ, НАИМЕНОВАНИЕ_ОТДЕЛА) (
Классификация моделей данных базируется на понятиях о взаимосвязи объектов. Между таблицами базами данных могут существовать четыре типа различных связей: «один к одному»; «один ко многим»; «многие ко многим».
При отношении «один к одному » в каждый момент времени одной записи таблицы «1» соответствует не более одной записи таблицы «2». Например, одному клиенту соответствует только один номер в гостинице. Этот тип связи используют не очень часто, поскольку такие данные могут быть помещены в одну таблицу. Такую связь используют для разделения очень широких таблиц, например, для разделения таблицы с информацией о сотрудниках фирмы на две – служебной и личной информацией.
Связь с отношением «один ко многим » характеризует то, что одному экземпляру информационного объекта «1» соответствует 0,1,2 и более экземпляров объекта «2». Такое отношение существует, например, между таблицами «Поставщики» и «Товары», т.е. каждый поставщик может продавать различные товары, но у каждого товара есть единственный поставщик.
Отношение «многие ко многим » предполагает, что в каждый момент времени одной записи таблицы «1» соответствует несколько экземпляров таблицы «2» и наоборот. Примером может служить связь между информационными объектами «Клиент» и «Банк». Один клиент хранит средства во многих банках. Один банк обслуживает многих клиентов. Реализуется отношение с помощью третьей (связующей) таблицы, ключ которой состоит, по крайней мере, из двух полей, которые являются полями внешнего ключа в исходных таблицах.
Известны три основных типа моделей данных.
Иерархическая модель. Предполагает организацию данных в виде древовидной структуры. Дерево представляет собой иерархию элементов. На самом верхнем уровне структуры находится корень дерева. У одного дерева может быть только один корень, остальные - узлы, называемые порожденными. Каждый узел имеет исходный, находящийся выше него.
Иерархическая базой данных представляет собой как множество отношений и веерных отношений, для которых соблюдаются два ограничения: существует единственное отношение, называемое корневым, которое не является зависимым ни в одном веерном отношении; все остальные отношения (кроме корневого) являются зависимыми отношениями только в одном веерном отношении.
Записью иерархической БД называется множество значений, содержащее одно значение корневого отношения и все вееры, доступные от него. В нашем примере запись образуют данные, относящиеся к одному факультету.
Сетевая модель . В основу модели положены сетевые структуры, в которых любой элемент может быть связан с любым другим элементом. Информационными конструкциями в модели являются отношения и веерные отношения. Последние подразделяют на основные и зависимые. Веерным отношением W(R,S) называется пара отношений R и S и связь между ними при условии, что каждое значение S связано с единственным значением R . Отношение R называют исходным (основным), а S - порожденным (зависимым).
В структуру основного и зависимого отношений вводится дополнительный атрибут, называемый адресом связи, который обеспечивает соответствие каждого значения зависимого отношения S с единственным значением основного отношения R . Адрес связи хранит начальный адрес или номер следующей обрабатываемой записи. Кольцевая структура адресов связи называется веером . Роль "ручки" веера играет запись основного отношения.
Недостатком рассмотренных выше моделей данных является то, что при добавлении новых вершин или установлении новых связей возникают проблемы выгрузки данных из базы и загрузки их в новую структуру. При этом возможна утрата данных или возникновения неопределенных значений данных.
Реляционная модель. В основе структуры данных этоймодели лежит аппарат реляционной алгебры и теории нормализации. Модель предполагает использование двумерных таблиц (отношений).
Ограничения на отношения реляционной модели: каждый элемент таблицы представляет собой простой элемент данных; в таблице нет одинаковых строк; столбцам (полям) присвоены уникальные имена; все строки таблицы имеют одну и ту же структуру; в таблице порядок строк и столбцов произволен.
Связь между таблицами осуществляется посредством значений одного или нескольких совпадающих полей. Каждая строка таблицы в реляционных базах данных уникальна. Для обеспечения уникальности строк используют ключи, которые содержат одно или несколько полей таблицы. Ключи хранятся в упорядоченном виде, что обеспечивает прямой доступ к записям таблицы во время поиска.
План
База данных (БД)
СУБД
Модель данных
Иерархическая модель базы данных
Сетевая модель базы данных
Строка таблицы - это запись, которая содержит информацию об отдельном объекте таблицы (один ученик).
Структура записей одинакова; совокупность элементов данных, из которых состоит запись, называется полем. Информация записи находится в полях. Поле таблицы - это колонка таблицы.
Одинаковые записи в таблице не допускаются, поскольку во всех записях поля им предоставляют уникальные имена, фамилия СУБД Access позволяет:
Поле должно быть однородным по типу по всем записям в колонке (или текстовые данные, числовые и т.д).
Реляционная модель базы данных, как правило, содержит несколько таблиц, связь между которыми осуществляется с помощью специального поля - ключа .
Примеры реляционных СУБД: dBASE, FoxBase, FoxPro и Access.
Приложение MS Access является системой управления базами данных, которая входит в состав пакета Microsoft Office и предназначена для работы за персональным компьютером или в сети под управлением операционной системы Windows.
База данных СУБД Access является реляционной базой данных, которая состоит из взаимосвязанных двумерных таблиц.
СУБД Access дает возможность:
· Проектировать табличные объекты базы данных;
· Устанавливать связи между таблицами;
· Вводить, хранить, просматривать, сортировать, изменять данные таблицы с использованием аппарата алгебры логики и индексирования;
· Создавать и использовать объекты БД.
Объекты СУБД Access:
Базы данных - файл, который содержит различные объекты сохранения данных.
Таблицы (tables ) - организация хранения данных в виде двумерного массива. Она является основным объектом БД. Остальные - производные от таблицы.
Формы - объекты для отображения данных из таблицы на экране в удобном для просмотра и обработки виде.
Запросы - объекты для выбора и фильтрации данных таблицы по определенным критериям.
Отчет - формирование документа данных из таблицы для печати.
Макросы - описание действий в виде последовательности команд и их автоматического выполнения.
Модули - программы на Visual Basic, которые разрабатывает пользователь для реализации нестандартных процедур.
Обзор реляционной модели данных. Модель «сущность-связь». Понятие отношения, атрибута, ключа, связи. Классификация связей с множественностью и полнотой. Правила построения модели данных предметной области.
Модель "сущность-связь" (ER-модель) (англ. Entity-relationship model или entity-relationship diagram) - модель данных, позволяющая описывать концептуальные схемы с помощью обобщенных конструкций блоков. ER-модель - это метамодель данных, то есть средство описания моделей данных.
ER-модель удобна при проектировании информационных систем, баз данных, архитектур компьютерных приложений и других систем (моделей). С помощью такой модели выделяют существенные элементы (узлы, блоки) модели и устанавливают связи между ними.
Существует ряд моделей для представления знаний. Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель "сущность-связь" (entity - relationship model, ER - model ).
Модель "сущность-связь" основывается на какой-то важной семантической информации о реальном мире и предназначена для логического представления данных. Она определяет значения данных в контексте их взаимосвязи с другими данными. Важным для нас является тот факт, что из модели "сущность-связь" могут быть порождены все существующие модели данных (иерархическая, сетевая, реляционная, объектная), поэтому она является наиболее общей. Любой фрагмент предметной области может быть представлен как множество сущностей, между которыми существует некоторое множество связей.
ER-модель - это одна из наиболее простых визуальных моделей. Она позволяет постичь структуру объекта «крупными мазками», в общих чертах. Такое общее описание структуры называется ER-диаграммой или онтологией выбранной предметной области (area of interest).
Типичные примеры использования ER-модели данных IDEF1x (ICAM DEFinition Language) и dimensional modelling.
Отношение реляционных баз данных .
Отношения реляционной базы данных делятся на два класса: объектные и связные. Объектное отношение хранит данные объекты (экземпляры сущности). В объектном отношении один (или несколько) из атрибутов, однозначно идентифицирующих объект. Такой ключевой атрибут называется (единичным или множественным) ключом отношений или первичным атрибутом. Ключ, как правило, находится в первом столбце. Остальные атрибуты функционально зависят от данного ключа. Ключ может включать несколько атрибутов (сложный ключ). В объектном отношении атрибуты не должны дублироваться. Это основное ограничение в реляционной базе данных для сохранения целостности данных. Связное отношение хранит ключи двух или более объектных отношений, то есть по ключам устанавливаются связи между объектами отношений. Связное отношение может иметь и другие атрибуты, которые функционально зависят от этой связи. Ключи в связных отношениях называются внешними (сторонними) ключами, поскольку они являются первичными ключами других отношений.
Условия и ограничения, которые накладываются на отношения реляционных баз данных на табличном уровне представления, можно сформулировать следующим образом:
· не может быть одинаковых первичных ключей, то есть все строки (записи) должны быть уникальными;
· все строки должны иметь одинаковую типовую структуру;
· имена столбцов таблицы должны быть различны, а значения столбцов должны быть однотиповыми;
· значения столбцов должны быть атомарными, т.е. не могут быть компонентами других отношений;
· должна сохраняться целостность внешних ключей;
· порядок размещения строк в таблице несущественный - он влияет только на скорость доступа к нужной строки.
Обеспечивается поддержка таких типов связей между записями: один ко многим; многие к одному, многие ко многим .
Основные этапы работы с базами данных:
Проектирование таблицы.
После создания нового банка данных с помощью директивы File/New Database (Создать новый банк) или открытие существующего банка с помощью File/Open Database (Открыть банк) на экране в рамках окна Access появляется окно банка данных.
В меню File выберите директиву New (Создать новый объект), а в подменю - опцию Table (Таблица).
Назначение имен полей
Каждая строка спецификации определяет характеристики одного поля записи. В колонку Fіeld Name задается имя поля. Оно может иметь длину до 64 символов и может содержать кириллицу, пробелы и специальные символы, за исключением точек, восклицательного знака и угловых скобок. Естественным ограничением является запрет на наличие в одной таблице двух полей с одинаковыми именами.
Установка типа данного поля
Тип данных вносится в столбец Data Type, причем его можно выбрать из списка доступных типов.
Text. Текстовые поля содержат текст, длина которого не может быть больше 255 символов. Реальная длина поля устанавливается с помощью параметра Fіeld Size (Размер поля)
Memo. В Memo-полях текст длиной до 32000 символов. Поля этого типа данных не могут индексироваться.
Number. Числовые поля содержат произвольные числовые значения. Диапазон допустимых значений определяется параметром Fіeld Size (Размер поля).
Date/Time. Поля даты/времени содержат значения даты и времени в диапазоне от 100 до 9999 года.
Currency. В денежных полях можно хранить числа с точностью до 15 разрядов слева от запятой и четырех десятичных разрядов (обычно достаточно двух) справа от запятой.
Counter. Поле счетчика, содержит число, которое автоматически увеличиваются Access на 1, когда в таблицу добавляется новый блок данных.
Yes/No. В таких полях хранятся значения Yes (Да) или No (Нет). Поля данного типа не могут индексироваться.
OLE Object. В OLE-полях содержатся объекты, такие как, например, Excel-таблица или Microsoft Draw-графика, обработанные OLE-сервером. Размер поля может быть до 128 МБ.
Определение размера поля. Для числовых полей параметр Fіeld Size может иметь одно из следующих значений:
Byte . Хранит числа от 0 до 255 (только целые). Занимает 1 байт.
Іnteger . Хранит числа от -32768 до 32767 (только целые). Занимает 2 байта.
Long Іnteger . Хранит числа от -2147483648 до 2147483647 (только целые). Занимает 4 байта.
Sіngle . Хранит числа с шестиразрядной точностью от 3,402823Е38 до 3.402823Е38. Занимает 4 байта.
Double . Хранит числа с десятиразрядной точностью от -1.79769313486232Е308 до 1,79769313486232Е308. Занимает 8 байтов (стандартная установка).
Определение параметров поля
Характеристики каждого поля определяются рядом параметров. Эти параметры регламентируют способы обработки, хранения и индикации данных.
Fіeld Sіze (Размер поля). Устанавливает максимальную длину текстового поля или способ представления чисел в поле типа Number.
Format (Формат). Определяет способ представления данных. Наряду с определенными форматами допускается использование собственных форматов пользователя.
Decіmal Places (Десятичные разряды). Устанавливает количество разрядов справа от десятичной запятой.
Captіon (Надпись). Определяет надпись, которая будет использоваться в качестве наименования поля в формуляре или отчете. Если для этого параметра не будет задано никакое значение, то, как надпись, будет по умолчанию использовано имя поля.
Default Value (Значение по умолчанию). Устанавливает значение, которое будет автоматически введено в поле при генерации блока данных.
Valіdatіon Rule (Ограничения введения). Правило, которое ограничивает допустимые для ввода в поле данные.
Valіdatіon Text (Сообщение о нарушении). При попытке ввести в поле данные, не удовлетворяющие правилу, сформулированному в Valіdatіon Rule.
Іndexed (Индексированное поле). Признак индексирования.
Добавление и удаление полей
В готовую спецификацию можно вносить изменения. В частности, можно изменять параметры отдельных полей, добавлять поля в запись в нужных местах и удалять лишние. Но при этом стоит постараться внести все исправления в спецификацию до начала заполнения банка данных, потому что попытка изменить параметры полей заполненной базы может вызвать потерю или искажение данных.
1. Если удалить поле, которое содержит данные, то появится предупреждающее сообщение с вопросом о том, действительно ли пользователь хочет выполнить удаление, нажмите на кнопку Cancel.
2. В меню Edit выберите директиву Undo Delete (Отменить удаление). Однако отменить операцию удаления и восстановить исходное состояние таблицы можно только в случае, если после удаления не были сделаны никакие другие изменения в структуре или содержании банка. Access гарантирует возможность отмены, но только для последней выполненной операции.
3. Закройте окно таблицы и нажмите командную кнопку No (Нет) в диалоговом окне запроса о необходимости сохранения изменений. Однако в этом случае будут проигнорированы и все другие изменения, выполненные за этот сеанс работы с таблицей.
Установка первичного ключа
После того как дано определение всем полям, стоит выбрать минимум одно поле для использования как первичный ключ. Объявления первичного ключа препятствует введению повторяющихся блоков данных, поскольку поле таблицы, используемое в качестве первичного ключа, содержит однозначный идентификатор для каждого блока данных. Это поле не может содержать одинаковую величину в двух разных записях.
Первичный ключ может быть определен только в режиме проектирования таблицы. Маркируйте поле, что должно стать полем первичного ключа и вызовите директиву Set Ргімагу Key (Установить ключ) в меню Edit. Маркированная поле немедленно обозначается значком ключа в селекторном столбике (это и есть признак того, что поле объявлено первичным ключом) и соответственно индексируется.
Если к моменту выхода из режима проектирования первичный ключ для создаваемой таблицы не будет объявлен, то Access спросит, стоит ли включить в таблицу поле первичного ключа. Если пользователь ответит положительно (Yes), то Access создаст особое поле с именем ID, в которое для каждого блока данных будет вводиться.
Понятие таблицы, поля, записи. Основные этапы работы с базами данных в среде системы управления базами данных. Отображение модели «сущность-связь» базы данных. Свойства полей, типы данных. Ввод данных в таблицы. Сортировка, поиск и фильтрация данных.
Таблица - это набор именованных полей, в которых описываются свойства объектов.
Таблица предусматривает отражение данных в виде строк и столбцов. Столбец содержит характеристику объектов; строка - совокупность характеристик об одном экземпляре объекта. Записью является строка таблицы базы данных
Поле - столбец таблицы, предназначенный для хранения значений определенного свойства (параметра) объекта.
Запись - строка таблицы. Одна запись содержит данные про отдельный объект, который описывают в базах данных.
СУБД Access позволяет создавать объекты базы данных, в которых будет содержаться информация из различных таблиц. Для этого необходимо установить связь между таблицами. При создании связи будут объединены (связаны) записи в этих таблицах. При этом пользуются условными сроками, говорят о базовой и зависимой таблице. В обеих таблицах должны быть поля, которые имеют одинаковые значения. Тогда связью между таблицами будет эта пара полей (одно - в базовой таблице, второе - в зависимой). Связанные поля могут иметь разные имена, но тип значений этих полей обязательно должен совпадать.
Проектирование баз данных состоит из концептуального, логического и физического этапов. Каждый этап использует свою модель данных.
Существует несколько методов построения концептуальной модели базы данных. Один из наиболее распространенных методов основывается на модели, которая основана на предоставлении предметной области в виде двух типов объектов - сущностей и связей.
Сущность - это объект предметной области, который является множеством элементов. Примеры сущностей - ученики, предметы, кружки. Каждый элемент сущности - это конкретный экземпляр. Сущности представляются в базе данных в виде таблицы. Имя сущности - имя таблицы, характеристики - названия столбцов таблицы, а экземпляры - строки таблицы.
Существует понятие степени связи между сущностями, относящихся к связи.
Степень связи определяет, какое количество экземпляров одной сущности может быть связано с экземплярами другой сущности, принадлежащие к этой связи.
На этапе логического проектирования сущности и связи превращаются в логическую модель данных, построенную по законам логики. Как мы уже упоминали на первом уроке, существует несколько логических моделей данных. Среди них выделяют реляционную, иерархическую и сетевую. Наиболее широко сейчас используется реляционная модель. На английском «relation» - отношение, отсюда и название модели.
Отношение представляется в виде таблицы, состоящей из строк и столбцов. Каждый столбец отношения называют полем, а строку - записью. Названия полей - атрибутов. В отличие от обычной таблицы основное свойство отношения заключается в том, что в нем не должно быть одинаковых записей. Это связано с тем, что отношение отражает название определенного множества объектов, а каждая запись представляет элемент этого множества. Конечно, элементы множества должны быть разными.
Атрибуты (группы атрибутов) обеспечивают уникальность (неповторимость) каждой строки, которая называется ключом отношения. Ключей в отношении может быть несколько.
Существует несколько методов построения концептуальной модели базы данных. Один из наиболее распространенных методов основывается на ER-модели. Эта модель основана на представлении предметной области в виде двух типов объектов - сущностей и связей.
Сущность - это объект предметной области, который является множеством элементов. Примеры сущностей - ученики, предметы, кружки. Каждый элемент сущности - это конкретный экземпляр, например ученик Сидоров или предмет «математика». Как правило, сущности выражаются существительными. Сущности представляются в базе данных в виде таблицы. Имя сущности - имя таблицы, характеристики - названия столбцов таблицы, а экземпляры - строки таблицы. В табл. показано, как понимать основные термины сущности.
Сущность УЧЕНИК - имя сущности.
Мы привыкли, что в таблицу можно помещать любую информацию. Однако таблицы-сущности отличаются от обычных таблиц тем, что в них не может быть двух одинаковых строк.
Например, пусть сущность УЧЕНИК имеет характеристики ФАМИЛИЮ, ИМЯ, ОТЧЕСТВО, ДАТА РОЖДЕНИЯ, ДОМАШНИЙ АДРЕС. Будем записывать это в таком виде: УЧЕНИК (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ДАТА РОЖДЕНИЯ, ДОМАШНИЙ АДРЕС). Примеры экземпляров этой сущности - (Сидоров, Петр, Васильевич, 01.02.1985, ул. Цветочная 33), (Иванова, Ольга, Борисовна 12.05.1986, просп. Победы, 231, кв. 3).
Связи отражают важные для проектируемой базы данных отношения между сущностями. Это связи - ОБУЧАЕТСЯ (ученик в классе), ИЗЛАГАЕТ (учитель предмет для класса в кабинете) и т.п. Как правило, связи выражаются глаголами.
Связь между сущностями можно изобразить в виде линий между конкретными экземплярами. Ниже иллюстрируется связь ПОСЕЩАЕТ между сущностями УЧЕНИК и КРУЖОК. Если сущность можно представить в виде таблицы, то для представления связей нужно создать дополнительные таблицы, в которые помещают информацию о связываемых данных.
Объекты СУБД Access:
Таблица - организация хранения данных в виде двумерного массива. Она является основным объектом БД. Остальные - производные от таблицы.
Форма - помогает создавать интерфейс пользователя, ее используют для ввода, изменения или отображения данных.
Запросы - объекты для выбора и фильтрации данных таблицы по определенным критериям.
Отчет - формирование документа.
Макросы - описание действий в виде последовательности команд и их автоматического выполнения.
Модули - программы на языке Visual Basic, которые разрабатывает пользователь для реализации нестандартных процедур.
Создание таблиц.
Таблицы - это объекты, в которых непосредственно хранятся данные.
Создать таблицу можно, выбрав в окне БД на вкладке Таблица и используя Конструктор или Мастер. Но есть и другие способы (см. табл.).
Для заполнения таблицы необходимо перейти в режим заполнения таблицы, открыв ее.
Заполнение таблиц.
Таблицы состоят из полей и записей. Полями называют столбцы, а записями - строки. Внести запись в таблице означает заполнить строку. Чтобы создать таблицу, необходимо определить ее поля, типы данных этих полей, а иногда некоторые дополнительные свойства этих полей. Не все данные занимают в компьютере одинаковый объем. Для их компактного хранения необходимо четко определить их тип.
Типы данных.
В таблицах Access можно указать типы данных.
| ФОРМА | ИСПОЛЬЗУЕТСЯ ДЛЯ ОТОБРАЖЕНИЯ |
| Текст | Короткие буквенно-цифровые значения, например фамилия или адрес. |
| Число | Числовые значения, например расстояние. Обратите внимание, что для денежных единиц существует отдельный тип данных. |
| Денежная единица | Денежные значения. |
| Да/Нет | Значение "Да" и "Нет" и поля, содержащие только одно из двух значений. |
| Дата и врем | Значения даты и времени для лет от 100 до 9999. |
| Форматированный текст | Текст или сочетание текста и чисел, которое можно отформатировать с помощью элементов управления цветом и шрифтом. |
| Вычисляемое поле | Результаты вычисления. В расчетах должны использоваться другие поля той же таблицы. Для создания вычислений используется построитель выражений. |
| Вложения | Вложенные в записи базы данных, файлы электронных таблиц, документы, диаграммы и другие типы поддерживаемых файлов, подобно вложений в сообщениях электронной почты. |
| Гиперссылки | Текст или сочетание текста и чисел, которое хранится в виде текста и используется как адрес гиперссылки. |
| Примечание | Длинные фрагменты текста. Поле типа "Примечание" часто используется для хранения подробного описания продукта. |
| Подстановка | Список значений из таблицы или запроса, или набор значений, указанных при создании поля. Поле подстановок можно создать с помощью мастера подстановок. Тип данных в поле подстановок текстовый или числовой, в зависимости от того, какие параметры были выбраны в мастере. |
Ввод и редактирование.
Ввод и редактирование данных происходит путем переключения между режимами Представления таблицы и Конструктор.
Несмотря на то, что для ввода данных, особенно в базы данных Access с несколькими пользователями, лучше использовать формы, данные можно вводить и изменять непосредственно в таблице.
Тип данных, которые пользователь может вводить в таблицу, зависит от следующих аспектов.
По умолчанию поля в таблицы содержат определенный тип данных, например текст или числа. Следует вводить тот тип данных, который получает соответствующее поле.
Иначе отображается сообщение об ошибке.
Если к полю применена маска ввода, формат, состоящий из постоянных символов (таких как скобки, точки или дефисы) и специальных символов маски, указывающих, в какие позиции, в каком количестве и какого типа данные можно вводить, может возникнуть необходимость вводить данные в определенном формате.
За исключением вложений и многозначных списков в большинство полей можно вводить только один тип данных. Если неизвестно, может ли поле содержать вложения, просмотрите его свойства. Если поле - многозначный список, отображается флажок рядом с каждым элементом списка.
Понятие языка SQL.
Языковой поддержкой проведения транзакций является, как правило, язык SQL. Языки реляционного исчисления основаны на классическом исчислении предикатов. Они предоставляют пользователю набор правил для написания запросов к базам данных. В таком запросе содержится лишь информация о желаемом результате. На основе запроса система управления базами данных автоматически, путем формирования новых отношений, формирует желаемый результат. Языки реляционного исчисления являются непроцедурными. Первый язык реляционного исчисления ALFA была разработана самим Е.Ф.Коддом.
В настоящее время широкое распространение получил язык SQL (Structured Query Language). Язык SQL был разработан фирмой IBM в середине 70-ых годов, а затем одобрен и поддержан многими компаниями как стандарт языка управления реляционными базами данных. Эта речь была разработана на основе стандарта языка, которая использовалась в системе управления базами данных dBase. Международная федерация по обработке информации (AFIP) и международная организация по стандартизации (ISO) формируют и уточняют стандарты для дальнейших разработок языка SQL. Речь ориентирована на проведение операций с данными, которые подаются в виде логически взаимосвязанной совокупности таблиц. Основным отличием от исходного языка dBase является то, что язык SQL разработан для проведения операций с таблицами, в то время как язык dBase ориентирован на работу с записями.
Функции языка SQL.
Использование концепции операций, ориентированных на табличное представление данных, позволило создать компактный язык SQL с небольшим набором команд. Такой подход позволяет достаточно легко определять, выводить и обновлять информацию в базе данных, упростив программирование сложных запросов. Особенностью команд языка SQL является то, что они в большей степени ориентированы на конечный результат обработки данных, чем на процедуру этой обработки. Система определяет оптимальный путь до вывода данных. Язык SQL - это непроцедурная речь. Полный набор команд языка SQL включает около 30 команд.
Таблица языка SQL представляет собой совокупность строк и столбцов, в которых строкам таблицы соответствуют записи, а колонкам - поля. Кроме обычных таблиц, язык SQL позволяет создавать особый вид таблиц - выборку. Выборка - это подмножество строк и столбцов из одной или нескольких таблиц. Часто выборку называют виртуальной таблицей, поскольку она фактически не содержит данных, а лишь позволяет их воспроизводить. Данные в выборке отражают реальные изменения в соответствующих таблицах и наоборот, изменение данных в обновляемых выборках приводит к изменению этих данных в первичных таблицах.
Эффективное использование команд языка SQL реализуется благодаря использованию и созданию специальной информации, которая позволяет ссылаться на каждую таблицу и выборку. Эта информация содержится в файлах, которые называются каталогами таблиц, которые формируются во время создания базы данных. Каждая команда языка SQL заканчивается “;”. Каждая команда SQL, которая называется предложением, начинается глаголом, которое определяет имя базовой операции. В состав многих команд входят ключевые слова и предложения, которые уточняют выполнения базовых операций. Кроме того, в команду SQL нужно включить данные, которые будут обрабатываться и (или) операции, которые нужно над этими данными выполнить.
Язык SQL оперирует с понятием баз данных, содержащих всю информацию, которая необходима для обработки данных в прикладной программе. В полный состав баз данных SQL входят такие компоненты:
· таблицы - основные структуры данных в базах данных;
· выборки - тип виртуальной таблицы, которая обеспечивает ввод-вывод определенных строк и столбцов из одной или нескольких таблиц;
· синонимы - альтернативные имена таблиц и выборок;
· индексные файлы, которые присоединяются к таблицам для обеспечения быстрого поиска данных и поддержания целостности баз данных;
· каталоги - множество таблиц в каждой базе данных, описывающих базы данных и их содержание.
Развитие языка SQL.
Первый стандарт языка SQL появился в 1989 году (SQL-89) и поддерживался практически всеми коммерческими реляционными системами управления баз данных. Он имел общий характер и допускал широкое трактование. Преимуществами SQL-89 можно считать стандартизацию синтаксиса и семантики операторов выборок и манипулирования данными, а также фиксацию средств ограничения целостности базы данных. Однако в этой версии отсутствуют такие разделы, как манипулирования схемой базы данных и динамический SQL .
Неполнота требований SQL -89 привела к созданию в 1992 году следующей версии языка SQL -92, которая охватывала более широкий диапазон функций: манипулирование структурой базы данных, управление транзакциями и сессиями, динамический SQL. В стандартной версии предполагается три уровня: базовый, промежуточный и полный. Только последние версии систем управления базами данных обеспечивают совместимость с полным стандартом. Работа над совершенствованием этого языка не прекращается. Усовершенствования будут, в первую очередь, проводится в направлении включения механизма триггеров, определении произвольного типа данных.
План
1. Понятие модели данных, базы данных. Понятие и назначение систем управления базами данных.
2. Обзор реляционной модели данных. Модель «сущность-связь». Понятие отношения, атрибута, ключа, связи. Классификация связей с множественностью и полнотой. Правила построения модели данных предметной области.
3. Понятие таблицы, поля, записи. Основные этапы работы с базами данных в среде системы управления базами данных. Отображение модели «сущность-связь» базы данных. Свойства полей, типы данных. Ввод данных в таблицы. Сортировка, поиск и фильтрация данных.
4. Понятие запроса к реляционной базе данных. Понятие о языке запросов SQL.
5. Создание таблиц, форм, запросов и отчетов с помощью мастеров.
6. Обмен данными между СУБД и другими программами, предназначенными для обработки документов. Совместное использование базы данных.
Понятие модели данных, базы данных. Понятие и назначение систем управления базами данных.
База данных (БД) - это структурированная совокупность взаимосвязанных данных определенной предметной области (реальных о6ъектов, процессов, явлений и т.п.).
Примеры: БД о наличии медикаментов; БД в системе расписания самолетов, поездов или БД продажи билетов транспорта; БД документов учащихся школы, картотека отдела кадров или в библиотеки и т.д..
Появление компьютерной техники повысило эффективность работы с базами данных. Доступ к данным и управление ими происходит в среде специального программного пакета - системы управления базами данных (СУБД).
СУБД - это программа, с помощью которой осуществляется хранение, обработка и поиск информации в базах данных.
Организация данных во внутренней сфере характеризуется двумя уровнями - логическим и физическим. Физическая организация данных определяет способ размещения данных непосредственно на машинном носителе. Логическая организация данных на машинном носителе зависит от программных средств, организации и ведения данных во внутренней сфере. Метод логической организации данных определяется используемым типом структур данных и видом модели, которая поддерживается программными средствами.
Модель данных - это совокупность взаимосвязанных структур данных и операций над этими структурами. Для размещения одной и той же информации во внутренней сфере могут быть использованы различные структуры и модели данных. Это зависит от пользователя, от технического и программного обеспечения, определяется сложностью автоматизированных задач и объемом информации.
Существуют такие модели данных: иерархическая, реляционная, постреляционная, многомерная, объектно-ориентированная.
По структуре организации информации в БД различают такие модели баз данных: иерархическая, сетевая и реляционная.
Иерархическая модель базы данных . Эта модель представляет собой структуру данных, которые упорядочены по подчинению от общего к конкретному; напоминает «дерево» (граф), поэтому имеет такие же параметры: уровень, узел, связь. Модель работает по такому принципу: несколько узлов низшего уровня соединяются при помощи связи с одним узлом высшего уровня.
Иерархическая модель базы данных имеет такие свойства: несколько узлов низшего уровня связаны только с одним узлом высшего уровня; дерево иерархии имеет только одну вершину, что не подлежит другой; каждый узел имеет имя собственное, есть только один маршрут от вершины дерева (корневого узла) до любого узла структуры.
Сетевая модель базы данных . Общим видом она похожа на иерархическую. Имеет такие же составляющие структуры, отличается характером отношения между ними. Между элементами структуры произвольное, не ограниченное количество элементов-связь.
Реляционная модель базы данных . (Происхождение названия от латинского слова relatio - отношение). Модель построена на взаимоотношениях между составляющими структуры. Представляет собой одну таблицу или совокупность взаимосвязанных двумерных таблиц.
Реляционная модель создана на основе двухмерной таблицы.
Строка таблицы - это запись, которая содержит и
