Разработка базы данных «Служащие фирмы»

Как и утверждалось во всех источниках, проектирование БД — самая «размытая» деятельность среди прочих, имеющих место при проектировании КИС, и подчас трудно из разных вариантов организации структуры выбрать предпочтительный. В таких случаях обычно прикидывают варианты использования (как сидит оператор, и насколько ему очевидно, что к чему), а также направления будущего развития КИС. Первое я могу сделать, а, что касается второго, это задача аналитика. Я в области управления кадрами не эксперт, а, значит, на роль аналитика не претендую. Всё, за что отвечает аналитик, уже должно было быть в задании. Полного (стремящегося, хотя бы) списка запросов нет, его только додумывать. И если что, я не виноват.

Впрочем, в производство эта работа всё равно не пойдёт, так что последствия лишь гипотетические.

Задание: Разработать базу данных «Служащие фирмы»

Сведения:

Код работника,

Фамилия, имя, отчество,

Фото,

Дата рождения,

Пол,

Домашний адрес,

Семейное положение,

Сведения о ближайших родственниках,

Служебный и домашний телефоны,

Должность,

Подразделение,

Дата поступления на работу,

Служебные перемещения,

Образование, специальность, год окончания учебного заведения,

Ученая степень,

Почетные звания,

Заработная плата (по месяцам текущего года),

Дополнительные сведения (характеристика и др.)

Запросы:

Вывод сведений о работниках определенной должности (код, ФИО, подразделение, рабочий телефон),

Вывод сведений о работниках (ФИО, должность, подразделение), стаж работы которых на фирме не менее … лет,

Вывод сведений о заработной плате работника … за последний месяц, последний квартал,

Вывод сведений о семейном положении работника …

Вывод данных о работниках, имеющих ученую степень и возраст не более … лет.

Отчет: Вывод сведений о работниках, у которых в текущем году наступает пенсионный возраст

Комментарии: Не очевидно, что значит «Заработная плата (по месяцам текущего года)». Что значит, текущего? А за прошлые года выбрасывать, что ли? Нет, ну в принципе-то можно, тем или иным способом установить таймер, чтоб выкидывал лишнюю информацию, когда приходит время. Но в этом случае запрос «Вывод сведений о заработной плате работника … за последний месяц, последний квартал» будет невозможен в первые месяцы нового года. Если ближе к действительности, то данные из базы удаляются обычно только тогда, когда они были добавлены по ошибке. И удаляются незадолго после добавления. Либо, если нет места хранить всё, но современные ЖД не каждая организация доводит до исчерпания, и по-хорошему вместо удаления используется какая-нибудь галочка (логическая колонка в таблице) «сейчас не работает», «сейчас не существует», и т. п. Так что зарплата будет храниться за все месяцы, и удалением этих сведений я не буду заниматься.

Некоторые решения, возможно, не такие, какие подсказывает теория, но ближе к практике. Например, я вот вижу, что у сведений о работнике и сведений о родственниках некоторая общая структура. Ф. И. О., дата рождения. Я, вроде бы как должен вынести людей в отдельную таблицу. Должен, но не обязан. Я думаю, с этой дополнительной таблицей операторам только лишние заморочки будут. Если отец уже работает в фирме, тогда при добавлении сына/дочери нужно искать отца из списка работников. А если не работает, то добавлять нового человека. Добавление родственников можно автоматизировать, на форме добавления сотрудника поставить галочки «добавить отца в БД», «добавить мать в БД» и тут же под ними поля для ввода информации о них. Но в этом случае, что-то мне подсказывает, операторы будут создавать новые сущности «человек», даже, если они уже есть в БД. Так что людей я решил сделать (составным) доменом. Домены, определённые пользователем, поддерживает не каждая БД. MS SQL Server, по всей видимости, поддерживает, но проект на MS JET, так что логическому домену соответствуют физические однородные группы колонок.

Примерная схема базы данных такова:

Рис.

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

