база данных. LBD1_1 п. 1,2,4 любых 5 задач 2 задание. Практикум по дисциплине базы данных Лабораторная работа n 1 Построение концептуальной модели базы данных

• Название: Практикум по дисциплине базы данных Лабораторная работа n 1 Построение концептуальной модели базы данных
• Анкор: база данных
• Дата: 14.01.2023
• Размер: 0.64 Mb.
• Имя файла: LBD1_1 п. 1,2,4 любых 5 задач 2 задание.doc
• Тип: Практикум; #886507

ГОСУДАРСТВЕННЫЙ КОМИТЕТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ПО ВЫСШЕМУ ОБРАЗОВАНИЮ

Новосибирская государственная академия экономики и управления

ЛАБОРАТОРНЫЙ ПРАКТИКУМ ПО ДИСЦИПЛИНЕ

«БАЗЫ ДАННЫХ»
Лабораторная работа N 1
«Построение концептуальной модели базы данных»

НОВОСИБИРСК 2000

1. ВВЕДЕНИЕ

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



Рис.1. Три уровня архитектуры базы данных

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

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

Внутренний уровень – это структурный уровень базы данных, определяющий физический вид базы данных. Проектирование на физическом уровне осуществляется с учетом конкретной СУБД (системы управления базами данных) и используемых технических средств (компьютеров, запоминающих устройств, доступа к сетям и т.д.)

На этапе концептуального проектирования разрабатывается концептуальная схема БД. Для этого описываются модели пользовательских представлений данных, которые интегрируются в концептуальную модель, содержащую все элементы корпоративных данных, из которых будет состоять БД.

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



Рис. 2 Этапы проектирования базы данных

В результате выполнения лабораторной работы Вы сможете:

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

2. ОСНОВНЫЕ ПОНЯТИЯ КОНЦЕПТУАЛЬНЫХ МОДЕЛЕЙ
В процессе определения требований и концептуального проектирования выясняются информационных требования пользователей, которые представляются в виде хорошо сконструированной модели.

Модель - это представление реальности, отражаю­щее лишь избранные детали.

Для создания модели необходимо отобразить элементы реальности в элементы модели. Если процесс отображения выполнен должным образом, то моделью можно вос­пользоваться для решения задачи. Если нет, то модель не может послужить источником правильного решения.

Разработка концептуальной модели данных является методо­логической основой создания схем баз данных для конкретных практических ситуаций.
2.1. ОБЪЕКТЫ

Главными элементами концептуальной модели данных являются объ­екты и отношения. Объекты часто представляют в виде существительных, а отношения — в виде глаголов.

Объекты представляют собой вещи, которые пользователи считают важными в моделируемой нами части реальности. Примерами объектов могут быть люди, автомобили, деревья, дома, молотки и книги.

Объекты делятся на конкретные и концептуальные. Примеры конкретных объ­ектов: люди, книги, дискеты и т.д. Концептуальными объектами будут компании, навыки, организации, проекты товаров, деловые операции, штатное расписание.

Для того, чтобы уточнить называется ли объектом конкретная вещь (отдельный человек, конкретный автомобиль, конкретный банк) или множе­ство вещей (все люди, все автомобили, все банки) пользуются термином объектное множество для обо­значения множества вещей одного типа и объект-элемент для обозначения одного члена (одного элемента) объектного множества.

Как показано на рис. 3 мы будем изображать объектные множества в виде прямоугольни­ков, а объекты-элементы — в виде точек. Имя объектного множества пи­шется заглавными буквами в единственном числе. Так «ЧЕЛОВЕК» — имя объектного множества, представляющего людей. Строчными буквами («человек») обозначается элемент из объектного множества ЧЕЛОВЕК. Мы пишем «человек в ЧЕЛОВЕК», чтобы обозначить, что человек является эле­ментом объектного множества ЧЕЛОВЕК.

Объектное множество. Множество вещей одного типа.

Объект-элемент. Конкретный элемент объектного множества.

Рис. 3 Объектное множество и объект-элемент

Объектные множества бывают лексическими и абстрактными. Эле­менты лексических объектных множеств можно напечатать, тогда как эле­менты абстрактных объектных множеств напечатать нельзя.

