Обязательность на обоих концах

 

В принципе невозможна.

4.1.2.2. OR-модель

OR-модель (Object-Role - объект-роль) рассматривает ПрО как со­вокупность элементарных фактов и описывает реальный мир в терми­нах объектов, которые играют определенные роли (участвуют в связях) по определённым правилам (в соответствии с определёнными ограни­чениями). В отличие от ER-моделей в этой модели понятие атрибута яв­но не используется, а наличие атрибута сущности в ER-модели будет соответствовать связи между 2-мя объектами (атрибут становится само­стоятельным объектом). В этой модели количество объектов в одной связи также неограничено. Пример OR-модели представлен на рис. 4.12.

Рис. 4.12. Пример OR-модели

 

Графическая нотация для OR-модели следующая. Объект-сущность (Студент) изображается поименованным овалом, свойство объекта (ФИО) - пунктирным поименованным овалом, связь (обучение студента в группе) - поименованным прямоугольником, разделенным на столько частей, сколько объектов участвует в связи, т.е. количество связей у од­ного объекта равно количеству его ролей. Идентифицирующее свойство (№ зачетки) может быть указано в круглых скобках после названия объ­екта или выделено в отдельный объект со связью. Черная точка возле объекта означает обязательность роли этого объекта в связи (Группа должна обучаться по какой-нибудь специальности). Стрелка над ролью объекта в связи означает уникальность участия объекта в связи по от­ношению к другому объекту в этой связи (Каждый студент учится толь­ко в одной группе). Стрелка над всеми ролями в одной связи говорит о том, что связь между объектами в этой связи M:N (Кафедра обеспечива­ет подготовку по нескольким специальностям; специальность может обеспечиваться несколькими кафедрами). Уникальность нескольких ро­лей объекта отображается соединяющей эти роли линией с кругом, внутри которого стоит U (uniqueness - уникальность) (Студент с одной фамилией может учиться только в одной группе).

OR-модели, используя универсальный подход представления ПрО в виде объектов и их ролей в связях друг с другом, являются более вы­разительными моделями по сравнению с ER-моделями. Однако только потому, что одна модель является более выразительной, чем другая, не дает ей превосходства; среды разной выразительности моделирования являются разными инструментами для различных целей. При составле­нии модели всегда имеются компромиссы: ER-мод ели являются более компактными и в результате легко читаемыми, чем более выразитель­ные и масштабными OR-моделями. В настоящее время для построения концептуальной схемы предпочитают пользоваться ER-моделями. Сле­дует отметить, что построив одну модель (ER-модель), можно без осо­бого труда получить из нее другую модель (OR-модель) и наоборот. Т.к. атрибут ER-модели преобразуется в объект OR-модели и наоборот, объ­ект OR-модели, который играет только одну роль и связан с одним объ­ектом является атрибутом той сущности в ER-модели, с которой он свя­зан.

4.2. Выбор СУБД

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

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

опираясь на некоторые критерии отбора. В результате выделяют сле­дующие группы критериев [17]: —1 Моделирование данных

—1 Особенности архитектуры и функциональные возможности —1 Контроль работы системы —1 Особенности разработки приложений —1 Производительность —1 Надежность —1 Требования к рабочей среде —1 Смешанные критерии Далее рассмотрим каждую из этих групп критериев.

—1 Моделирование данных

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

• Триггеры и хранимые процедуры. Триггер - программа БД, автома­тически вызываемая всякий раз при вставке, изменении или удалении строки таблицы. Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти изменения будут приняты. Хранимая процедура - программа, которая хранится на сервере и может вызывать­ся клиентом. Поскольку хранимые процедуры выполняются непосред­ственно на сервере БД, обеспечивается более высокое быстродействие, нежели при выполнении тех же операций средствами клиента БД. В различных программных продуктах для реализации триггеров и храни­мых процедур используются различные инструменты.

• Средства поиска. Некоторые современные системы имеют встро­енные дополнительные средства контекстного поиска.

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

