Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Тема1-3.doc
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
257.54 Кб
Скачать

Тема 3 Информационное моделирование.

  1. Понятие информационной модели. Уровни описания

  2. Классификация связей между информационными единицами.

  3. Типы информационных моделей.

  4. Реляционные модели.

  5. Понятие нормализации реляционной базы данных

  6. Обьектно-реляционный подход к проектированию базы данных

1

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

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

  • внешний уровень;

  • концептуальный уровень;

  • физический уровень.

В общем виде все перечисленные уровни можно представить в виде следующей схемы.

В Н.мод1 Вн.мод2 Вн.мод3 . . . Вн.модN

Концептуальная модель

Модель реализации

Физическая модель

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

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

На концептуальном уровне выполняется описание информационной модели с точки зрения администратора данных. Концептуальная схема представляет собой набор всей информации БД. Она включает диаграмму “Сущность-связь” и блок диаграмм информационных потоков.

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

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

2

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

1. "один к одному" (1:1) Одному элементу исходного множества соответствует один и только один элемент целевого множества. Пример: одной записи таблицы "Счета" соответствует одна запись "остатки на счетах"

2. "Один ко многим" (1:N) Одному элементу исходного множества соответствует несколько элементов целевого множества. Пример: одной записи в таблице "Счета" соответствует несколько записей в таблице "Операции на счетах"

3. "многие к одному" (N:1) Нескольким элементам исходного множества соответствует один элемент целевого множества

4. " многие к многому" (N:M) Произвольному числу элементов исходного множества может соответствовать произвольное число элементов целевого множества. Пример: Таблица "Поставщики" связана с таблицей "Товары" по этому принципу, так как любой поставщик может поставлять произвольную номенклатуру товаров, а любой товар в свою очередь может поставляться любым поставщиком.

Связи подразделяются на ассоциации и отображения. Отображение – это сильный тип связи, связь обязательна и имеет два направления, изображается в виде , ассоциация – слабый тип связи, связь необязательна , изображается в виде 

Согласно вышеприведенной классификации связей можно определить следующие типы информ. моделей:

иерархическая;

сетевая;

реляционная.

В последнее время появилось понятие объектно-реляционной модели данных.

  • Иерархической называется модель связи между элементами, которая построена по принципу 1:1 или 1:N. Данная модель состоит из подчиненных звеньев, связи между которыми реализуются через специальные ссылки-указатели.

  • Сетевой называют модель в которой допускается любой тип связи. Данный тип модели используется в глобальных компьютерных сетях. В частности в службе WWW Интернета.

4.

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

Таблица отношений ( в дальнейшем таблица) имеет следующие важные ограничения:

В таблице не должно быть идентичных записей

Порядок следования столбцов и записей не имеет значения

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

Данные условия позволяют максимально упростить структуру таблицы и как следствие упростить ее обработку. Более того для обработки данных представленных в виде отношений был разработан специальный язык SQL (язык структурных запросов).

Каждая таблица отношений имеет следующие атрибуты:

имя таблицы, служит для идентификации таблицы в БД;

тип таблицы, определяется набором и атрибутами столбцов;

кардинальное число, максимально возможное число записей в таблице.

Каждый столбец таблицы имеет следующие атрибуты:

имя столбца;

тип столбца (текстовый, числовой, дата/время, логический);

дополнительные свойства столбца (длина, формат отображения данных, наличие индекса - специальный метод доступа);

домен столбца ( область определения значений для столбца);

5.

Целью нормализации таблицы в реляционной модели является приведение таблиц к виду исключающему дублирование информации и обеспечивающей целостность и непротиворечивость информации в БД.

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

В настоящее время имеют место следующие виды нормальных форм:

Первая нормальная форма (1НФ)

Вторая нормальная форма (2НФ)

Третья нормальная форма (3НФ)

Нормальная форма Бойса-Кодда (БКНФ)

Четвертая нормальная форма (4НФ)

Пятая нормальная форма (5НФ)

Каждая более старшая нормальная форма накладывает ряд дополнительных ограничений на базу данных. На практике 4НФ и 5 НФ используются очень редко. Сформулируем требования первых трех нормальных форм.

1 НФ. Таблица находятся в первой нормальної форме, если в ней отсутствуют повторяющиеся записи и повторяющиеся группы полей.