Так, например, ИМЯ будет лексическим объектным множеством, поскольку его элементами являются имена, то есть строки символов, которые можно напечатать. ДАТА. КОЛИЧЕСТВО и НОМЕР-ПАСПОРТА также являются примерами лексических объектных множеств, так как даты, количества и номера паспортов также можно распечатать.

Лексическое объектное множество. Объектное множество, состоящее из элементов, которые можно распечатать.

Абстрактное объектное множество. Объектное множество, состоящее из элементов, которые нельзя распечатать.

С другой стороны, ЧЕЛОВЕК является абстрактным объектным множеством, поскольку человека напечатать нельзя.

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

Элементы абстрактных объектов будут представлены внутренними номерами, не имеющими смысла вне системы. Внутренний номер иногда называют «Идентификатор объекта» или суррогатным ключом, так как он представляет и однозначно определяет абстрактный объект-элемент реального мира. Примерами суррогатных ключей являются: для гражданина – данные паспорта, для сотрудника предприятия – табельный номер и т.д.

Суррогатный ключ: «Идентификатор» абстрактного объекта-элемента в компьютерной системе; вне системы смысла не имеет
2.2. КОНКРЕТЕЗИЦИЯ И ОБОЩЕНИЕ

Некоторые объектные множества содержатся внутри других объектных множеств. Например, МУЖЧИНА (множество мужчин) содержится внутри множества ЧЕЛОВЕК. Это означает, что каждый мужчина (элемент множе­ства МУЖЧИНА) является также человеком (элементом множества ЧЕЛОВЕК). Аналогично, множество ЖЕНЩИНА содержится внутри множе­ства ЧЕЛОВЕК (ЧЕЛОВЕК).

В данном случае МУЖЧИНА — конкретизация (или подмножество) множества ЧЕЛОВЕК. Мы можем представить это, на­писав МУЖЧИНА - ЧЕЛОВЕК.

ЧЕЛОВЕК, с другой стороны, является обобщением или надмножеством множества МУЖЧИНА (и множества ЖЕНЩИНА).

Конкретизация. Объектное множество, являющееся подмножеством другого объектного множества (содержащее его).

Обобщение. Объектное множество, являющееся надмножеством другого объектного множества.

Графическое изображение конкретизации/обобщения пред­ставлено на рис. 4. U-образный символ обозначает направление включе­ния. Верхняя часть U «открывается» в сторону большего или объемлющего множества.



Рис. 4 Альтернативные представления конкретизации и обобщения

Представим себе мужчину по имени Джордж. Тогда Джордж является также человеком. Это представлено графически на рис. 5 Обратите вни­мание, что две точки обозначают одного и того же человека. Одна точка представляет его как элемент множества ЧЕЛОВЕК, а вторая — как элемент множества МУЖЧИНА. На самом деле это один объект. Он просто показан принадлежащим двум разным объектным множествам. Мы вскоре покажем важность такого представления.



Рис. 5 Две точки, представляющие один и тот же объект
2.3. ОТНОШЕНИЯ

Отношение связывает два объектных множества. Рассмотрим объектные множества ЖЕНАТЫЙ МУЖЧИНА и ЗАМУЖНЯЯ ЖЕНЩИНА. Мы можем определить между этими множествами отношение СОСТОИТ-В-БРАКЕ-С, сопоставив каждому женатому мужчине его жену (или наоборот, каждой замужней женщине - ее мужа).

Отношение. Связь между элементами двух объектных множеств.

Отношение СОСТОИТ-В-БРАКЕ-С составлено из множества женатых пар, в каждой из которых мужчина — из объ­ектного множества ЖЕНАТЫЙ МУЖЧИНА, а женщина - из объектного множества ЗАМУЖНЯЯ ЖЕНЩИНА. Графически мы представляем отно­шение между двумя объектными множествами в виде соединяющего их от­резка (при желании дополненного ромбом) рис. 6.


Рис.6. Графическое представление отношения
Отношение само по себе является объектным множеством, состоящим из пар объектов-элементов, взятых из двух множеств, которые соединяет отно­шение. Иными словами, каждый элемент отношения — это пара элементов из двух объектных множеств. Если

ЖЕНАТЫЙ МУЖЧИНА = {Адам, Дэвид, Джон)

и

ЗАМУЖНЯЯ ЖЕНЩИНА = {Джоан. Линда, Мишель}