• Реализация языка запросов. Все современные системы совместимы со стандартным языком доступа к данным SQL-92, однако многие из них реализуют те или иные расширения данного стандарта.

—i Особенности архитектуры и функциональные возможности

• Мобильность. Это независимость системы от среды, в которой она работает. Средой в данном случае является как аппаратура, так и ПО (операционная система).

• Масштабируемость. При выборе СУБД необходимо учитывать, сможет ли данная система соответствовать росту ИС, причем рост мо­жет проявляться в увеличении числа пользователей, объема хранимых данных и объеме обрабатываемой информации.

• Распределенность. Основной причиной применения информацион­ных систем на основе БД является стремление объединить взгляды на всю информацию организации. Самый простой и надежный подход - централизация хранения и обработки данных на одном сервере. Однако различные системы имеют разные возможности управления распреде­ленными БД.

• Сетевые возможности. Многие системы позволяют использовать широкий диапазон сетевых протоколов и служб для работы и админист­рирования.

—1 Контроль работы системы

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

• Автонастройка. Многие современные системы включают в себя возможности самоконфигурирования, которые, как правило, опираются на результаты работы сервисов самодиагностики производительности. Данная возможность позволяет выявить слабые места конфигурации системы и автоматически настроить ее на максимальную производи­тельность.

—1 Особенности разработки приложений

• Многие производители СУБД выпускают также средства разработ­ки приложений для своих систем. Как правило, эти средства позволяют наилучшим образом реализовать все возможности сервера, поэтому при анализе СУБД стоит обратить внимание также и на возможности средств разработки приложений.

• Средства проектирования. Некоторые системы имеют средства ав­томатического проектирования как БД, так и прикладных программ. Причем, средства проектирования различных производителей могут существенно различаться.

• Многоязыковая поддержка. Поддержка большого количества на­циональных языков расширяет область применения системы и прило­жений, построенных на ее основе.

• Возможности разработки Web-приложений. При разработке раз­личных приложений зачастую возникает необходимость использовать возможности среды Internet. Средства разработки некоторых произво­дителей имеют большой набор инструментов для построения приложе­ний под Web.

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

—1 Производительность

• Рейтинг ТРС (Transactions per Cent - количество транзакций в про­центом отношении). Для тестирования производительности применяют­ся различные средства, и существует множество тестовых рейтингов. Одним из самых популярных и объективных является ТРС-анализ про­изводительности систем. Фактически ТРС анализ рассматривает компо­зицию СУБД и аппаратуры, на которой эта СУБД работает. Показатель ТРС - это отношение количества запросов обрабатываемых за некий промежуток времени к стоимости всей системы.

• Возможности параллельной архитектуры. Для обеспечения па­раллельной обработки данных существует, как минимум, два подхода: распараллеливание обработки последовательности запросов на несколь­ко процессоров, либо использование нескольких компьютеров- клиентов, работающих с одной БД, которые объединяют в так называе­мый параллельный сервер.

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

—1 Надежность

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

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

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

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

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

—1 Требования к рабочей среде

• Поддерживаемые аппаратные платформы

• Минимальные требования к оборудованию

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

• Операционные системы, под управлением которых способна рабо­тать СУБД.

—1 Прочие критерии

• Качество и полнота документации. Для любой системы не по­следнюю роль играет наличие подробной и качественной документации.

• Локализованность. Возможность использования национальных языков является еще одним преимуществом выбранной системы.

• Модель формирования стоимости. Как правило, производители СУБД используют определенные модели формирования стоимости. На­пример, стоимость одного и того же продукта может существенно из­меняться в зависимости от того, сколько пользователей будет с ним ра­ботать.

• Стабильность производителя

• Распространенность СУБД

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

4.3. Проектирование физической структуры БД

На этапе проектирования физической структуры БД решается во­прос о способе реализации БД, но после того, как будет определена це­левая СУБД. Целью этого этапа является описание способа физической реализации логической модели, полученной на предыдущем этапе, в среде выбранной СУБД.

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

о

