Главная страница Случайная страница
Разделы сайта
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
Информационные объекты
|
|
Информационный объект - это информационное описание некоторой сущности предметной области - реального объекта, процесса, явления или события. Информационный объект является совокупностью логически взаимосвязанных реквизитов, представляющих качественные и количественные характеристики сущности. Примерами сущностей являются - товар, поставщик, заказчик, поставка, отгрузка, сотрудник, отдел, студент, преподаватель, кафедра и т.п.
Информационный объект имеет множество реализаций – экземпляров объекта. Например, каждый экземпляр информационного объектаТОВАР содержит значения реквизитов по товару определенного наименования. Экземпляр объектадолжен однозначно определяться среди всего множества экземпляров, то есть идентифицироваться значением уникального (первичного) ключа информационного объекта. Уникальность ключа означает, что любое значение ключа не может повториться в каком либо другом экземпляре объекта. Простой ключ состоит из одного реквизита. Составной ключ – из нескольких реквизитов. Таким образом, реквизиты информационного объекта подразделяются на ключевые и описательные, которые являются функционально зависимыми от ключа.
Функциональные зависимости реквизитов предметной области (документов)
Информационные объекты могут быть выделены на основе описания предметной области путем определения функциональных зависимостей между реквизитами предметной области. Функциональная зависимость реквизитов информационного объекта устанавливает соответствие значений ключевых (определяющих) и неключевых (определяемых) реквизитов.
Необходимость установления функциональных зависимостей связанно с требованием баз данных по однозначной определяемости любого данного для его размещения и доступа к нему. Например, для однозначной и полной определяемости реквизита Количество в поставке товара нужно указать что поставляется, то есть товар (его идентификатор), нужно указать кем поставляется, то есть поставщик (его идентификатор). Если возможны поставки одного товара поставщиком в разные сроки, то нужно также указать когда осуществляется поставка, то есть срок поставки принять, как определяющий поставку. Если не будет выявлена полная функциональная зависимость, количество поставки останется не определенным однозначно.
Например, если в функциональных зависимостях количества поставки не определен срок поставки, то из нескольких поставок одного и того же товара одним и тем же поставщиком, но в разные сроки, их нельзя отличить друг от друга. В этом случае имеет место не полная идентификация поставки на этапе проектирования. Это приведет после реализации проекта к возможности загрузки в базу данных о количестве только по одной поставке (первой введенной), так как для одного значения идентификатора Код товара+Код поставщика в БД, то есть одного товара и одного поставщика, может быть введено одно значение количества поставляемого. Наглядная иллюстрация этой ситуации, когда срок поставки не указан как определяющий (ключевой) поставку представлена ниже в табл.2.1
Таблица 2.1. Пример неправильной идентификации поставок товаров
| Реквизит | Код товара | Код поставщика | Срок поставки | Количество поставки | Результат в БД |
| Роль в функциональной зависимости | ключевой | ключевой | зависимый | ||
| Идентификатор поставки | |||||
| Поставка1 | Т1 | П1 | февраль | введена | |
| Поставка2 | Т1 | П1 | апрель | Не введена |
Замечание
При выявлении функциональных зависимостей реквизитов не рассматриваются арифметические зависимости (например, стоимость от количества), поскольку устанавливается только функциональная зависимость, определяющая логические связи описательных и ключевых реквизитов.
При графическом изображении модели данных каждый информационный объект представляется прямоугольником с обозначением его имени и идентификатора -ключа. Пример такого изображения для информационных объектов ТОВАР и ПОСТАВКА показан на рис.2.2. Здесь KOД_Т (код товара) - простой ключ объекта ТОВАР, а KOДT+ KПОСТ (код поставщика)+СРОКП (срок поставки) - составной ключ объекта ПОСТАВКА.
Рис.2.2. Пример графического изображения информационных
объектов с простым и составным ключом
Требованиянормализации ИО
Реквизиты каждого информационного объекта канонической модели данных должны отвечать требованиям, соответствующим третьей нормальной форме реляционной модели данных:
r информационный объект должен содержать уникальныйидентификатор - ключ;
r все описательные реквизиты должны быть взаимонезависимы, т.е. между ними не должно быть функциональных зависимостей;
r все реквизиты, входящие в составной ключ, также должны быть взаимонезависимы;
r каждый описательный реквизит должен функционально-полно зависеть от ключа, то есть каждому значению ключа должно соответствовать только одно значение описательного реквизита, а при составном ключе описательные реквизиты должны зависеть целиком от всей совокупности реквизитов, образующих ключ;
r каждый описательный реквизит должен зависеть от ключа нетранзитивно, т.е. не должен зависеть через другой промежуточный реквизит.
Замечание
В случае транзитивной зависимости между реквизитами информационного объекта можно выполнить расщепление совокупности реквизитов с образованием двух информационных объектов вместо одного.
Выполнение требований нормализации обеспечивает построение канонической модели данных и на ее основе создание реляционной базы данных без дублирования описательных данных, а также возможность автоматического поддержания связной целостности данных средствами СУБД при обновлении базы данных – добавлении и удалении записей, изменении значений в ключевых полях.
|
|