и

Адам состоит-в-браке-с Джоан

Дэвид состоит-в-браке-с Линдой

Джон состоит-в-браке-с Мишель

то тогда

СОСТОИТ-В-БРАКЕ-С={(Адам, Джоан)/ (Дэвид, Линда), (Джон, Мишель)}

Фигурные скобки {} заключают множество. На рис. 7 эта информация представлена графически. Мы видим, что отношение СОСТОИТ-В-БРАКЕ-С само является объектным множеством, элементами которого будут семейные пары. Объектное множество типа СОСТОИТ-В-БРАКЕ-С, полученное из от­ношения между другими объектными множествами, называется составным объектным множеством.

Составное объектное множество. Отношение, рассматриваемое как объектное множество.

.

Рис. 7. Графическое представление объекта-отношения

Составным объектным множествам можно давать имена и включать их в отношения, как и обычные объектные множества. На рис. 8 составное множество отношения СОСТОИТ-В-БРАКЕ-С называется СЕМЕЙНАЯ-ПАРА и участвует в нескольких отношениях. Отношение ОТМЕЧАЮТ-ДАТУ-СВАДЬБЫ связывает каждую семейную пару с датой их свадьбы; отношение ПРОЖИВАЮТ-В связывает пару с их адресом, а отношение ЗАРАБАТЫВАЮТ связывает их с их общим совокупным доходом.


Рис. 8 Графическое изображение составного объектного множества

В качестве другого примера рассмотрим два множества служащих ком­пании: ИНСПЕКТОР и РАБОЧИЙ. Мы определим элементы множества РАБОЧИЙ как тех служащих компании, которые не контролируют работу других служащих. Множество ИНСПЕКТОР состоит из тех служащих, кото­рые контролируют рабочих. Отношение КОНТРОЛИРУЕТ (обратите внима­ние, что это глагол) связывает каждого инспектора с рабочими, которых он контролирует (рис. 9). На рис.9 показаны примеры отношения КОНТРОЛИРУЕТ.

Рис. 9. Представление отношения КОНТРОЛИРУЕТ

2.4. МОЩНОСТЬ

Мощность отношения обозначает максимальное количество элементов одного объектного множества, связанных с одним элементом другого объектного множества. Например, если мы допускаем, что у человека может быть только один супруг, то мощность отношения СОСТОИТ-В-БРАКЕ-С бу­дет равна одному в каждом направлении (рис. 10).



Рис. 10. Графическое изображение мощности

Мощность. Максимальное количество элементов одного объектного множества, связанных с одним элементом другого объектного множества.

Хотя обычно нас интересует максимальная мощность, иногда полезно определять и минимальную мощность. Предположим, например, что мы пе­реопределим отношение СОСТОИТ-В-БРАКЕ-С и будем считать, что оно су­ществует между множествами МУЖЧИНА и ЖЕНЩИНА (рис. 10). По­скольку многие мужчины и женщины одиноки, минимальная мощность равна нулю в каждом направлении. Мы пишем возле объектного множества ЖЕНЩИНА «0,1», обозначая этим, что каждый мужчина может иметь от нуля до одной жены. И обратно, 0,1 возле объектного множества МУЖЧИНА обозначает, что у каждой женщины может быть от нуля до одного мужа (рис. 11).

Рис. 11. Изображение мощности отношения СОСТОИТ-В –БРАКЕ-С

Некоторые отношения не имеют конкретного значения максимальной мощности. Например, инспектор контролирует как минимум одного рабо­чего» возможно, больше. Такую мощность мы будем обозначать 1,*, где «1» обозначает минимальную мощность, а «*» просто обозначает «много». С дру­гой стороны, если мы допускаем, что каждого данного рабочего контроли­рует один и только один инспектор, то мощность в обратном направлении будет 1,1 (рис. 12).

Рис.12. Мощность отношения КОНТРОЛИРУЕТ

Мощность отношения конкретизации (или включения) всегда одна и та же. Каждый элемент объемлющего множества связан с одним или нулем элементов подмножества, а каждый элемент подмножества связан ровно с одним элементом объемлющего множества (рис. 13).

Рис. 13. Мощность отношения конкретизации