Физическая модель фактически представляет собой ddl -скрипт по созданию объектов в БД: таблиц, описанных в реляционной модели данных, др. объектов (представлений, триггеров, процедур, функций и др.) для реализации необходимых бизнес-правил в среде СУБД. Пример физической модели для создания таблицы Личность представлен ниже:

CREATE TABLE Личность

(

фамилия VARCHAR2(100) NOT NULL, имя VARCHAR2(80) NOT NULL, отчество VARCHAR2(90) NOT NULL, дата_рождения DATE, место рождения VARCHAR2(100), пол VARCHAR2(10) NOT NULL, национальность VARCHAR2(30)

);

³ ddl (data definition language) - язык определения данных, используемый для созда­ния, изменения и удаления объектов БД

4.4. CASE-средства, используемые при проектировании БД

На сегодняшний день рынок CASE-средств, используемых для проектирования БД, представлен достаточно широко, среди популярных продуктов можно выделить следующие: Computer Associates AllFusion ERwin Data Modeler, Oracle Designer, Microsoft Office Visio, Sybase Pow­er Designer, IDS Prof. Scheer ARIS и др.

Рассмотрим 2 мощных средства, позволяющих выполнить весь процесс проектирования БД от построения концептуальной схемы дан­ных ПрО до создания физической модели БД: Computer Associates All- Fusion ERwin Data Modeler и Oracle Designer.

ERwin Data Modeler

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

] ERwin является мощным и достаточно простым в использовании средством проектирования реляционных БД, завоевавшим широкое признание и популярность.

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

] ERwin - это не просто средство, облегчающее проектирование, но и инструмент разработки, способный автоматически создавать таб­лицы и генерировать тексты хранимых процедур и триггеров для мно­гих популярных СУБД.

] Однако необходимо понимать, что сам по себе ERwin - это по большому счёту лишь удобное средство «рисования» с множеством до­полнительных возможностей, позволяющее зафиксировать и наглядно представить то, что спроектировал пользователь. Использование ERwin (и стандарта IDEF1X в его рамках) само по себе не обеспечивает полу­чение оптимальной схемы БД. Поэтому для эффективного использова­ния данного инструмента необходимо хорошее знание теории проекти­рования реляционных БД.

] В ERwin предусмотрено два типа моделей: логическая и физиче­ская. Логическая модель - это абстрактный взгляд на данные, это КИМПО. Логическая модель данных является универсальной в том смысле что, она никак не связана с конкретной реализацией для вы­
бранной СУБД. Физическая модель - модель БД для конкретной СУБД, которая фактически является отображением системного каталога БД. В физической модели содержится уже информация не об объектах ПрО, а об объектах БД. Одной и той же логической модели могут соответство­вать несколько разных физических моделей.

] ERwin поддерживает стандарт моделирования IDEF1X (Integra­tion DEFinition for Information Modeling). IDEF1X является методом для разработки реляционных БД и использует условный синтаксис, специ­ально разработанный для удобного построения концептуальной схемы. IDEF1X подразумевает использование различных уровней моделирова­ния при проектировании системы.

Клиент ^ Код_клиента         Имя Фамилия Номер паспорта Дата рождения

Предмет_заказа

Код_клиента (FK) Номер заказа (FK) Код_товара

Заказ • Г— "Л Код_клиента (FK)     ^ Номер заказа :----------------------   Исполнитель (FK)     Дата приёма     Дата исполнения   чшшштшшшшшшш[2]

Рис. 4.15. Фрагмент полной атрибутивной модели

—1 Логической модели в IDEF1X соответствуют три уровня моделиро­вания, отличающиеся по глубине представления информации о данных: • Диаграмма сущность-связь (Entity-Relationship Diagram (ERD)) - это модель данных верхнего уровня, которая включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области (рис. 4.13).

Клиент	§ А --------------- ~	Заказ	•1

Предмет_заказа

Рис. 4.13. Фрагмент диаграммы сущность-связь

 

• Модель данных, основанная на ключах (Key-Based Model (КВМ)) - более подробное представление данных, включает описа­ние сущностей и первичных ключей (рис. 4.14).

Клиент Заказ

