Материал: Информационные системы в экономике. курсовое проектирование. Лубянская Э.Б., Лукаш Е.Н
Рис. 7.3. Исходный вариант ER-диаграммы
Оставшиеся неясными классы принадлежности и степени связи необходимо выяснить у Заказчика. Для этого надо сформировать вопросы к нему. Вот список возможных вопросов для второго разговора с Заказчиком. Здесь же в скобках даны ответы Заказчика. Следует, однако, помнить, что эти от-
веты характеризуют только конкретное предприятие «Мак-
роСофт».
Верны ли сделанные допущения? (Да.) Как связаны РАБОТНИКИ и РАБОТЫ:
а) каждый делает только одну свою работу; б) каждый делает несколько работ;
в) каждая работа делается несколькими работниками; г) несколько работников участвуют в нескольких рабо-
тах.
Все ли работники заняты выполнением работ по договорам? (Нет.)
Но нужно хранить сведения обо всех работниках? (Да. ) Всегда ли известно, кто выполняет или будет выполнять
каждую из работ? Да.)
Действительно ли каждая разработка делится на несколько работ, причем эти работы для каждой разработки свои?
(Да.)
Может ли заказ иметь несколько разработок? (Нет.)
46
Можно ли одну разработку ПО включить в несколько заказов или каждая разработка уникальна? (Уникальна. Даже если поставляетсяимеющееся программноеобеспечение, то его следует настроить на конкретное применение).
Существуют ли заказы без разработки программного обеспечения, только на компьютеры и комплектующие? (Нет.)
Планируете ли Вы разработки без заказов, на перспективу? (Нет.)
Далее Заказчик уточнил, что ему хотелось бы иметь сведения не только о фирмах, сделавших заказы, но и о потенциальных клиентах для рассылки рекламных проспектов. Поэтому для каждого клиента предприятия, как сделавшего заказ, так и пока не имеющего заказа, требуется знать название фирмы и адрес. На основе состоявшегося разговора была составлена уточненная ER-диаграмма, в которую введены также ключи сущностей (рис.7.4). Имена3 и содержание ключевых атрибутов сводятся в таблицу (табл.7.1).
Рис. 7.4. Уточненная ER-диаграмма
3 Хотя имена в БД назначаются произвольно, лучше разработать для себя определенные пра-
вила их формирования. Тогда работа сильно облегчается, так как имя будет нести информацию осодержанииданных. Здесь применено следующееправило: еслиатрибутявляется номером, то его первая буква - Н. Далее идет сокращенное название (Таб - табельный, Комп - компьютер и т.д.). Если имя состоит из нескольких слов, то каждое слово начинается с заглавной буквы и записывается без пробела.
47
Таблица 7.1 Имена и содержание ключевых атрибутов
Имя |
|
|
Содержание |
|
1 |
|
|
2 |
|
НДог |
Номер договора на разработку. Обычно ведется |
|||
|
учет договоров и им присваиваются уникальные |
|||
|
номера. Если договор составляет клиент, может |
|||
|
оказаться, что у двух разных клиентов имеются |
|||
|
одинаковые номера договоров. Но в ЗАО «Мак- |
|||
|
роСофт» каждому договору присваивается свой |
|||
|
учетный номер. |
|
|
|
НЗак |
Номер заказа. Этот номер также присваивается |
|||
|
ЗАО «МакроСофт»; |
|
||
НКл |
Номер клиента. Названия фирм могут повторять- |
|||
|
ся. Кроме того, если Заказчик - крупная фирма, то |
|||
|
заказы могут делать различные ее отделы. ЗАО |
|||
|
«МакроСофт» ведет учет своих клиентов, при- |
|||
|
сваивая им уникальные номера. |
|
||
НКомпл |
Номер |
вида |
комплектующего |
изделия. |
|
Штрих-коды, широко распространенные в на- |
|||
|
стоящее время, уникально идентифицируют ка- |
|||
|
ждый вид товара. Это представление достаточно |
|||
|
компактно (обычно содержит 13 цифр). С помо- |
|||
|
щью штрихкодов легко вести автоматизиро- |
|||
|
ванный учет движения комплектующий изделий |
|||
|
внутри фирмы. Поэтому в данном случае ис- |
|||
|
пользуется штрих-код в цифровом выражении. |
|||
НКонф |
Номер конфигурации поставляемого компьютера. |
|||
|
Таких конфигураций имеется порядка 20. Они |
|||
|
пронумерованы ЗАО «МакроСофт». |
|
||
НПост |
Номер поставщика. Задается аналогично номеру |
|||
|
клиента. |
|
|
|
48
|
Продолжение табл. 7.1 |
1 |
2 |
НРаб |
Номер работы в рамкахдоговора. В рамкаходного |
|
договора может быть несколько работ. Это сборка |
|
компьютера, тестирование, программирование и |
|
проч. В ЗАО «МакроСофт»работы нумеруются по |
|
порядку их выполнения, причем эта нумерация |
|
начинается заново для каждого договора. Поэтому |
|
много договоров имеют работу№1, №2 и т. д. Для |
|
идентификации конкретной работы требуется |
|
знать номер договора и номер работы по этому |
|
договору |
НТаб |
Табельный номер работника. Присвоением та- |
|
бельных номеров каждому своему работнику за- |
|
нимается каждая фирма. Чаще всего этот номер |
|
содержит только цифры, но иногда в него вво- |
|
дятся дополнительные буквенные обозначения. |
Следующий шаг - формирование структур данных для хранения информации. Такие структуры получили название отношений.
7.2. Правила получения предварительных отношений
Основные определения
Данные в БД представляются в виде отношений. Теория отношений достаточно формализована, так что перед началом изложения материала необходим ряд определений.
МНОЖЕСТВО - совокупность произвольных объектов, объединенных по некоторому признаку.
Каждый объект называется ЭЛЕМЕНТОМ МНОЖЕ-
СТВА.
Элементы не упорядочены и не могут дублироваться.
49
ОТНОШЕНИЕ R есть множество упорядоченных n-КОРТЕЖЕЙ вида: <d1 , d2 , ... , dn> ,
где di - элемент множества Di; d2 - элемент множества D2; dn - элемент множества Dn .
Di , i = 1 , 2 , ... , n называется ДОМЕНОМ отношения R . При проектировании БД элементами множеств являются объекты реального мира, которые описываются при помощи системы характеристик, называемых АТРИБУТАМИ. Значение
характеристики называется ЗНАЧЕНИЕМ АТРИБУТА. В состав ОПИСАНИЯ ОТНОШЕНИЯ входят:
ЗАГОЛОВОК ОТНОШЕНИЯ - множество атрибутов, описывающих объект, причем каждый атрибут соответствует некоторому домену; ТЕЛО ОТНОШЕНИЯ - множество кортежей.
ПРИМЕР. Рисунок 7.5 представляет собой пример отношения.
Рис. 7.5. Пример отношений
Данные, содержавшиеся обычно в традиционных, «ручных» таблицах достаточно произвольного вида, сначала организуются в отношения - определенные выше структуры табличного вида. Тем самым они становятся пригодными для хранения в таблицах реляционных БД. Отношения определяют состав и структуру таблиц БД, в которых будут храниться.
50