Максимальная мощность является значительно более важным понятием, чем минимальная. Поэтому для упрощения наших диаграмм мы будем ука­зывать минимальную мощность только тогда, когда это необходимо. За ис­ключением отношения включения (минимальную мощность которого мы об­судили выше), опущенную минимальную мощность можно полагать равной нулю.

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

Отношение один - к – одному. Отношение, максимальная мощность которого равна одному в обоих направлениях.

Отношение один - ко – многим. Отношение, максимальная мощность которого равна одному в одному в одном направлении и многим в обратном.

Отношение много - к – многим. Отношение, максимальная мощность которого равна многим в обоих направлениях.

Если максимальная мощность отношения в обоих направлениях равна одному, мы называем его отношением один-к-одному. Если максимальная мощность в одном направлении равна одному, а в другом — многим, то от­ношение называется отношением один-ко-многим. И, наконец, если макси­мальная мощность в обоих направлениях равна многим, то отношение назы­вается отношением много-ко-многим. В табл.1 приведены характери­стики трех основных мощностей отношений.

Табл. 1. Три основные мощности отношений

Мощность	Обозначение	Пример
Один -к- одному	1:1 или 1-1	У мужа есть одна жена. У жены есть один муж (мощность отношения один-к-одному)
Один – ко -многим	1:* или 1-*	Служащий работает в одном отделе. В отделе работает много служащих (Мощность отношения один-ко-многим)
Много –ко -многим	*:* или *-*	Студент посещает много курсов. Курс слушает много студентов (Мощность отношения много-ко-многим)

2.5. АТРИБУТЫ

Мы представляем объектные множества в виде прямоугольников, а их элементы — в виде точек. Это очень абстрактно. (Что может иметь меньше характеристик, чем точка?) Мы обычно представляем себе элементы объект­ных множеств обладающими некоторыми атрибутами, позволяющими их различать. Например, у человека есть имя, дата рождения, номер страховки, рост, вес, пол, цвет волос, мать. отец и, возможно, супруг(а). Как представлять эти атрибуты?

На самом деле, атрибут объекта — просто функциональное отношение объектного множества этого объекта к другому объектному множеству. Так, два из перечисленных выше атрибутов представлены в виде отношений на рис.14.


Рис. 14. Изображение атрибутов объекта

Атрибут. Функциональное отношение объектного множества с другим объектным множеством.

Однако иногда удобно представлять атрибуты более простым обра­зом, как на рис. 15, Обратите внимание, что имя отношения и имя объекта в некотором смысле комбинируются, давая вместе имя атрибута, особенно ДАТА-РОЖДЕНИЯ. Таким образом, мы видим, что такая запись атрибутов является просто краткой записью отношений. Обычно такой краткой записью можно пользоваться, если мы не собираемся использовать атрибут как объект, участвующий в других отношениях.

Рис. 15. Краткая форма изображения атрибутов объекта

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

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

Ключи. Ключ — это значение, которое однозначно определяет элемент объектного множества. Мы ранее упоминали суррогатные ключи, которые используются в компьютерных системах для идентификации элементов аб­страктных (нелексических) объектных множеств. В реализации концепту­альной базы данных каждый человек из объектного множества ЧЕЛОВЕК получит суррогатный ключ для идентификации этого человека внутри базы данных. Однако, поскольку суррогатные ключи не могут быть использованы вне системы, пользователям базы данных требуются другие средства иден­тификации элементов множества ЧЕЛОВЕК. Для этого используются внеш­ние ключи.

Внешний ключ (иногда называется идентификатором) — это лексиче­ский атрибут или набор лексических атрибутов, значения которых всегда однозначно определяют элемент объектного множества. Лексический атрибут — это атрибут, созданный с участием лексического объектного множе­ства. Таким образом, внешние ключи пользователи могут использовать для идентификации с их помощью конкретных элементов объектного множества вне системы базы данных. Например, на рис. 15 ,№-СТРАХОВКИ может служить ключом для объекта ЧЕЛОВЕК, если допустить, что каждый номер страховки соответствует ровно одному человеку. Таким образом, минималь­ная и максимальная мощности в направлении от №-СТРАХОВКИ к ЧЕЛОВЕК будут 1,1. ДАТА-РОЖДЕНИЯ, напротив, не может служить клю­чом, так как любая данная дата может быть днем рождения нескольких разных людей.