Предмет_заказа Рис. 4.14. Фрагмент модели данных, основанной на ключах

 

Физическая модель в IDEF1X представлена двумя уровнями: • Трансформационная модель (Transformation Model (ТМ)) - мо­дель данных, соответствующая конкретной СУБД. Структуры дан­ных оптимизируются исходя из возможностей СУБД, объёмов дан­ных, предполагаемых схем доступа и интенсивности использования данных (рис. 4.16).

ITEM______________

^ order_num: NUMBER (FK) ^ customerjd: NUMBER (FK) articlejd: NUMBER

quantity: INTEGER

Рис. 4.16. Фрагмент трансформационной модели

• Модель СУБД (DBMS Model) - содержит определения объек­тов физической структуры БД в схеме СУБД или системном ката­логе БД, напрямую генерируется из ТМ. ERwin непосредственно поддерживает эту модель путём генерации схемы БД. Фактически эта модель представляет собой текст DDL-предложений на языке SQL:

CREATE TABLE CUSTOMER (

id NUMBER NOT NULL,

first name VARCHAR2(20) NULL, lastname CHAR(18) NULL, passportnum CHAR(18) NULL, birthday DATE NULL,

PRIMARY KEY (id));

CREATE TABLE ORDER (

id NUMBER NOT NULL,

ordernum NUMBER NOT NULL, makerid NUMBER NULL,

accept date DATE NULL, return date DATE NULL, PRIMARY KEY (id, order num), FOREIGN KEY (id)

REFERENCES CUSTOMER (id));

CREATE TABLE ORDER ITEM (

id NUMBER NOT NULL,

order num NUMBER NOT NULL, articlejd NUMBER NOT NULL, quantity INTEGER NULL,

PRIMARY KEY (order num, id, articlejd), FOREIGN KEY (id, order num)

CUSTOMER ORDER Ц, id: NUMBER   Д customerjd: NUMBER (FK)] ^ order_num: NUMBER ф   first_name: VARCHAR2(20) last_name: CHAR(18) passport_num: CHAR(18) birthday: DATE   makerjd: NUMBER accept_date: DATE return_date: DATE   ----------- •

REFERENCES ORDER (id, order num));

Таким образом, процесс разработки БД в ERwin фактически пред­ставляет собой последовательное продвижение по уровням моделиро­вания от диаграммы сущность-связь до генерации кода, необходимого для физического создания БД.

Oracle Designer

Oracle Designer - это сложное приложение, реализованное в среде СУБД Oracle, состоящее из 2 частей: серверной и клиентской. Сервер­ная сторона Oracle Designer представляет собой репозитарий (хранили­ще метаданных) и API по управлению репозитарием. Каждый раз, когда выполняется операция добавления, сохранения, удаления и т.д. в одном из инструментов клиентской стороны, изменения посредством API за­носятся в репозитарные таблицы. Для проектирования БД серверная часть не нужна, а необходимо использовать клиентскую часть Oracle Designer. Клиентская сторона продукта - это набор инструментов, включающий несколько диаграммеров, навигаторов, утилит преобразо­вания и генераторов, а также утилиты, поддерживающие все этапы раз­работки системы.

Для проектирования БД используются следующие инструменты Oracle Designer:

] Entity-Relationship Diagrammer - для проектирования КИМПО

и построения диаграммы сущность-связь ] Design Editor - для построения реляционной модели ПрО Фрагмент реляционная модели ПрО вуз представлен на диаграмме, построенной в Design Editor, на рис. 4.17.