2 НФ. Таблица находится во второй нормальной форме, если она удовлетворяет условиям 1 НФ й любой неключевой реквизит в каждой запи­си однозначно определяется полным набором ключевых реквизитов.

3 НФ. Таблица находится в третьей нормальной форме, если она удовлетворяет условиям 2 НФ й любой неключевой реквизит в каждой запи­си не определяется однозначно другим неключевым реквизитом.

Задача

Торговая фирма осуществляет оптовые поставки продуктов магазинам и предприятиям общественного питания. Заказы оформляются посредством выписки счетов-фактур. Разработать структуру информационной базы для выписки и ведения счетов-фактур покупателей

Рассмотрим структуру опорной таблицы "Счета"

  1. Номер счета-фактуры

  2. Дата выписки

  3. Код покупателя

  4. Наименование покупателя

  5. Юридический адрес покупателя

  6. Код ОКПО

  7. Расчетный счет покупателя

  8. МФО отделения банка покупателя

  9. Наименование отделения банка покупателя

  10. Номер контактного телефона

  11. Номер позиции

  12. Код товара

  13. Наименование товара

  14. Единицы измерения

  15. Цена за единицу

  16. Количество

  17. Сумма

  18. Итоговая сумма по счету

  19. Признак оплаты.

Реквизиты в документе можно разделить на следующие группы:

Информация о документе (1,2,18)

Инф. О покупателе: (4,5,6,7,8,10)

Инф. О заказанном товаре: (13,14,15,16,17)

Кроме того, для обеспечения эффективности обработки данных включены следующие служебные реквизиты: (3,12,19)

Реквизиты опорной супертаблицы представляют собой набор столбцов таблицы в которые будет заноситься фактическая информация. Отдельный счет-фактура представляет собой запись в этой таблице. Таблица является немормализованной, так как в ней имеются группы полей, имеющие в разных записях одинаковые значения. В частности, если счет-фактура содержит несколько позиций по товарам, то общие реквизиты по счету (1,2,3,4,5,6,7,8,9,18,19) в соответствующих записях будут сдублированы.

Для устранения повторяющихся групп полей выполним первый шаг нормализации путем разбиения исходной таблицы на две “Счета” и “Позиции”

Структура таблицы “Счета” находящейся в 1НФ

  1. *Номер счета-фактуры

  2. *Дата выписки

  3. *Код покупателя

  4. Наименование покупателя

  5. Юридический адрес покупателя

  6. Код ОКПО

  7. Расчетный счет покупателя

  8. МФО отделения банка покупателя

  9. Наименование отделения банка покупателя

  10. Номер контактного телефона

  11. Итоговая сумма по счету

  12. Признак оплаты.

*- возможный ключ. Идентифицировать запись в т.”Счета” можно при помощи реквизита 1 либо при помощи составного ключа 2 + 3

Структура таблицы «Позиции» находящейся в 1НФ

  1. *Номер счета-фактуры

  2. *Номер позиции

  3. *Код товара

  4. Наименование товара

  5. Единицы измерения

  6. Цена за единицу

  7. Количество

  8. Сумма

Таблица имеет два возможных составных ключа 1 + 2 и 1 + 3

Приведенные таблицы не удовлетворяют условиям 2 НФ, так как они содержат реквизиты, однозначно определяемые реквизитами, входящими в сос тавной ключ. Так, в таблице "Счета" реквизиты 4,5,6,7,8,9,10 однозначно определяется реквизитом "Код покупателя", который является частью составного ключа. Аналогично, таблица "Позиции" содержит реквизиты 4,5,6 также однозначно определяемые реквизитом "Код товара", являющегося частью возможного составного ключа.

Для приведения таблиц во вторую нормальную форму необходимо выполнить их разбиение на более мелкие составляющие. Таблица "Счета разбивается на "Счета" й "Покупатели", а таблица "Позиции" на "Позиции" и "Товары”

Структура таблицы” Счета” находящейся во 2 НФ

  1. *Номер счета-фактуры

  2. *Дата выписки

  3. *Код покупателя

  4. Итоговая сумма по счету

  5. Признак оплаты.

Структура таблицы "Покупатели", находящаяся во 2 НФ