Ключ. Значение, которое всегда можно использовать для однозначного определения элемента объектного множества.

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

Идентификатор. Внешний ключ.

Иногда для создания ключа требуется более одного атрибута. Предполо­жим, что ЧЕЛОВЕК с рис. 15 используется в генеалогической базе данных, отслеживающей генеалогические деревья. Поскольку многие люди из объекта ЧЕЛОВЕК умерли до появления страховок, в качестве ключа при­дется использовать не №-СТРАХОВКИ, а что-то другое. Возможно, доста­точно окажется имени, даны рождения и места рождения. Если это так, то ключом будет комбинация этих трех атрибутов. Если нет, придется привле­кать дополнительные атрибуты. Если нужно, мы всегда можем создать иден­тификационный номер, однозначность которого будет заложена в системе.

Мы показываем, что атрибут служит внешним ключом, подчеркивая его имя.

Не для каждого объекта нужен ключ. Например, в базе данных, запи­сывающей продажи, пользователя может интересовать только продаваемый товар и объем продажи. Очевидно, что многие продажи могут иметь одни и те же значения объема и товара. Совершенно неразумно заставлять пользо­вателя создавать однозначный ключ для каждой продажи. Таким образом, база данных будет записывать только ту информацию о продажах, в которой заинтересован пользователь, однако она будет создавать отдельную запись для каждой продажи. Так, на рис. 16 показаны две разные продажи, в ко­торых продавался товар А237 в количестве 5.95. Пользователь увидит две продажи, не имея никакой возможности различить их; но его это и не инте­ресует. Таким образом, отсутствие ключа не имеет последствий.



Рис. 16. Продажи с одинаковыми значениями атрибутов
Конкретизация/обобщение и атрибуты. Если объект является конкре­тизацией другого объекта, то тогда конкретизированный объект наследует все атрибуты и отношения обобщенного объекта. ЖЕНАТЫЙ ЧЕЛОВЕК, на­пример, является конкретизацией объекта ЧЕЛОВЕК. Поэтому у состоящего в браке человека есть имя, номер страховки, адрес и т.д. просто потому, что он является человеком. Объект ЖЕНАТЫЙ ЧЕЛОВЕК наследует эти атри­буты от объекта человек. Кроме того, у конкретизированного объекта могут быть свои собственные атрибуты. Например, СУПРУГ будет атрибутом объ­екта ЖЕНАТЫЙ ЧЕЛОВЕК, но не объекта ЧЕЛОВЕК. Эти понятия иллюст­рируются рисунком 17.


Рис. 17. Наследование атрибутов при конкретизации

Наследование. Свойство объектного подмножества обладать всеми атрибутами объемлющего множества.

Конкретизированные объекты наследуют не только атрибуты, но и все отношения. На рис. 18 показано, что ЧЕЛОВЕК связан с объектом КОМПАНИЯ отношением РАБОТАЕТ-В.



Рис. 18. Наследование отношений
ЖЕНАТЫЙ ЧЕЛОВЕК, будучи конкретизацией объекта ЧЕЛОВЕК, также связан с объектом КОМПАНИЯ отношением РАБОТАЕТ-В. Предположим, что Джон Доу женат и работает на фирме XYZ. У нас есть точка объекта ЖЕНАТЫЙ ЧЕЛОВЕК, представ­ляющая Джона Доу, точка объекта ЧЕЛОВЕК, представляющая его же, и точка объекта КОМПАНИЯ, представляющая XYZ. Джон Доу из объекта ЖЕНАТЫЙ ЧЕЛОВЕК связан с Джоном Доу из объекта ЧЕЛОВЕК, который связан с компанией XYZ. Следовательно, Джон Доу объекта ЖЕНАТЫЙ ЧЕЛОВЕК связан с компанией XYZ.

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

3. 
   ПОСТРОЕНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ ДЛЯ ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ
   

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

Рассмотрим процесс построения концептуальной модели коммерческого банка. Предположим, в процессе управления банком главный менеджер должен оперативно получать ответы на следующие вопросы: Сколько у нас текущих счетов? Сколько сберегательных счетов? Сколько кли­ентов? У каких клиентов есть и текущие, и сберегательные счета? Каков про­цент сберегательных счетов, баланс которых не превышает 1000 долларов? Какой тип клиентов имеет самый высокий средний баланс счетов? Сколько клиентов помимо обладания текущими и сберегательными счетами брали у нас ссуды?

