Реляционной.

Relation – отношения (таблицы). Понятие реляционной модели связано с разработками известного американского специалиста в области СУБД Эдварда Кодда.

Достоинства:

1. Простая структура;

2. Данные связаны логически;

3. Группа записей обрабатывается одной командой;

4. Удобные для пользователя таблицы представления;

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

Недостатки:

1. Не всегда применима для сложных иерархических и сетевых данных.

Также БД классифицируются по способу обработки данных: централизованные и распределённые. Централизованные – на одном компьютере. Распределённые – части на разных компьютерах. По способу доступа к данным: с локальным доступом и с сетевым или удалённым доступом.

E-R модель.

Модель сущность-связь (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области.

ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма) (англ. entity-relationship diagram, ERD).

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

Представление Er-диаграммы зависит от нотации моделирования.

Нотация Питера Чена

Простая ER-модель MMORPG с использованием нотации Питера Чена.

Множества сущностей изображаются в виде прямоугольников, множества отношений изображаются в виде ромбов. Если сущность участвует в отношении, они связаны линией. Если отношение не является обязательным, то линия пунктирная. Атрибуты изображаются в виде овалов и связываются линией с одним отношением или с одной сущностью.^[3]

Crow's Foot

Пример отношения между сущностями согласно нотации Crow's Foot.

Данная нотация была предложена Гордоном Эверестом под названием Inverted Arrow («перевёрнутая стрелка»), однако сейчас чаще называемая Crow's Foot («воронья лапка») или Fork («вилка»).

Согласно данной нотации, сущность изображается в виде прямоугольника, содержащем её имя, выражаемое существительным. Имя сущности должно быть уникальным в рамках одной модели. При этом, имя сущности — это имя типа, а не конкретного экземпляра данного типа. Экземпляром сущности называется конкретный представитель данной сущности.

Связь изображается линией, которая связывает две сущности, участвующие в отношении. Степень конца связи указывается графически, множественность связи изображается в виде «вилки» на конце связи. Модальность связи так же изображается графически — необязательность связи помечается кружком на конце связи. Именование обычно выражается одним глаголом в изъявительном наклонении настоящего времени: «Имеет», «Принадлежит» и т. д.; или глаголом с поясняющими словами: «Включает в себя», и т.п. Наименование может быть одно для всей связи или два для каждого из концов связи. Во втором случае, название левого конца связи указывается над линией связи, а правого – под линией. Каждое из названий располагаются рядом с сущностью, к которой оно относится.

Атрибуты сущности записываются внутри прямоугольника, изображающего сущность и выражаются существительным в единственном числе (возможно, с уточняющими словами). Среди атрибутов выделяется ключ сущности — неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности

Создать таблицу дисциплин и успеваемости

Disc (kod_d; name_d; mark; date1)

E -R диаграмма

USP

Disc

Create table

(kod_d int primary key, name_d var char (30) )

Create table USP

N char (n) constaintogrk Foreign key references Stud (n) on Update cascade on delete kod_d Foreign key references Disc (kod_d) on Update cascade, on delete mark var char (1) date1 date time)

6. Этапы проектирования баз данных.

При разработке БД можно выделить следующие этапы работы.

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

II этап. Анализ объекта. На этом этапе рассматривается, из каких объектов может состоять БД, каковы свойства этих объектов. После разбиения БД на отдельные объекты необходимо рассмотреть свойства каждого из этих объектов, или, другими словами, установить, какими параметрами описывается каждый объект. Все эти сведения можно располагать в виде отдельных записей и таблиц. Далее необходимо рассмотреть тип данных каждой отдельной единицы записи. Сведения о типах данных также следует занести в составляемую таблицу.

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

IV этап. Выбор способов представления информации и программного инструментария.После создания модели необходимо, в зависимости от выбранного программного продукта, определить форму представления информации. В большинстве СУБД данные можно хранить в двух видах: с использованием форм; без использования форм. Форма – это созданный пользователем графический интерфейс для ввода данных в базу.

V этап. Синтез компьютерной модели объекта.В процессе создания компьютерной модели можно выделить некоторые стадии, типичные для любой СУБД. Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы. Стадия 2. Создание исходной таблицы или таблиц. Создавая исходную таблицу, необходимо указать имя и тип каждого поля. Имена полей не должны повторяться внутри одной таблицы. В процессе работы с БД можно дополнять таблицу новыми полями. Созданную таблицу необходимо сохранить, дав ей имя, уникальное в пределах создаваемой базы. Стадия 3. Создание экранных форм. Стадия 4. Заполнение БД. Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE – в виде формы.

VI этап. Работа с созданной базой данных..Работа с БД включает в себя следующие действия: поиск необходимых сведений; сортировка данных; отбор данных; вывод на печать; изменение и дополнение данных.

7. Архитектура (общая схема) систем баз данных.

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

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

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

Архитектурные уровни. Поскольку  в системах баз данных имеют дело с иерархией  абстракций данных,  уместно говорить об уровнях абстракции. Различным  уровням абстаркции данных соответствуют в системе базы данных  различные уровни информационной архитектуры. Поддержка каждого дополнительного уровня абстракции  данных  в системе требует наличия в СУБД специальных механизмов и существенно усложняет  ее  реализацию  и  эксплуатацию,  оказывает  влияние  на производительность  системы. Однако такой шаг диктуется  достаточно серьезными  мотивами. Он позволяет, как уже говорилось,  обеспечить адекватные   способы  видения  базы  данных  для  различных   групп персонала    и         пользователей  системы,   создать   инструментарий, эффективно  удовлетворяющий их потребности, выраженные  в  терминах естественного  для  них  представления  базы  данных.  Кроме  того, появляется  возможность  изменять некоторые  характеристики  одного представления  базы данных, не затрагивая характеристик  других  ее представлений, т.е. обеспечить независимость данных. С  каждым  уровнем  информационной  архитектуры  системы  базы данных   связана  некоторая  модель  данных,  в  терминах   которой обеспечивается  представление  данных  на  этом  уровне.   Языковые средства  этой  модели, если они представляются разработчиком  СУБД пользователям  и   системному  персоналу,  позволяют   настраивать механизмы  данного  архитектурного  уровня  СУБД  и  управлять   их функционированием. В частности, язык определения  данных  позволяет определять представление базы данных, ассоциируемое с этим  уровнем архитектуры,  а  операторы  языка  манипулирования  данными   дают возможность  выполнять  различные  операции  над  элементами  этого представления.

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

Реляционная модель данных. Иерархическая модель данных. Сетевая модель данных. Структуры хранения. Понятие метода доступа.

СУБД основывается на использовании трёх моделей:

• Сетевой;

У потомков несколько предков и наоборот.

Достоинства:

1. Быстрый поиск записей, относящихся к определённому объекту.

Недостатки:

4. Сложная структура;

5. Тяжёлое восприятие;

6. Физическая связь.

• Иерархической;

К основным понятиям иерархической структуры относятся: уровень, элемент, связь. Узел – это совокупность атрибутов данных описывающих некоторый объект. Каждый потомок имеет только одного предка. Только одна вершина – корень.

Достоинства:

3. Удобство использования иерархических данных;

4. Эффективное использование памяти компьютера.

Недостатки:

1. Жёсткая, громоздкая структура;

2. Записи связаны физически (корректировка не только данных, но и указателей);

3. Нужна мощная машина.