Проектирование подсистемы "Учета труда и заработная плата"

;nf - .. . :

манипуляции с ними (в виде связей). Реляционная модель предполагает 3 концеп- flffr*¹* |1 ' ■ ^! I

туальных элемента: структура, целостность и обработка данных.

      Преобразование модели «сущность-связь» в реляционную модель ОСуЩеСТВ-

^М;; ' : ■ •

ляется путём последовательного выполнения ряда шагов:

К, Ц

      Каждой сущности ставится в соответствие отношение реляционной модели данных.

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

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

IBB IP®' •

или недопустимость Null значений для него.

W#!^r

      Таким образом, в результате преобразования получаем следующие отношения:

• должности;
• работники;
• отпуск;
• табель использования рабочего времени;
• платежная ведомость;

|

! у 11 - листок неработоспособности.

'Jllil^ipf si '

      Переименование атрибутов должно происходить в соответствии с теми же

Шщ

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

      Первичный ключ сущности становится первичным ключом соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автомати- чески получают свойство обязательности (Not Null).

      В каждое отношение, соответствующее подчинённой сущности добавляется набор атрибутов основной сущности, являющейся первичным ключом основной

I ! :

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

mnf' - ¹

      Для моделирования необязательного типа связи на физическом уровне у ат- м рибутов соответствующих внешнему ключу, устанавливается свойство допустимых неопределённых значений (признак Null). При обязательном типе связи атрибуты получают свойство отсутствия неопределённых значений (признак Not

jjfp

Null).

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

fw- * г ■

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

щм

возможности переходов к подтипам от супертипа необходимо в супертип вклю-

fpr^lp" ' ¹¹ ■ '

чить идентификатор связи.

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

;тгг  ^;

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

только идентификатор супертипа в подтипы или наследуются все атрибуты су-

ПШ'Ь пертипа.

|г:|1Й'

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

\щф

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

щг • 1 ^! .

требованиям нормализации.

      Чаще всего нормализация осуществляется в виде нескольких иоследова-

      I.

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

1.1- ¹ ' ;

      Проанализировав модель, отметим, что проектируемая база данных нахо-

!

дится в третьей нормальной форме и дальнейшей нормализации не требует.

      Проверка модели относительно транзакций пользователя позволяет убедится в том, что ЕЯ-модель позволяет выполнить все предусмотренные транзак-

.

ции. ЕЯ-модель должна выдавать данные в полном объеме согласно запросам пользователей.

      Для проверки модели относительной транзакций пользователей определим список транзакций из описания предметной области. В него войдут: ввод новых данных в таблицы базы данных, удаление записей из таблиц, выборка информа- | ции (выполнение запросов). Разработанная модель позволяет осуществить пользователям данный список транзакций.

      Реляционная модель представлена на рисунке В.4. 

      4.5 Физическое проектирование таблиц базы данных

      Физическое проектирование базы данных - процесс создания описания реа-

1ЩИШ¹

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

      Основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных. В случае реляционной модели данных под этим подразумевается следующее:

• создание набора реляционных таблиц и ограничений для них на основе ин- формации, представленной в логической модели данных;
• определение конкретных структур хранения данных и методов доступа к

Шрф^

ним, обеспечивающих оптимальную производительность системы с базой дан- ных;

• разработка средств защиты создаваемой системы.

      Фазы концептуального и логического проектирования следует отделять от фазы их физического проектирования. На это есть несколько причин:

• они связаны с совершенно разными аспектами системы: что делать и как делать;
• они выполняются в разное время, поскольку понять, что надо делать, следует прежде, чем решить, как это делать;
• они требуют совершенно разных навыков и умений, которыми обычно об- ладают разные люди

      Создание организованной структуры данных требует решения двух глобальных задач: необходимо спроектировать собственно базу данных (на этом этапе решается, какие именно данные будут храниться в базе данных и каким об-

и'И:

разом они будут организованы); необходимо спроектировать программу, которая

Щщ ■ I

будет организовывать доступ к базе данных.

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

• создаются таблицы БД;

т

фч-Фм- 

• вводятся необходимые ограничения;

I

• определяются ключевые поля;
• формируются связи между таблицами;
• обеспечиваются условия целостности данных;

■ г!

ЙЙ4

• вводя тся данные.

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

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

выполняться с этими значениями.

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

Р,- Т

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

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

      В ходе решения задачи была выбрана платформа Windows ХР от всемирно

I

известного производителя корпорации Microsoft. Эта платформа была выбрана по нескольким причинам:

• широкое распространение этой операционной системы в нашей стране;
• использование данной операционной системы на предприятии «1 оловной завод»;
• удобный, интуитивно понятный интерфейс;
• отсутствие проблем с совместимостью аппаратного обеспечения;
• работа в защищенном режиме.

      Для физического проектирования базы данных был выбран про!раммный

щ ■ ¹

продукт компании Microsoft - широко известный Microsoft Access. К преимуществам Access можно причислить: широкое распространение, возможность исполь-

зования непрофессиональным программистом.

! f - /«fr

■4

j'l'T". 
 

j'l'T". 
 

      Данная СУБД позволяет в полной мере реализовать спроектированную базу данных.

      Разработанная база данных должна соответствовать требованиям государственных стандартов Украины, бизнес правилам предприятия и действующему законодательству. Соответствие бизнес правилам предприятия должно отобра-

! ? V' ^!; & :

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

      С точки зрения пользователя, организация внутренней структуры сохране-

УК - "'! ■

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