На данной схеме можно видеть несколько «перечисляемых» доменов. «Перечисляемых» в кавычках, потому что я не припомню такого термина в теоретических источниках. Называются так по аналогии с перечисляемыми типами в языках программирования. Это, например, Тип образования, Тип почётного звания, Типы учёных степеней, Подразделения и Должности. Последние два, правда, более материальны, нежели «Типы». Что касается Типов, то они могли бы быть доменами, если бы их можно было все предусмотреть. Например, домен Пол едва ли претерпит какие-либо изменения со временем, чего не скажешь про учёные степени. Мало ли, какие реформы грядут. Специальность (Образование) решил не выделять. Наверное, не надо.

Что касается образований, то их вполне может быть несколько, так что именно так я решил их и сделать. Ближе к правде.

Вот с историей служебных перемещений поинтереснее будет. Ну с прошлыми позициями понятно, их можно хранить в цепочке ЗДЗП. А текущую позицию где хранить? Варианты есть такие:

· Хранить в ЗДЗП историю всех служебных перемещений, в том числе и текущую позицию. В строке таблицы, соответствующей текущей должности, дата окончания должна быть установлена на какую-нибудь далёкую дату в будущем, в зависимости от БД. Впрочем, это уже детали реализации (т. е. физическая модель). В логической модели дата окончания должна, наверное, хранить NULL. В разных источниках процесс проектирования БД описывается поэтапно. Мне кажется (имел бы больше опыта, утверждал бы увереннее), это так же далеко от практики, как предположение, что программы рождаются в сознании разработчика строчка за строчкой. Я думаю так, как мне удобнее. Мне удобнее думать параллельно на нескольких уровнях, просматривая, как это в конечном счёте будет выглядеть на каждом этапе.

· Хранить в ЗДЗП все перемещения, а в таблице Работник дополнительно ссылаться на суррогатный ключ текущей позиции (Код ЗДЗП). Существенный факт присутствует в более, чем одном месте. И ничего взамен.

· Но если в таблице Работник хранить не ссылку на текущую позицию, а собственно информацию о текущей позиции: подразделение, должность. Хранить ли дату начала работ в текущей служебной позиции? На подобные вопросы должен отвечать перечень возможных запросов. Запрос на суммарный стаж я вижу, а вот, чтобы была выборка по сотрудникам, сколько они работают на текущем месте, такого нет. Но, впрочем, дату я всё же включил бы. Исходя из принципа наименьшего сюрприза.

· Для полноты можно добавить ещё один вариант: в ЗДЗП хранить все прошлые позиции, а информацию о текущей — в таблице Работник. Существенные факты в двух местах не присутствуют, но преимущество сомнительно. Или нет? В принципе, можно накатать представление (View), которое присоединяло бы (UNION) запись о текущей позиции к записям о прошлых позициях. Мудрёно как-то.

Решил остановиться на первом варианте. Предпоследний, в принципе, неплох, но в среде Access время на реализацию предпоследнего существенно больше.

Надо полагать, в теории темпоральных баз данных есть однозначные решения подобных проблем. Но ТБД я не увлекался. У баз данных есть такая проблема, что для них нужны данные, тем более для темпоральных. А данные взять как-то неоткуда, их только на предприятиях много.

Рис.

Вроде всё гладко. Я проблем здесь не вижу. Можно воплощать.

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

· работник, сотрудник, служащий — employee

· фамилия — last name

· имя — first name

· отчество — patronymic

· дата рождения — birthday

· пол — gender

· тип — kind

· семейное положение — marital status

· почётное звание — honorary title

· должность — employment

· подразделелние — department

· служебная позиция (комбинация должности и подразделения) — position (of employment)

· образование — education

· человек — person

· супруг — spouse

· учёная степень — scientific degree

· специальность — speciality

Схема физической модели, таким образом:

база данные логическая модель

Рис.

Используемая литература

1.Локальная версия INTUIT.ru, курс «Основы проектирования реляционных баз данных»

2.К. Кейт «Руководство по реляционной СУБД DB2»

3.ISBN 5—279—63—9

4.http://www.isve.ru/text/51