СОДЕРЖАНИЕ
|
1. Задание……………………………………………………………….……..
2. Сущности и атрибуты
разрабатываемых моделей………………………….
3. Проектирование инфологической
модели…………………………………
4. Проектирование даталогической
модели………………………………..
5. Проектирование физической
модели………………………………………..
6. Заключение……………………………………………………………………...
|
..2
..3
..5
..9
11
14
|
1. Задание
Разработать инфологическую,
даталогическую и физическую модели данных для следующей предметной области.
Предприятие занимается производством строительных материалов различных видов.
После выпуска партии готовой продукции она передается на склад. Со склада
производится отгрузка готовой продукции покупателю. При возникновении
производственного брака производится списание готовой продукции. Если продукция
используется для производства нового изделия, ее возвращают со склада на
переработку.
При разработке моделей учитывалось следующее:
- после выпуска каждой партии готовой
продукции, необходимо зарегистрировать этот факт. При этом необходимо
зафиксировать: дату производства партии продукции, номер партии, наименование
продукции, количество, единицу измерения.
- при возникновении производственного
брака, оформляется списание готовой продукции, при котором фиксируется: дата
списания, наименование списываемой готовой продукции, количество, единица
измерения, номер партии.
- отпуск изделий из цеха на склад готовой продукции
представляет собой передачу партии готовой продукции на склад готовой продукции
для последующей реализации. При этом фиксируется: дата отпуска, наименование
продукции, производственное подразделение, количество, единица измерения, номер
партии.
Возврат готовой продукции на переработку производится в случае
использования данной продукции при производстве нового изделия. При этом фиксируется:
дата отпуска, наименование продукции (материалов), получатель (производственное
подразделение), количество.
2. Сущности и атрибуты разрабатываемых моделей
Задачи работы представляют собой разработку инфологической
модели информационной БД, трансформацию ее в даталогическую ER-модель,
физическую реализацию ER-модели в виде базы данных.
Цель инфологического моделирования - обеспечение наиболее
естественных для человека способов сбора и представления той информации,
которую предполагается хранить в создаваемой базе данных. Поэтому
инфологическую модель данных пытаются строить по аналогии с естественным языком
(последний не может быть использован в чистом виде из-за сложности компьютерной
обработки текстов и неоднозначности любого естественного языка). Основными конструктивными
элементами инфологических моделей являются сущности, связи между ними и их
свойства (атрибуты).
Одним из перспективных направлений к решению проблемы
разработки информационных БД является использование CASE-технологий в
частности ER подход. Использование этой технологии позволило эволюционно
трансформировать иерархическую модель в даталогическую.
Объектами модели на верхних уровнях архитектуры являются
системы «сообщение» и «канал передачи» (cм. рис.1.), которые в свою очередь
можно декомпозировать на системы «информация», «сигнал», «среда передачи» и
«приемопередатчик» соответственно. Каждый объект модели характеризуется определенным
набором параметров, позволяющих проводить оценку состояния.
Модель имеет открытую архитектуру, что позволяет изменять ее
конфигурацию, детализируя те или иные уровни.
Таким образом, совокупность значений взаимосвязанных
параметров даталогической модели является состоянием системы “линия связи”.
Физическая модель, определяющая размещение данных, методы
доступа и технику индексирования, называется внутренней моделью системы.
Рисунок 1.
Внешние модели никак не связаны с типом физической памяти, в
которой будут храниться данные, и с методами доступа к этим данным. Это
положение отражает первый уровень независимости данных. С другой стороны, если
инфологическая модель способна учитывать расширение требований к системе в будущем,
то вносимые в нее изменения не должны оказывать влияния на существующие внешние
модели. Это — второй уровень независимости данных.
3. Проектирование инфологической модели
Анализ данных: сбор основных данных: объекты, связи между
объектами.
Определим первоначальные данные:
Заявки - поступающие от магазинов на определённый период.
Договора - заключаются с поставщиками на определённый вид товара.
Поставщики - организации или физические лица, с которыми заключаются
договора на поставку товара.
Заказчики - в основном магазины, а также предприятия и организации, подающие заказ
на приобретение того или иного товара.
Счета - ведутся на этапе заключения договором с поставщиками, а также с заказчиками.
Накладные - создаются на основании получения заказа о заказчика, для отгрузки.
Справки - получение/выдача различных справок как заказчику так и поставщику.
Товар - присутствует на основании заявки и договора с поставщиком.
Для каждого объекта определим свойства, которые будем хранить
в БД. При этом необходимо учитывать тот факт, что при переходе от
инфологической к физической модели данных может произойти усечение числа
объектов. На самом деле, как правило, значительное число данных, необходимых
пользователю, может быть достаточно легко подсчитано в момент вывода
информации. В то же время, в связи с изменением алгоритмов расчета или исходных
величин, некоторые расчетные показатели приходится записывать в БД, чтобы
гарантированно обеспечить фиксацию их значений. Выбор показателей, которые
обязательно следует хранить в БД, достаточно сложен. Нечасто можно найти
однозначное решение этой проблемы, и в любом случае оно потребует тщательного
изучения работы предприятия и анализа концептуальной модели.
При разработке ER-моделей мы должны получить следующую
информацию о предметной области:
1.
Список сущностей
предметной области.
2.
Список атрибутов
сущностей.
3.
Описание
взаимосвязей между сущностями.
Включив все атрибуты сущности, согласно нашего задания,
построим ER-диаграмму (рис. 2).
Рисунок 2.
Построенная R-диаграмма
является примером инфологической модели. Это означает, что диаграмма не
учитывает особенности конкретной СУБД.
Рассматривая инфологическую модель, как дающую общее
информационно-логическое представление об информации предметной области, а
также обозначенные выше исходные данные, мы предлагаем следующие свойства, включаемые
в состав БД для рассматриваемой модели (см. табл. 1).
Таблица 1.
Свойства и первичные ключи объектов инфологической
модели
|
Объект
|
Первичный ключ
|
Свойства
|
|
ТОВАР
|
Уникальный ключ товара
|
Уникальный ключ товара
|
|
|
Наименование товара
|
|
ЗАКАЗЧИК
|
Уникальный ключ заказчика
|
Уникальный ключ заказчика
|
|
|
Наименование заказчика
|
|
|
Юридическая принадлежность
|
|
|
Ф.И.О. руководителя
|
|
|
Адрес
|
|
|
Телефон/факс
|
|
|
Наименование товара
|
|
|
Количество товара
|
|
|
Предполагаемая цена
|
|
ПРЕДПРИЯТИЕ
|
Уникальный ключ поставщика
|
Уникальный ключ предприятия
|
|
|
Наименование поставщика
|
|
|
Юридическая принадлежность
|
|
|
Ф.И.О. руководителя
|
|
|
Адрес
|
|
|
Телефон/факс
|
|
|
Наименование товара
|
|
|
Количество товара
|
|
|
Дата изготовления
|
|
|
Объем товара
|
|
|
Цена за единицу
|
|
|
Суммарная цена
|
|
|
Вид упаковки
|
|
|
Способ доставки
|
|
СЧЕТА
|
Номер счёта
|
Номер счёта
|
|
|
Дата продажи
|
|
|
Наименование поставщика
|
|
|
Адрес поставщика
|
|
|
Юридическая принадлежность п.
|
|
|
Наименование заказчика
|
|
|
Адрес заказчика
|
|
|
Юридическая принадлежность з.
|
|
|
Наименование товара
|
|
|
Количество товара
|
|
|
Сумма
|
|
|
НДС
|
|
|
Сумма к оплате
|
|
ДОГОВОР
|
Номер договора
|
Номер договора
|
|
|
Дата заключения
|
|
|
Номер счёта
|
|
|
Наименование поставщика
|
|
|
Адрес поставщика
|
|
|
Юридическая принадлежность
|
|
|
Наименование товара
|
|
|
Количество товара
|
|
|
Сумма
|
|
|
НДС
|
|
НАКЛАДНЫЕ
|
Номер накладной
|
Номер накладной
|
|
|
Дата накладной
|
|
|
Пометка об оплате
|
|
|
Номер счёта
|
|
|
Наименование заказчика
|
|
|
Адрес заказчика
|
|
|
Юридическая принадлежность
|
|
|
Наименование товара
|
|
|
Количество товара
|
|
|
Сумма
|
|
|
НДС
|
|
СПИСАНИЕ БРАКА
|
Номер накладной
|
Номер накладной
|
|
|
Дата накладной
|
|
|
Пометка о списании
|
|
|
Номер счёта
|
|
|
Наименование товара
|
|
|
Количество товара
|
|
|
Сумма
|
|
|
Получатель
|
Вывод: Инфологическая модель независима от физических
параметров среды хранения данных, но важно, что, в конце концов, она должна
быть основой для построения концептуальной модели данных, которая также, как
внешняя и внутренняя, является машинно-ориентированной. Поэтому инфологическая
модель не должна изменяться до тех пор, пока какие-то правила в реальном мире
не изменятся. И самое главное, когда такое изменение произойдет (а это
неизбежно), то необходимо внести в нее соответствующие изменения, чтобы она
продолжала адекватно отражать предметную область.
Любое понятие предметной области, зафиксированное в
инфологической модели, в принципе должно быть отображено с помощью средств
концептуального уровня той СУБД, в которой реализуется проект информационной
системы.
4. Проектирование даталогической модели
Данные, представленные в виде таблицы 2, являются формой
даталогической модели данных. Образование двумерной таблицы, содержащей все
необходимые свойства информационной модели, и в выделении ключевых свойств за
счет использования технологии ER подхода позволило эволюционно трансформировать
инфологическую модель в даталогическую.
Таблица 2.
Свойства и ключи даталогической
модели
|
Объект
|
Первичный ключ
|
Свойства
|
|
ТОВАР
|
Уникальный ключ товара
|
Уникальный ключ товара
|
|
|
|
Уникальный ключ поставщика
|
|
|
|
Уникальный ключ заказчика
|
|
|
|
Наименование товара
|
|
|
|
Дата изготовления
|
|
|
|
Объем
|
|
|
|
Цена за единицу
|
|
|
|
Суммарная цена
|
|
ЗАКАЗЧИК
|
Уникальный ключ заказчика
|
Уникальный ключ заказчика
|
|
|
|
Наименование заказчика
|
|
|
|
Юридическая принадлежность
|
|
|
|
Ф.И.О. руководителя
|
|
|
|
Адрес
|
|
|
|
Телефон/факс
|
|
|
|
Предполагаемая цена
|
|
ПРЕДПРИЯТИЕ
|
Уникальный ключ предприятия
|
Уникальный ключ предприятия
|
|
|
|
Наименование предприятия
|
|
|
|
Юридическая принадлежность
|
|
|
|
Ф.И.О. руководителя
|
|
|
|
Адрес
|
|
|
|
Телефон/факс
|
|
СЧЕТА
|
Номер счёта
|
Номер счёта
|
|
|
|
Дата продажи
|
|
|
|
Уникальный ключ товара
|
|
|
|
НДС
|
|
|
|
Сумма к оплате
|
|
ДОГОВОР
|
Номер договора
|
Номер договора
|
|
|
|
Дата заключения
|
|
|
|
Уникальный ключ предприятия
|
|
НАКЛАДНЫЕ
|
Номер накладной
|
Номер накладной
|
|
|
|
Уникальный ключ заказчика
|
|
|
|
Пометка об оплате
|
|
|
|
Дата накладной
|
|
СПИСАНИЕ БРАКА
|
Номер накладной
|
Номер накладной
|
|
|
Дата накладной
|
|
|
Пометка о списании
|
|
|
Номер счёта
|
|
|
Наименование товара
|
|
|
Количество товара
|
|
|
Сумма
|
|
|
Получатель
|
|
ВОЗВРАТ СО СКЛАДА НА
ПЕРЕРАБОТКУ
|
Номер накладной
|
Номер накладной
|
|
|
Дата накладной
|
|
|
Пометка о списании
|
|
|
Номер счёта
|
|
|
Наименование товара
|
|
|
Количество товара
|
|
|
Сумма
|
|
|
Получатель
|
|
|
|
|
Приведение модели к требуемому уровню нормальной формы
является основой построения реляционной БД. В процессе нормализации элементы
данных группируются в таблицы, представляющие объекты и их взаимосвязи. Проектирование
модели основано на том, что определенный набор таблиц обладает лучшими
свойствами при включении, модификации и удалении данных, чем все остальные наборы
таблиц, с помощью которых могут быть представлены те же данные. Введение
дополнительных отношений при разработке даталогической модели обеспечивает
минимальный объем физической, то есть записанной на каком-либо носителе БД и ее
максимальное быстродействие, что впрямую отражается на качестве
функционирования информационной системы.
5. Проектирование физической модели
По построенной выше инфологической модели конструируем
физическую диаграмму (рис. 3), в которой уже будут учитываться такие
особенности СУБД, как допустимые типы и наименования полей и таблиц,
ограничения целостности и т.п.
Рисунок 3.
На данной диаграмме каждая сущность представляет собой
таблицу базы данных, каждый атрибут становится колонкой соответствующей
таблицы.
В процессе проектирования физической модели (см. табл. 3)
объекты преобразуются в отношения, свойства в поля таблиц, методы – в
процедуры, формы и т.д. Правильно проведенный объектно-ориентированный анализ
позволяет значительно облегчить работу.
Таблица 3.
Проект таблицы для физической
модели
|
№ п/п
|
Наименование поля
|
Примечание
|
|
ТОВАР
|
|
1.
|
Key_tovar
|
Уникальный ключ товара
|
|
2.
|
Key_postav
|
Уникальный ключ предприятия
|
|
3.
|
Key_zakaz
|
Уникальный ключ заказчика
|
|
4.
|
Name_tovar
|
Наименование товара
|
|
5.
|
Date
|
Дата изготовления
|
|
6.
|
Marka
|
Фирменная марка
|
|
7.
|
Ves_
|
Вес
|
|
8.
|
Ob_
|
Объем
|
|
9.
|
Cena_1
|
Цена за единицу
|
|
10.
|
Cena
|
Суммарная цена
|
|
11.
|
Upakovka
|
Вид упаковки
|
|
ЗАКАЗЧИК
|
|
1.
|
Key_zakaz
|
Уникальный ключ заказчика
|
|
2.
|
Name_zakaz
|
Наименование заказчика
|
|
3.
|
Yrid_zakaz
|
Юридическая принадлежность
|
|
4.
|
FIO_zakaz
|
Ф.И.О. руководителя
|
|
5.
|
Adres_zakaz
|
Адрес
|
|
6.
|
Tel_zakaz
|
Телефон/факс
|
|
7.
|
Cena_z
|
Предполагаемая цена
|
|
8.
|
Number_N
|
Номер накладной
|
|
9.
|
Oplata
|
Пометка об оплате
|
|
10.
|
Date_N
|
Дата накладной
|
|
ПРЕДПРИЯТИЕ
|
|
1.
|
Key_poctav
|
Уникальный ключ предприятия
|
|
2.
|
Name_postav
|
Наименование предприятия
|
|
3.
|
Yrid_poctav
|
Юридическая принадлежность
|
|
4.
|
FIO_postav
|
Ф.И.О. руководителя
|
|
5.
|
Adres_postav
|
Адрес
|
|
6.
|
Tel_postav
|
Телефон/факс
|
|
7.
|
Number_D
|
Номер договора
|
|
8.
|
Date_Z
|
Дата заключения
|
|
СЧЕТА
|
|
1.
|
Number_S
|
Номер счёта
|
|
2.
|
Date_P
|
Дата продажи
|
|
3.
|
Key_tovar
|
Уникальный ключ товара
|
|
4.
|
NDS
|
НДС
|
|
5.
|
Summa
|
Сумма к оплате
|
|
СПИСАНИЕ БРАКА
|
|
|
|
1.
|
Number_N
|
Номер накладной
|
|
2.
|
Date_N
|
Дата накладной
|
|
3.
|
Spis
|
Пометка о списании
|
|
4.
|
Number_S
|
Номер счёта
|
|
5.
|
Name_tovar
|
Наименование товара
|
|
6.
|
Ob_
|
Количество товара
|
|
7.
|
Cena
|
Сумма
|
|
ВОЗВРАТ СО СКЛАДА НА
ПЕРЕРАБОТКУ
|
|
|
|
1.
|
Номер накладной
|
Номер накладной
|
|
2.
|
Date_N
|
Дата накладной
|
|
3.
|
Vozvrat
|
Пометка о
|
|
4.
|
Number_S
|
Номер счёта
|
|
5.
|
Name_tovar
|
Наименование товара
|
|
6.
|
Ob_
|
Количество товара
|
|
7.
|
Summa
|
Сумма
|
Физическая модель, определяющая размещение данных, методы
доступа и технику индексирования, называется внутренней моделью системы.
Построение физической модели обусловлено требованиями
используемой СУБД. Поэтому при замене СУБД она также может измениться.
Заключение
Основная функция СУБД, построенной на основании той или иной
модели – организация обмена информацией между пользователями и базами данных с
соответствующими процедурами контроля полномочий и процедур проверки. Среди
пользователей СУБД должно быть определено лицо, которого обычно должно
обеспечивать выполнение следующих функций:
·
определение
информационного содержания базы данных (идентификация объектов и связей,
представляющих интерес для данного предприятия, создание на этой основе
концептуальной схемы (с помощью специального языка);
·
определение
структуры хранения и стратегии доступа;
·
взаимодействие с
пользователем (подготовка и написание внешних схем);
·
определение
стратегии дублирования и восстановления;
·
управление
эффективностью ответа на запросы пользователей;
·
создание словаря
данных.