У банка есть текущие счета, сберегательные счета и клиенты. Мы установим подходящие отношения между ними, как пока­зано на рис. 19.



Рис. 19. Модель данных банка: основные объекты и отношения
Сейчас мы рассматриваем следующие вопросы:

Сколько у нас текущих счетов?

Сколько сберегательных счетов?

Сколько клиентов?

Ответы на эти вопросы можно получить, просто сосчитав количество элементов каждого из трех объектных множеств. При помощи соответст­вующего программного обеспечения менеджер сможет задавать эти вопросы своему персональному компьютеру в любое время или же получать регуляр­ный отчет.

Обратите внимание, насколько более понятным образом эти вопросы об­рабатывает база данных, чем: традиционная файловая система. В файловой системе, не имеющей межфайловых связей, обеспечиваемых базой данных, может быть только два файла: один для сберегательных счетов и один — для текущих. В каждом из этих файлов информация о клиенте будет рас­пределена по нескольким полям (имя клиента, адрес и т.д.). На третий во­прос — «Сколько клиентов» — может оказаться непросто ответить, по­скольку нам придется извлекать данные о клиентах из двух файлов и отбра­сывать повторы. В базе данных же эти данные о клиентах могут храниться отдельно, при этом будут поддерживаться нужные связи с информацией о счетах.

У кого из клиентов есть и текущие счета, и сберегательные?

На этот вопрос можно ответить только рассмотрев отношения. У клиента есть текущий счет, если он (или она) связан посредством отношения ИМЕЕТ-ТЕКУЩИЙ-СЧЕТ с некоторым элементом объектного множества ТЕКУЩИЙ-СЧЕТ. Аналогично, у клиента есть сберегательный счет, если он связан посредством отношения ИМЕЕТ-СБЕРЕГАТЕЛЬНЫЙ-СЧЕТ с некото­рым элементом объектного множества СБЕРЕГАТЕЛЬНЫЙ-СЧЕТ. Наконец, у клиента есть и текущий счет, и сберегательный, если он связан посредст­вом обоих этих отношений с некоторыми элементами объектных множеств ТЕКУЩИЙ-СЧЕТ и СБЕРЕГАТЕЛЬНЫЙ-СЧЕТ. Для того чтобы ответить на предыдущий вопрос, нам нужно просто подсчитать число клиентов, имею­щих обе связи.

Мощности. На рис. 19 были намеренно опущены мощности отноше­ний. Давайте займемся ими теперь. Допустим, мы определили мощности, как показано на рис. 20. Они означают, что у клиента не может быть более одного текущего или сберегательного счета. Каждый счет принадлежит ровно одному клиенту.


Рис 20. Мощности отношений банка

Однако такие мощности могут не отражать действительное положение вещей. Рассмотрим мощность со стороны объекта ТЕКУЩИЙ-СЧЕТ. Владеет ли каждый клиент только одним текущим счетом? АВТ, как и большинство банков, позволяет своим клиентам открывать несколько текущих счетов, однако мощности на рис. 20 этого не позволяют.

Теперь посмотрим на остальные мощности. Реально ли предположить, что счет может относиться к нескольким клиентам? Это тоже вполне веро­ятно, поскольку общие счета — мужа и жены или родителей и детей — весьма широко распространены. Для того чтобы отразить наше более точное восприятие действительности, мы исправили рис. 20 (рис. 21).



Рис. 21. Пересмотренные мощности отношений банка
Модель на рис. 20 неверна, поскольку не отражает наше представление о реальном банке. Для другого представления реальности модель, приведенная на рис. 20 может оказаться верной. Например, банк может позволить клиентам открывать только один текущий счет и запретить совместные счета. В этом случае рис. 20 будет верно отражать реальность такого банка. Модель верна или неверна только в том смысле, правильно ли она отражает реальность, в которой мы заинтересованы.

Обратившись к модели на рис. 21, мы можем теперь ответить на до­полнительные вопросы:

У скольких клиентов по несколько текущих счетов?

Сколько у нас общих счетов?

