Слияние ллмд в глмд (фаза 1).

Процедуру слияния можно считать самой важной в ходе логического проектирования, поскольку с ее помощью(т.е. с помощью ГЛМД) создается представление обо всей ПО, независящие от любых конкретных пользователей.

На этом подэтапе в наиболее полном варианте представляются следующие действия.

1. анализ имен сущностей и их первичных ключей.

2. анализ имен связей.

3. слияние общих сущностей из разных ЛЛМД, если таковые есть.

4. включение (без слияния) в ГЛМД сущностей уникальных для каждой ЛЛМД.

5. слияние общих связей из различных ЛЛМД, если таковые выявлены при анализе.

6. включение без слияния в ГЛМД связей уникальных для каждой ЛЛМД.

7. проверка на наличие пропущенных сущностей или связей.

8. проверка соблюдения ограничения целостности данных.

9. выполнение чертежа ГЛМД.

Рассмотрим некоторые из этих действий.

При объединении ЛЛМД в ГЛМД возможны следующие подходы

1. слияние друг с другом сразу всех ЛЛМД

2. слияние 2-х ЛЛМД в одну общую с последующим добавлением к ней 3-й ЛЛМД пока не будет получена ГЛМД

3. попарное последовательное слияние ЛЛМД в ГЛМД (наиболее распространенный вариант).

 

Рис. 3.4.3.1.

При объединении ЛЛМД используется 3 основных концепции

1. выявление идентичных конструкций

2. агрегация

3. обобщение

1. Выявление идентичных конструкций дает возможность уменьшить количества элементов в ГЛМД. При этом считается, что 2 или более элементов модели идентичны, если они имеют одинаковое смысловое значение.

При объединении необходимо выявить в таких элементах одинаковые по смыслу но разные по названию атрибуты и установить им одинаковые названия.

Например, в ЮРГТУ есть факультеты и колледж. В колледже выявлена сущность «Ученик колледжа», на факультете «студент университета». Эти два элемента(сущности) могут быть объединены в одну «студент образовательного учреждения».

Рис. 3.4.3.2

1. Агрегация. Реализация этой концепции позволяет рассматривать связь между элементами(сущностями) как новый элемент(сущность).

Пример 6. В ЛЛМД имеют место две сущности «Студент» и «Преподаватель». Поскольку между этими сущностями имеется связь, то используя концепцию агрегирования эту связь можно отразить путём введения новой сущности «экзамен».

Рис. 3.4.3.3

2. Обобщение позволяет трактовать классы различных типов объектов(сущностей) в различных ЛЛМД как один поименованный обобщенный тип объекта.

Пример. В ЛЛМД имеют место сущности «Процессор компьютера» и «Запоминающее устройство». Они могут быть представлены в ГЛМД как обобщенный тип объектов (обобщенная сущность) – «компоненты компьютера».

Рис. 3.4.3.4

Проверка ГЛМД (фаза 2).

Цель этой фазы состоит в том, чтобы после завершения объединения опробировать (проверить) ГЛМД как в отношении правил нормализации, так и в отношении возможности выполнения транзакций, имеющих место в функциях отдельных полей.

Такая проверка выполняется с использованием тех же методов, которые применяются и при проверке ЛЛМД. Однако проведение нормализации отношений требуется только в том случае, если в процессе объединения ЛЛМД были внесены изменения в состав и свойства отдельных типов сущностей.

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

 

3.4.3.3, Создание окончательного варианта глобальной диаграмы Сущность-Связь (ГЛМД) (фаза 3).

Цель этой фазы – создание окончательного варианта ER-Диаграммы, отображающей всю предметную область в виде ГЛМД. Эта фаза может быть выполнена после проверки созданной ГЛМД. В результате этой фазы создается документация (ER-Д, схемы отношений, словарь данных), которая отражает всю ПО и в которой согласованы и устранены все противоречия, возможные и выявленные при объединении ЛЛМД.

 

 

ТЕМА 4.Модель данных. Реляционная модель данных.

 

Модель данных общие понятия

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

Общее описание базы данных на соответствующем уровне представления абстрагирования называют схемой базы данных. То есть для описания схемы базы данных на соответствующем уровне представления используется модель данных.

Определение1. Модель данных-это интегрированный набор правил для описания:

1. Самих данных;

2. Связей между ними;

3. Ограничений накладываемых на данные в данной предметной области.

Определение: Модель данный это инструментарий, позволяющий отображать предметную область, на определенный уровень представления (абстрагирования).

Важно различать:

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

В рамках 3-х уровневой архитектуры базы данных, обычно выделяются 3(три) взаимосвязанные модели данных:

- Инфологические модели

- Датологические модели

-физические модели

Упрощенно соответствие разных моделей, этапов проектирования и уровней представления представлены на рис 4.1

Рис 4.1.1.

Инфологические модели (СКИМ) используются на этапе концептуального проектирования. Они позволяют описывать ПО в удобной и естественной для разработчиков форме на внешнем уровне и концептуальном уровне представления.

 

Датологические модели - используются на этапе логического проектирования, а также на 1-ом этапе физического проектирования. Эти модели позволяют на основе КИМ создавать описание ПО с учетом ТИПА СУБД, предполагаемой для использования в АИС.

 

Физические модели используются на 2-м этапе физического проектирования. ФМД оперирует категориями, касающимися организации внешней памяти. Эти модели позволяют создавать описание ПО в виде компьютерных структур хранения данных во внешней памяти компьютера (структуры записей, их упорядоченность, методы доступа к записям и т.д.).

 

 

На рис 4.2 Представлена классификация разновидностей этих 3- типов модели

 

 

 

4.1.2 Классификация моделей данных

 

РМД предложена сотрудниками фирмы IBM Эдгаром Коддом и основывается на понятии ОТНОШЕНИЕ (relation).

Определение: Отношение представляет собой множество кортежей, каждый из которых описывает экземпляр сущности и их связи и состоит из элементов (Элементы соответствуют атрибутам отношения).

Наглядной формой представления отношения является двумерная таблица.

Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам - атрибуты отношения. Например: таблица может содержать сведения о группе обучаемых, о каждом из которых известны следующие характеристики: Фамилия, Имя, Отчество, пол, возраст, образование. Поскольку в рамке одной таблицы не удается описать более сложные логические структуры данных о предметной области, применяют СВЯЗЫВАНИЕ таблиц (связные отношения).

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

Недостаток РМД- отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей. Примеры реляционных СУБД: (Paradox (Borland). FOXPRO, Visual FOXPRO, ACCES (Microsoft). Oracle (oracle). Ingress и т.д.)