*Код покупателя

  1. Наименование покупателя

  2. Юридический адрес покупателя

  3. Код ОКПО

  4. Расчетный счет покупателя

  5. МФО отделения банка покупателя

  6. Наименование отделения банка покупателя

  7. Номер контактного телефона

Структура таблицы "Позиции" находящейся во 2НФ

  1. *Номер счета-фактуры

  2. *Номер позиции

  3. *Код товара

  4. Количество

  5. Сумма

Структура таблицы “Товары” находящейся во 2НФ

  1. *Код товара

  2. Наименование товара

  3. Единицы измерения

  4. Цена за единицу

Таблицы “Счета” ,”Позиции” и “Товары” удовлетворяют также и условиям 3НФ, так как не содержат неключевых реквизитов, определяемых другими неключевыми реквизитами. В таблице "Покупатели" такая зависимость есть – неключевой реквизит "Наименование отделения банка покупателя” определяется другим неключевым реквизитом “МФО банка покупателя”.

Для приведения этой таблицы в 3НФ необходимо выполнить ее разбиение на таблицы “Покупатели” и “Банки”

Структура таблицы “Покупатели” в 3 НФ

  1. *Код покупателя

  2. Наименование покупателя

  3. Юридический адрес покупателя

  4. Код ОКПО

  5. Расчетный счет покупателя

  6. МФО отделения банка покупателя

  7. Номер контактного телефона

Структура таблицы “Банки” в 3 НФ

  1. *МФО отделения банка покупателя

  2. Наименование отделения банка покупателя

Таким образом опорная ненормализованная таблица разбита на пять таблиц, каждая из которых находится в З НФ. Полученную структуру базы данных можно представить в виде диаграммы 'Сущность - связь"

Условные обозначения, используемые при построении диаграммы "Сущность – связь”

------------ - связь - отображeние

--------------- - связь - ассоциация

<—————>> тип связи 0дин – ко многим

<<—————> тип связи Многие к одному

<———-——> тип связи 0дин – к одному

* - ключевой реквизит

- Таблица

Диаграмма "Сущность- связь"

Счета Позиции

* Номер счета-фактуры ► *Номер счета-фактуры

*Дата выписки *Номер позиции

* Код покупателя ◄ *Код товара

Итоговая сумма по счету Количество

Признак оплаты. Сумма

Покупатели Товары

*Код покупателя * Код товара

Н аименование Наименование

Юридический адрес Единицы измерения

К од ОКПО Цена за единицу

Р асчетный счет

МФО отделения банка

Номер телефона

Банки

*МФО отд банка

Наименование отд

Связь Счета - Позиции является отображением, так как она двунаправлена и обязательна , т, е. Если существует счет, то существует и спецификация заказанных товаров по счету и наоборот. Эта связь имеет тип "Один – ко многим” так как в одном счете может быть заказано несколько товаров.

Связь Счета - Покупатели является отображением. Двунаправленность этой связи характеризуется тем, что если покупатель хотя бы один раз заказал товар, он заносится б таблицу "Покупатели". Тип связи "Многие к одному” характеризуется тем, что несколько счетов-фактур таблицы “Счета” могут соответствовать одному покупателю.

Связь “Позиции-Товары” является ассоциацией так как в таблице "Товары” могут быть занесены товары,. Которые еще не были заказаны.

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

6

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

Данная проблема пока не имеет четкой теоретической основы, однако многие фирмы разработчики СУБД внедряют элементы объектного подхода при создании СУБД нового поколения.

Объектный подход к разработке программ имеет несколько базовых понятий:

объект - объект реального метода над которым выполняется обработка информации;

класс объекта - совокупность свойств, которыми обладает объект;

методы - операции которые допустимы при обработке данного объекта.

Пример: при обработке объекта "сотрудник" можно описать класс

(совокупность столбцов описания свойств сотрудников). Для обработки объекта "сотрудники" можно сформулировать несколько методов:

нанять сотрудника;

уволить сотрудника;

наградить сотрудника;

В настоящее время имеется несколько СУБД, в которых частично реализовано понятие объектной модели.

Пример: В СУБД Access имеется несколько типов объектов:

объект типа таблица; запрос; форма; отчет; модуль; макрос .

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]