Сколько обладателей нескольких текущих счетов имеют также сберегательные счета?
Давайте посмотрим, как ответить на первый из этих вопросов. Клиент обладает несколькими текущими счетами, если он связан посредством отно­шения ИМЕЕТ-ТЕКУ ЩИЙ-С ЧЕТ как минимум с двумя элементами объект­ного множества ТЕКУЩИЙ-СЧЕТ. Мы ответим на первый вопрос, рассмот­рев каждый элемент множества КЛИЕНТ и проверив, имеет ли он такие связи, и подсчитав число таких элементов. Мы рекомендуем вам попытаться рассмотреть процесс поиска ответов на все сформулированные вопросы с по­мощью передвижений по диаграмме на рис. 21.

Конкретизация клиентов банка. Всегда ли клиентами банка являются люди? Клиентами банка могут быть организации: коммерческие предпри­ятия, некоммерческие организации, церкви, правительственные учрежде­ния. Хочет ли менеджер различать типы клиентов? Да, поскольку у разных типов клиентов могут быть разные атрибуты. Кроме того, их счета могут обладать разными характеристиками. На рис. 22 представлены две кон­кретизации объекта КЛИЕНТ, ФИЗИЧЕСКОЕ ЛИЦО, разумеется, включает клиентов-людей. ЮРИДИЧЕСКОЕ ЛИЦО объединяет клиентов-организации.


Рис. 22. Конкретизации объекта КЛИЕНТ

Одно из основных преимуществ использования обобщения и конкрети­зации состоит в том, что мы можем создавать разные атрибуты для конкре­тизации объектного множества, сохраняя при этом общие атрибуты объем­лющего уровня. На рис. 23 показано, что у каждого клиента есть номер, который может использоваться в качестве ключа, но атрибуты физического лица могут отличаться от атрибутов юридического лица.



Рис. 23. Атрибуты типов клиентов
Давайте, модифицируем рис. 21, отразив конкретизации объекта КЛИЕНТ. Наша модификация представлена на рис. 24, который является комбинацией рисунков 21 и 23. (На этом рисунке мы опустили ромбы при обозначении отношений. Впредь мы обычно будем их опускать.) Мы также добавили атрибут БАЛАНС к каждому объектному множеству счетов.

Рис. 24. Счета клиентов разных типов

Теперь мы готовы ответить на несколько новых вопросов:

Каков процент сберегательных счетов, баланс которых не превышает 1000 дол­ларов? Какой тип клиентов имеет самый высокий средний баланс счетов?

Ответ на второй вопрос зависит от того, что мы подразумеваем под «типом клиента». Структура нашей базы данных позволяет нам различать физические лица и юридические лица. Мы также можем определить отли­чия внутри объекта ЮРИДИЧЕСКОЕ ЛИЦО с помощью атрибута ТИП ОРГАНИЗАЦИИ. Например, типом организации может быть Коммерческое Предприятие, Некоммерческая Организация, Церковь или Правительствен­ное Учреждение. Для того чтобы ответить на второй вопрос, мы начнем с объекта ФИЗИЧЕСКОЕ ЛИЦО и перейдем от него, минуя объект КЛИЕНТ, к объекту ТЕКУЩИЙ-СЧЕТ через ИМЕЕТ-ТЕКУЩИЙ-СЧЕТ. Мы проделаем это для каждого физического лица, записывая баланс. Закончив с физическими лицами, мы подсчитаем средний баланс физических лиц. Затем мы проделаем все то же самое с юридическими лицами. Для того чтобы ответить на наш вопрос, нужно только сравнить два результата.

3. 
   ПОСТРОЕНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ ДЛЯ СИСТЕМ ОБРАБОТКИ ДАННЫХ
   

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

Однако возникает необходимость разработки моделей, которые могли бы быть использованы в системах обработки данных, обра­батывающих операции, ежедневно выполняемые работниками компании.

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

Описание деятельности консультационной службы

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

Смета. Каждому клиенту, с которым заключается контракт, Джоан должна предложить план проекта. Он включает, среди прочего, тип проекта, цель, структуру задачи и структуру оплаты. Оплата в зависимости от плана, работы может сильно различаться. Она зависит от услуг, предоставляемых клиенту, а также от времени и усилий, необходимых для выполнения контракта. Вся ин­формация о контракте сохраняется для дальнейшего использования. Обо всех изменениях, вносимых в смету, сообщается клиенту; они также записываются.