J РАС ПИ САН И Е 3АНЯ ТИ И (S i t 1 1[3] 1 тч # * 7s, но№р_гр/ппы # * А ти п_недели # * А двнь_нвдели # * 78, нсжер_занятия * А дисциплина * А корпус * А аудитория * А и д_преподавателя

^ПРЕПОДАВАТЕЛЬ (Sis s|
Mm 1*	XI 1-1
*?8,	ид
* а	фио
о ш	дата_рождения
* А	долж ностъ
* А	кафвдра
	• • •

\/

рН-

^ПОДРАЗДЕЛЕНИЕ (Sis sp
0 1 1 *	XI 1-1
* * А	название
* А	фио_начальника
о А	старшее • • •

 

V

]]ГРУППА СТУДЕНТОВ (Sis spravochnik)

А д|ГИТУЛ_УЧЕБНОГО_ПЛАНА (Sis_ 1 11*11 Н

Ы 1*1 1 и

^УЧЕБНЫЙ_ПРОЦЕСС (Sis_spravochn
i й	1 1*	1 1-1
# *	78,	и д_ти тул а_учеб ного_пл а на
# *	А	дисциплина
# *	78,	сшестр
# *	А	вид_занятии
*	78,	количество часов • • •

 

V

 

А

^СТУДЕНТ (Sis spravochnik)

\

N 1*1 1 1-1

# *	А	номер_3 а *-етной _кни ж к и
*	А	ног/ер_группы
*	А	фио
*	Ш	дата_рождения
*	А	пол
О	А	национальность
*	78,	ти п_фи на нси рэвани я
*	т	дата_за числения
о	Ш1	дата_отчиспения

 

# *	70,	ид
*	А	кафедра
*	78,	номер_спн_|иальности
*	А	форма_обуиени я
*	?8,	год_при ема
*	78,	срок_обу-ения
о	т	дата_утверж дени я

\/

 

 

^СПЕЦИАЛЬНОСТЬ (Sis sp
\ 1*	1 1-1
# * 78,	но1\/ер_по_гос
* А	название
* А	квалификация
О ?8ч	направление
	• • •

т

 

Рис. 4.17. Пример реляционной модели, построенной в Design Editor

Для получения физической структуры БД в Oracle Designer исполь­зуется утилита Generate Database from Server Model, которая создает ddl_фaйл для генерации объектов БД.

4.5. Пример проектирования БД

Рассмотрим на примере весь процесс проектирования БД от по­строения концептуальной схемы данных ПрО до создания физической модели БД на основе имеющегося описания ПрО «Отдел кадров в части трудоустройства». Описание включает в себя информационных потреб­ностей пользователей и основных ограничений к ПрО.

В отделе кадров предприятия накапливается и обрабатывается ан­кетная информация о работниках: ФИО, дата, место рождения, адрес, паспортные данные, национальность, гражданство, знание иностранных языков, дети (ФИО, дата рождения), образование (учебное заведение, год окончания, № диплома, специальность, квалификация), история ра­боты (дата поступления, название организации, должность, дата уволь­нения).

При трудоустройстве работник заключает контракт с предприяти­ем, который включает информацию: ФИО, подразделение, должность, условия работы: длительность рабочего дня (число часов либо ненор­мированный), место работы, система оплаты (оклад, сдельная, повре­менная) и размер оплаты, требования к работнику, его адрес, паспорт­ные данные. Условия контракта могут изменяться с течением времени по соглашению сторон. Все изменения должны быть зафиксированы и сохранены.

Кроме того, в отделе кадров накапливается информация о награж­дениях и взысканиях, повышениях квалификации, совмещении должно­стей.

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

Во-первых, однозначно можно сказать, что есть сущность Работ­ник с атрибутами о персональных сведениях (ФИО, дата рождения, место рождения, национальность).

Если место рождения представлять детально, то получим следую­щий вариант сущности Работник1 {ФИО, дата рождения, страна ро­ждения, регион рождения, район рождения, тип населенного пункта рождения, название населенного пункта рождения). Таким образом, для всех атрибутов, по которым необходимо детальная информация, не создаются отдельные сущности, а в той же сущности этот атрибут заме­няется на те атрибуты, которые необходимо заполнить.

Далее определяем сущности, которые могут иметь несколько эк­земпляров для одного работника.

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

Паспортные данные (ID работника, Тип паспорта, Страна, вы­давшая паспорт. Серия паспорта, Номер паспорта, Кем выдан, Дата выдачи, Действителен до)

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

Адрес работника (ID работника, Тип адреса, Город, Улица, Номер дома, Номер квартиры)

Полагая, что одна личность может быть гражданином нескольких стран, определяем сущность Гражданство.

Гражданство (ID работника, Страна гражданства, Дата пре­доставления)

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

Аналогично определяем сущности Знание иностранных языков и Дети.

Знание иностранных языков (ID работника. Язык, Степень вла­дения)

Дети (ID работника, ФИО ребенка. Дата рождения ребенка)

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

Образование (ID работника, Учебное заведение, Год окончания, Номер диплома, Специальность, Квалификация)

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

Получаем сущность История работы (ID работника, Название ор­ганизации, Должность, Дата поступления, Дата увольнения).

Далее анализируем часть описания, связанную с контрактом.

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

Основной контракт (ID работника, № контракта, Дата заключения контракта, Подразделение, Должность, Длительность рабочего дня, Ра­бочее место, Система оплаты, Размер оплаты, Требования к работнику)

Коль скоро не известна структура контракта, а в рамках одного доп. соглашения могут одновременно поменяться значения нескольких атрибутов, структура доп. соглашения во многом повторяет структуру основного.

Дополнительное соглашение (ID работника, № контракта, Дата заключения контракта, Дата дополнительного соглашения к основному контракту, Подразделение, Должность, Длительность рабочего дня, Ра­бочее место, Система оплаты, Размер оплаты, Требования к работнику)

Кроме того, в отделе кадров накапливается информация о награж­дениях и взысканиях, повышениях квалификации, совмещении должно­стей.

Полагаем, что работник может получать награду/поощрения одно­го типа не однократно

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

Повышение квалификации (ID работника, Учебное заведение, Дата начала, Дата окончания, Специальность, Номер удостоверения)

Построенная концептуальная схема ПрО «Отдел кадров» в нотации IDEF1X представлена на рис.4.18.

Работник Рис. 4.18. Концептуальная схема ПрО «Отдел кадров» в нотации IDEF1X

Ниже приведен листинг ddl-файла, запустив который, выполнится скрипт по созданию физической структуры БД для спроектированной выше концептуальной схемы ПрО «Отдел кадров».

CREATE TABLE Работник (

ид NUMBER(4) NOT NULL PRIMARY KEY,

ФИО VARCHAR2(60) NOT NULL,

дата_рождения DATE NOT NULL, национальность VARCHAR2(30) NOT NULL, месторождения VARCHAR2(100) NOT NULL

);

CREATE TABLE Паспортные данные (

страна VARCHAR2(50) NOT NULL,

серия VARCHAR2(10) NOT NULL,

номер VARCHAR2(20) NOT NULL,

типпаспорта VARCHAR2(15) NOT NULL, ид_работника VARCHAR2(18) NOT NULL, кемвыдан VARCHAR2(30) NOT NULL, дата_выдачи DATE NOT NULL, действителен_до DATE NULL, PRIMARY KEY (страна, серия, номер)

);

CREATE TABLE Адрес (

ид_работника CHAR(18) NOT NULL, тии_адреса VARCHAR2(20) NOT NULL, город VARCHAR2(30) NOT NULL,

улица VARCHAR2(30) NOT NULL,

номер_дома VARCHAR2(5) NOT NULL, номер квартиры VARCHAR2(5) NOT NULL, PRIMARY KEY (ид_работника, тии адреса)

);

CREATE TABLE Гражданство (

ид_работника CHAR(18) NOT NULL, страна VARCHAR2(50) NOT NULL,

дата_предоставления DATE NOT NULL, PRIMARY KEY (ид_работника, страна)

);

CREATE TABLE Знаниеиностранныхязыков (

ид_работника VARCHAR2(18) NOT NULL, язык VARCHAR2(20) NOT NULL,

стеиень_владения VARCHAR2(20) NOT NULL, PRIMARY KEY (ид_работника, язык)

);

CREATE TABLE Дети (

ид_работника CHAR(18) NOT NULL,

ФИО_ребенка VARCHAR(IOO) NOT NULL, дата_рожде11ияребеi1ка DATE NOT NULL, PRIMARY KEY (ид_работника, ФИО_ребенка)

);

CREATE TABLE Образование (

номер диплома VARCHAR2(20) NOT NULL PRIMARY KEY, ид_работника VARCHAR2(18) NOT NULL, учебное_заведение VARCHAR2(50) NOT NULL, год_окончания NUMBER(4) NOT NULL, специальность VARCHAR2(30) NOT NULL, квалификация VARCHAR2(30) NOT NULL

);

CREATE TABLE История_работы (

ид_работника VARCHAR2(18) NOT NULL, названиеорганизации VARCHAR2(50) NOT NULL, должность VARCHAR2(30) NOT NULL,

дата_поступления DATE NOT NULL, дата_увольнения DATE NULL,

PRIMARY KEY (ид_работника, название организации, должность, дата_постуиления)

);

CREATE TABLE Основнойконтракт (

номер контракта VARCHAR2(10) NOT NULL,

дата_заключения DATE NOT NULL,

ид_работника VARCHAR2(18) NOT NULL, подразделение VARCHAR2(50) NOT NULL, должность VARCHAR2(3 0) NOT NULL, длительность_рабочего_дня DATE NOT NULL, рабочееместо VARCHAR2(30) NOT NULL, системаоплаты VARCHAR2(10) NOT NULL, размер_оплаты NUMBER(10,2) NOT NULL, требования_к_работнику VARCHAR2(500) NOT NULL, PRIMARY KEY (номер контракта, дата заключения)

);

CREATE TABLE Дополнительное соглашение (

номер_контракта VARCHAR2(10) NOT NULL,

дата_заключения_контракта DATE NOT NULL, дата_заключения_доп_соглашения DATE NOT NULL ид_работника VARCHAR2(18) NOT NULL, подразделение VARCHAR2(50) NOT NULL, должность VARCHAR2(30) NOT NULL, длительность_рабочего_дня DATE NOT NULL, рабочее место VARCHAR2(30) NOT NULL, система оплаты VARCHAR2(10) NOT NULL, размер_оплаты NUMBER(10,2) NOT NULL, требования_к_работнику VARCHAR2(500) NOT NULL, PRIMARY KEY (номер контракта, дата заключения контракта, дата_заключения_доп_соглашения)

);

CREATE TABLE Награждение (

ид_работника VARCHAR2(18) NOT NULL, тип_награды VARCHAR2(30) NOT NULL, дата_награждения DATE NOT NULL,

PRIMARY KEY (ид_работника, тип награды, дата награждения)

);

CREATE TABLE Поощрение (

ид_работника VARCHAR2(18) NOT NULL, типпоощрения VARCHAR2(30) NOT NULL, дата_поощрения DATE NOT NULL,

PRIMARY KEY (ид_работника, тип поощрения, датапоощрения)

);

CREATE TABLE Повышениеквалификации (

ид_работника VARCHAR2(18) NOT NULL, учебное_заведение VARCHAR2(50) NOT NULL, дата_начала DATE NOT NULL,

дата_окончания NUMBER(4) NULL, специальность VARCHAR2(30) NOT NULL, номер_удостоверения VARCHAR2(10) NOT NULL, PRIMARY KEY (ид_работника, учебное_заведение, дата_начала)

);

ALTER TABLE Паспортныеданные

ADD FOREIGN KEY (ид_работника) REFERENCES Работник(ид); ALTER TABLE Адрес

ADD FOREIGN KEY (ид_работника) REFERENCES Работник(ид); ALTER TABLE Гражданство

ADD FOREIGN KEY (ид_работника) REFERENCES Работник(ид); ALTER TABLE Знаниеиностранныхязыков

ADD FOREIGN KEY (ид_работника) REFERENCES Работник(ид); ALTER TABLE Дети

ADD FOREIGN KEY (ид_работника) REFERENCES Работник(ид); ALTER TABLE Образование

ADD FOREIGN KEY (ид_работника) REFERENCES Работник(ид); ALTER TABLE Историяработы

ADD FOREIGN KEY (ид_работника) REFERENCES Работник(ид); ALTER TABLE Основнойконтракт

ADD FOREIGN KEY (ид_работника) REFERENCES Работник(ид); ALTER TABLE Дополнительное соглашение

ADD FOREIGN KEY (ид_работника) REFERENCES Работник(ид); ALTER TABLE Дополнительное соглашение

ADD FOREIGN KEY (номерконтракта, дата заключения контракта) REFERENCES Основной_контракт(номер_контракта, дата заключения); ALTER TABLE Награждение

ADD FOREIGN KEY (ид_работника) REFERENCES Работник(ид); ALTER TABLE Поощрение

ADD FOREIGN KEY (ид_работника) REFERENCES Работник(ид); ALTER TABLE Повышение квалификации

ADD FOREIGN KEY (ид_работника) REFERENCES Работник(ид);

/

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1) Мартин Дж. Организация баз данных в вычислительных системах: пер. с англ. / Дж. Мартин. - 2-е изд., доп. - М.: Мир, 1980. - 662 с.

2) Дейт К. Дж. Введение в системы баз данных: Пер. с англ / К. Дж. Дейт. - 6-е издание. - К.; М.; СПб.: Издательский дом «Вильяме». - 2000. - 848 с.

3) Олле Т.В. Предложения КОДАСИЛ по управлению базами данных: пер. с англ. / Т.В. Олле; Пер. В.И. Филиппов; С.М. Кругова. - 1981: Фи­нансы и статистика, 1981. - 286 с.

4) Godd E.F. A Relation Model of Data for Large Shared Data Banks. Communications of the ACM 13:6, 1970, P. 377-387.

