|
В принципе невозможна.
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)
);
3 ddl (data definition language) - язык определения данных, используемый для создания, изменения и удаления объектов БД
4.4. CASE-средства, используемые при проектировании БД
На сегодняшний день рынок CASE-средств, используемых для проектирования БД, представлен достаточно широко, среди популярных продуктов можно выделить следующие: Computer Associates AllFusion ERwin Data Modeler, Oracle Designer, Microsoft Office Visio, Sybase Power 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 (Integration DEFinition for Information Modeling). IDEF1X является методом для разработки реляционных БД и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы. IDEF1X подразумевает использование различных уровней моделирования при проектировании системы.
Клиент
|
| Предмет_заказа |
| Код_клиента (FK) Номер заказа (FK) Код_товара |
Заказ
|
| Рис. 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
|
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
|
| ^ПРЕПОДАВАТЕЛЬ (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 Magazine, 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
Учебное издание
ЧУДИНОВ Игорь Леонидович ОСИПОВА Виктория Викторовна
БАЗЫ ДАННЫХ
Учебное пособие