Приход. Хотя по многим контрактам на небольшие суммы расплачиваются на­личными, большинство клиентов платят чеками. Оплата должна производиться по исполнении контракта, если не было согласовано предоставление кредита. Кредиты обычно оплачиваются клиентами вовремя но иногда Джоан прихо­дится рассылать клиентам повторные счета.

Расход. Хотя многие расходы непосредственно вносятся в сумму определенного контракта, многие расходы на материалы и оборудование относятся к несколь­ким контрактам или производятся заранее. Оплата закупок всегда производится чеками.

Модель данных о закупках

Форма заказа фирмы Мэнуоринг, которая используется для заказа това­ров, представлена на рис. 25. Она содержит название и адрес поставщика, дату, номер заказа и номер поставщика. В ней также указан инвентарный номер, товар и цена каждого товара. Общая сумма, включая налог, указана внизу.


Рис. 25. Форма заказа Консультационной Службы
Из этой формы мы можем вывести следующие объектные множества:

ПОСТАВЩИК, ЗАКАЗ, ТОВАР. Атрибуты этих трех множеств, как и отно­шения между ними, показаны на рис. 26. Обратите внимание на мощности отношений. Отношение между множествами ЗАКАЗ и ПОСТАВЩИК имеет мощность один-ко-многим, так как каждый заказ делается одному постав­щику, но данному поставщику может быть сделано несколько заказов. От­ношение ВКЛЮЧАЕТ между объектами ЗАКАЗ и ТОВАР имеет мощность много-ко-многим, так как заказ содержит несколько товаров, и товар может встречаться в нескольких заказах.


Рис. 26. Исходная модель данных о закупках Консультационной Службы
В конце концов заказ будет оплачен. Для того чтобы записать эту ин­формацию, мы расширим модель до представленной на рис. 27. Мы доба­вили объектное множество ОПЛАТА с атрибутами НОМЕР ЧЕКА и ДАТА. Мощность один-к-одному обозначает, что один заказ оплачивается одним чеком.


Рис. 27. Расширенная модель данных о закупках Консультационной Службы
5. ЗАДАНИЕ ДЛЯ САМОСТОЯТЕЛЬНОЙ РАБОТЫ

В процессе выполнения самостоятельной работы по изучаемой теме необходимо выполнить два задания:

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

Исходными данными для построения модели является набор вопросов, на которые должна система отвечать. Для выполнения этого задания необходимо описать предметную область. Проанализировать вопросы и определить объектные множества, отношения, атрибуты, мощности и ключи. Система должна давать ответы на все ниже перечисленные и подобные им вопросы.

1. 
   Сколько преподавателей работает на математическом факультете? Их фамилии? Кто работает на музыкальном факультете? (3амечание «математический» и «музыкальный» факультеты взяты для примера). Ваша модель должна также отвечать на аналогичные вопросы, касающиеся факультетов социологии, политологии, инженерного и т.д.)
   
2. 
   Какие студенты специализируются в истории? В английском?
   
3. 
   Кто из преподавателей читает социологические курсы? Какие курсы они читают?
   
4. 
   Сколько студентов занимаются по программе Физика 201 ? Какой раздел изучает Андреа Иденс?
   
5. 
   Сколько студентов, чьей специальностью является немецкий язык, официально зарегистрированы на усиленной программе? Кто является преподавателем каждого из них? Следующие модели создаются для торговой фирмы.
   
6. 
   Какие товары имеют продажную цену более 200 долларов? Какие из них имеют закупочную цену менее 150 долларов? Какие товары произведены на Среднем Западе? Кто их изготовители?
   
7. 
   Кто из продавцов продал товары ценой более 200 долларов? Даты этих продаж? Какова базовая зарплата этих продавцов? Следующие модели создаются для банка. Начните с модели на рис. 21 и добавляйте к ней все, что необходимо.
   
8. 
   Какой процент обладателей текущих счетов банка составляют его служащие?
   
9. 
   Сколько кассиров имеют в банке сберегательные счета? Сколько менеджеров? Сколько кассиров не имеют таких счетов?
   
10. 
    Кто из менеджеров, имеющих в банке сберегательные счета, руководит служащими, имеющими в банке сберегательные счета?
    

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

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

Пример варианта задания:



Рис. 28. Отчет о специализации консультантов