5) History of IBM // http://www-03.ibm.com/ibm/history/

6) Andy Oppel. Databases Demystified. - San Francisco, CA: McGraw- Hill Osborne Media., 2006 - pp. 90-91. - ISBN 0-07-225364-9

7) ISO/IEC 9075-11:2008: Information and Definition Schemas (SQL/Schemata) // http://www.iso.org/iso/home.html

8) O'Reilly Network. An Interview with Chris Date by Tony Williams // http://www.oreillynet.eom/lpt/a/6060

9) Oracle Database SQL Reference lOg - Oracle Corporation, Release 2 (10.2), 2005.

10) ANSI Standard SQL Joins, by Jonathan Gennick: журнал Oracle Maga­zine, no.6, 2001 (/oramag/oracle/01-nov/o6 lansi.html)

11) Barker R. Case* Method - Entity Relationship Modelling / R. Barker. - Addison Wesley Professional, Great Britain, 1990.

12) Перегудов Ф.И., Тарасенко Ф.П. Основы системного анализа: Учеб. 2-е изд., доп. - Томск: Изд-во НТЛ, 1997. - 396 е.: ил.

13) Основы системного подхода и их приложение к разработке терри­ториальных автоматизированных систем управления / Под ред. Ф.И. Перегудова. - Томск: Изд-во Томского ун-та, 1976. - 243 с.

14) Перегудов Ф.И., Сагатовский В.Н., Ямпольский В.З., Кочнев Л.В. Принципы декомпозиции целей и методика построения целей в систе­мах организационного управления // Кибернетика и вуз. Томск, 1975. Вып.8. С. 3-20.

15) Чудинов И. Л. Интеграционный подход к концептуальному проек­тированию информационной базы единой информационной среды / И. Л. Чудинов, И. В. Исаев // Материалы шестой Всероссийской научно- технической конференции «Теоретические и прикладные вопросы со­временных информационных технологий», Улан-Удэ, 2005.

16) Kim Y.-G. Comparing Data Modeling Formalisms / Y.-G. Kim, S.T. March // Communications of the ACM. - 1995. - Vol. 38, No. 6. - P. 103- 115.

17) Аносов А. Критерии выбора СУБД при создании информационных систем // www.interface.ru

Учебное издание

ЧУДИНОВ Игорь Леонидович ОСИПОВА Виктория Викторовна

БАЗЫ ДАННЫХ

Учебное пособие