17. Сравнение моделей данных. Достоинства и недостатки реляционной, сетевой и иерархической моделей данных.
Семантические модели данных представляют собой средство описания структуры предметной области.
Семантические модели должны отвечать следующим требованиям:
- обеспечить интегрированное представление о предметной области;
- понятийный аппарат модели должен быть понятен как специалисту предметной области, так и администратору БД;
- модель должна содержать информацию, достаточную для дальнейшего проектирования ЭИС.
При сравнении моделей данных трудно отделить факторы, характеризующие принципиальные особенности моделей, от факторов связанных с реализацией этих моделей данных средствами конкретных СУБД.
Преимущества реляционного подхода:
2. Теоретическое обоснования.
3. Независимость данных когда необходимо изменить структуру реляционной БД.
Недостатки реляционной модели данных:
1. Низкая скорость при выполнении операции соединения
2. Большой расход памяти для предоставления реляционной БД.
Достоинства иерархической моделей данных:
2. Минимальный расход памяти.
Недостатки иерархической модели:
2. Допустимость только навигационного принципа доступна к данным.
Преимущества сетевой модели данных:
2. Возможность доступа к данным через значения нескольких отношений.
Недостатки сетевой модели данных можно назвать:
1. Обилие понятий вариантов их взаимосвязей и особенностей реализации.
2. Допустимость только навигационного принципа доступа к данным.
При анализе моделей данных не затрагивалась проблема упорядоченности значений в отношениях БД. Для реляционных модели данных это упорядоченность с теоретической точки зрения необязательно, а в двух других моделях она широко используется для повышения эффективности реализации вопросов.
На окончательный выбор модели данных влияют многие дополнительные факторы, например наличие, хорошо зарекомендовавших себя СУБД квалификация прикладных программистов размер БД и другие.
18. Семантические модели данных. Модель «сущность-связь».
Семантические модели данных представляют собой средство описания структуры предметной области.
Семантические модели должны отвечать следующим требованиям:
- обеспечить интегрированное представление о предметной области;
- понятийный аппарат модели должен быть понятен как специалисту предметной области, так и администратору БД;
- модель должна содержать информацию, достаточную для дальнейшего проектирования ЭИС.
Базовыми элементами в модели «сущность-связь» служат типы сущностей, обозначаемые далее прямоугольниками, и типы связей, обозначаемые двойными прямоугольниками. Многие сущности, рассматриваемые в этой модели, соответствуют физическим объектам предметной области.
В структуре связей объектов допускаются следующие типы связей:
• N-арные связи, приводится пример тернарной связи;
11. Иерархическая, сетевая, реляционная и другие модели данных.
Модель данных — это совокупность структур данных и операций их обработки. Рассмотрим три основных типа моделей данных: иерархическую, сетевую и реляционную.
Иерархическая модель представляет собой совокупность элементов, расположенных в порядке их подчинения от общего к частному и образующих перевернутое по структуре дерево (граф).
К основным понятиям иерархической структуры относятся уровень, узел и связь. Узел — это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину, не подчиненную никакой другой вершине и находящуюся на самом верхнем — первом уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т. д. уровнях. Количество деревьев в базе данных определяется числом корневых записей. К каждой записи базы данных существует только один иерархический путь от корневой записи.
В сетевой структуре при тех же основных понятиях (уровень, узел, связь) каждый элемент может быть связан с любым другим элементом.
Реляционная модель данных объекты и связи между ними представляет в виде таблиц, при этом связи тоже рассматриваются как объекты. Все строки, составляющие таблицу в реляционной базе данных, должны иметь первичный ключ. Все современные средства СУБД поддерживают реляционную модель данных.
Эта модель характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных.
Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
1. Каждый элемент таблицы соответствует одному элементу данных.
2. Все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип и длину.
3. Каждый столбец имеет уникальное имя.
4. Одинаковые строки в таблице отсутствуют;
5. Порядок следования строк и столбцов может быть произвольным.
Постреляционные модели данных:
Сегодня постреляционные модели данных представлены двумя основными моделями данных: объектно–ориентированной и объектно–реляционной.
Объектно-ориентированная модель изначально строилась с учетом ее эволюции и расширения. Эта модель базируется на основных понятиях и методах, разработанных в объектно-ориентированном програмировании (ОПП) и представленных в широко используемых языках объектно-ориентированного программирования, таких как С++, Java и др..
В объектно-реляционных СУБД (ОРСУБД) используется базовая реляционная модель данных. ОРСУБД являются постепенным развитием предшествующих им реляционным СУБД. В отличие от ООСУБД переход к ОРСУБД не требует массового перепрограммирования. Основной язык объектно-ориентированных БД SQL3.
12.Определение реляционной модели.
Реляционная модель данных (РМД) — логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики, как теория множеств и логика первого порядка.
На реляционной модели данных строятся реляционные базы данных.
Реляционная модель данных включает следующие компоненты:
Структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений.
Аспект (составляющая) целостности — отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.
Аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).
Кроме того, в состав реляционной модели данных включают теорию нормализации.
Реляционная модель данных объекты и связи между ними представляет в виде таблиц, при этом связи тоже рассматриваются как объекты. Все строки, составляющие таблицу в реляционной базе данных, должны иметь первичный ключ. Все современные средства СУБД поддерживают реляционную модель данных.
Эта модель характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных.
Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
1. Каждый элемент таблицы соответствует одному элементу данных.
2. Все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип и длину.
3. Каждый столбец имеет уникальное имя.
4. Одинаковые строки в таблице отсутствуют;
5. Порядок следования строк и столбцов может быть произвольным.
13. Основные понятия реляционной модели данных (отношение, атрибут, кортеж, тип данных, домен, первичный ключ, внешний ключ, типы связей, целостность данных).
Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных БД допускается хранение:
специализированных числовых данных (таких как «деньги»),
а также специальных «темпоральных» данных (дата, время, временной интервал).
Важно! Реляционная модель требует, чтобы типы используемых данных были простыми (атомарными).
Собственно, для реляционной модели данных тип используемых данных не важен. Требование, чтобы тип данных был простым, нужно понимать так, что в реляционных операциях не должна учитываться внутренняя структура данных. Конечно, должны быть описаны действия, которые можно производить с данными как с единым целым, например, данные числового типа можно складывать, для строк возможна операция конкатенации и т.д.
Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа. Например, можно ввести домен «цвет». Для предметной области «Правила перехода улицы» домен «цвет» будет принимать значения: «красный», «желтый», «зеленый». Никакие другие значения для данного домена СУБД не пропустит.
Домен – это диапазон значений, которые может принимать атрибут. Домен может быть задан перечислением возможных значений либо в абстрактном виде. Домен характеризуется следующими свойствами:
Домен имеет уникальное имя (в пределах базы данных).
Домен может иметь некоторое логическое условие, позволяющее описать подмножество данных, допустимых для данного домена.
Домен несет определенную смысловую нагрузку.
характеристика, определяющая свойства данного класса объектов и позволяющая однозначно идентифицировать объект и отличить его от других.
Кортеж, соответствующий данной схеме отношения, — это множество пар , которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. «Значение» является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Попросту говоря, кортеж — это набор именованных значений заданного типа.
Отношение — это множество кортежей, соответствующих одной схеме отношения. На самом деле, понятие схемы отношения ближе всего к понятию структурного типа данных в языках программирования.
Первичный ключ(PRIMARY KEY) — уникальный идентификатор записей таблицы.
Один или несколько столбцов, используемые для идентификации каждой строки и обеспечивающие различимость строк.
Однозначно определяет значения остальных атрибутов отношения, не входящих в состав первичного ключа.
Содержит минимально необходимое для идентификации записи множество атрибутов .
В качестве первичного ключа рекомендуется выбирать поля типа «длинное целое» .
Если первичный ключ подобрать сложно, рекомендуется создавать искусственный идентификатор в виде поля «длинное целое» и заполнять его уникальными значениями, кодирующими записи исходной таблицы.
Внешний ключ(FOREIGN KEY ) – поле таблицы, предназначенное для хранения значенияпервичного ключадругой таблицы с целью организации связи между этими таблицами.
Значения атрибутов, входящих в исходную и связанную таблицы, должны совпадать для связанных записей.
Наименования связанных полей совпадать не обязаны.
Внешний ключ – это атрибут (или несколько атрибутов) одного отношения, являющиеся ключом другого отношения.
Типы связей между отношениями. При установлении связи между двумя отношениями одно из них будет являтьсяглавным, а второе – подчиненным.
Различают четыре типа связей:
· Один к одному – каждому кортежу одного отношения соответствует один кортеж другого отношения;
· Один ко многим – каждому кортежу главного отношения может соответствовать несколько кортежей подчиненного отношения;
· Многие к одному – нескольким кортежам главного отношения может соответствовать один кортеж подчиненного отношения;
· Многие ко многим – один кортеж главного отношения связан с несколькими кортежами подчиненного отношения, а один кортеж подчиненного отношения связан с несколькими кортежами главного отношения.
В таблице нет двух одинаковых строк;
Таблица имеет столбцы, соответствующие атрибутам отношения;
Каждый атрибут в отношении имеет уникальное имя;
Порядок следования столбцов (атрибутов) в отношении не имеет значения;
При изменении содержимого базы данных с помощью инструкций INSERT, DELETE или UPDATE может произойти нарушение целостности содержащихся в ней данных:
– в базу могут быть внесены неправильные данные, например, заказ, в котором указан несуществующий товар;
– в результате изменения имеющихся данных им могут быть присвоены некорректные значения, например, назначение служащего в несуществующий офис;
– изменения, внесенные в базу данных, могут быть утеряны из-за системной ошибки или сбоя в электропитании;
– изменения, внесенные в базу данных, могут быть внесены лишь частично, например, заказ может быть добавлен без учета изменения количества товара, имеющегося на складе