Постановка задачи icon

Постановка задачи


2 чел. помогло.




Скачать 309.53 Kb.
НазваниеПостановка задачи
Дата конвертации15.01.2013
Размер309.53 Kb.
ТипРеферат
Содержание


Введение 3

Постановка задачи 4

1. Проектирование структуры базы данных 5

1.1. Техническое задание 6

1.2. Концептуальное проектирование 8

1.3. Логическое проектирование 14

18

2. Выбор серверной платформы (СУБД) 19

3. Физическое проектирование. Реализация базы данных на платформе Microsoft SQL Server 22

4. Типовые процедуры администрирования базы данных 27

27

5. Типовые запросы к базе данных 28

6. Оценка качества базы данных 29

Заключение 31

Список использованной литературы 32



Введение



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

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


Постановка задачи



Цель разработки:

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

  2. Выбрать программную платформу для физической реализации проекта БД.

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

  4. Разработать основные процедуры администрирования БД.

  5. Предложить типовые запросы к БД на языке запросов выбранной серверной платформе.

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



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



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

Основные этапы жизненного цикла ПС:

1. Планирование разработки БД. Планирование наиболее эффективного способа реализации этапов жизненного цикла системы.

2. Определение требований к системе. Определение диапазона действий и границ приложения БД, состава его пользователей и областей применения.

3. Сбор и анализ требований пользователей. Сбор и анализ требований из всех возможных областей применения.

4. Проектирование БД. Полный цикл разработки включает концептуальное, логическое и физическое проектирование БД.

5. Выбор целевой СУБД.

Следующие этапы жизненного цикла системы выходят за рамки проектирования БД:


6. Разработка приложений.

7. Создание прототипов.

8. Реализация.

9. Преобразование и загрузка данных.

10. Тестирование.

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


1.1. Техническое задание



Основанием для начала проектирования служит техническое задание (ТЗ).

ТЗ для задачи проектирования БД учета заработной платы в поликлинике оформляется согласно ГОСТ 19.201-78.

1. Введение.

Наименование разработки: База данных по учету заработной платы в поликлинике.

Область применения: бухгалтерия.

2. Основания для разработки: Приказ руководства поликлиники

3. Назначение разработки: база данных для использования в комплексе бухгалтерских программ поликлиники.

4. Требования к программе.

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

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

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

По составу и параметрам технических средств: нормальное функционирование на сервере поликлиники.

По информационной и программной совместимости: функционирование на базе операционной системы Microsoft Windows Server 2003.

По защите информации: соответствие уровню безопасности С2.

5. Требования к программной документации.

Документация согласно РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов

6. Технико-экономические показатели

7. Стадии и этапы разработки

8. Порядок контроля и приемки


1.2. Концептуальное проектирование



Концептуальное проектирование – процесс создания модели используемой информации, не зависящей от любых физических аспектов ее представления.

Этапы разработки концептуальной модели:


1. Определение типов сущностей

Таблица 1. Сущности

Сущность

(Entity)

Описание

Worker

Работник, получающий зарплату в поликлинике

Phase

Фаза изменения работника

Work

Некоторая работа, за которую работник получает некоторую зарплату

Job

Должность

Tariff

Тариф, по которому ведется оплата

Ratio

Разряд

Division

Подразделение поликлиники

Charge

Вид начисления

Hold

Вид удержания

Calc

Расчет зарплаты конкретному работнику за конкретный месяц

Charging

Начисление по расчету

Holding

Удержание по расчету


2. Определение типов связей

Таблица 2. Связи

Связь

(Relation)

Описание

WorkerPhase

Данные работника изменяются с течением времени

DivisionPhase

Работник числится в конкретном подразделении поликлиники

JobPhase

Работник числится на конкретной должности

RatioPhase

Работник имеет конкретный разряд

RatioTariff

Тариф изменяется в зависимости от разряда

ChargePhase

Работник получает конкретные виды начислений

HoldPhase

Работник имеет конкретные виды удержаний с зарплаты

PhaseWork

Работник выполнил конкретные работы

PhaseCalc

Работнику произведен расчет зарплаты на конкретный месяц

CalcCharging

Начисление по расчету зарплаты

CalcHolding

Удержание по расчету зарплаты

ChargeCharging

Начисление произведено по конкретному виду начислений

HoldHolding

Удержание произведено по конкретному виду удержаний

ChargeWork

Начисление произведено по конкретной работе


Для большей наглядности и удобства представления следует использовать ER-диаграмму.





Рисунок 1. Диаграмма Entity-Relation (Сущность-связь)


3. Определение атрибутов и связывание их с типами сущностей и связей

Таблица 3. Атрибуты

Сущность

Атрибут

Описание

Тип данных

Пустые значения

Worker

WorkerId

Идентификатор работника

Целое

Нет

DOB

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

Дата

Нет

Sex

Пол

Символ

Нет

Phase

PhaseId

Идентификатор фазы

Целое

Нет

Surname

Фамилия

Строка

Нет

Name

Имя

Строка

Нет

Patronymic

Отчество

Строка

Да

Tabel

Табельный номер

Целое

Нет

Child

Количество детей

Целое

Да

Work

WorkId

Идентификатор работы

Целое

Нет

Start

Время начала работы

Время

Нет

Duration

Продолжительность работы

Число

Нет

Rate

Коэффициент пересчета

Число

Нет

Job

JobId

Идентификатор должности

Целое

Нет

Name

Наименование должности

Строка

Да

Tariff

TariffId

Идентификатор тарифа

Целое

Нет

Rate

Тарифный коэффициент

Число

Нет

TariffYear

Год действия тарифной сетки

Целое

Нет

Ratio

RatioId

Номер разряда

Целое

Нет

Division

DivId

Идентификатор подразделения

Целое

Нет

Name

Наименование подразделения

Строка

Да

Charge

ChargeId

Идентификатор вида начисления

Целое

Нет

Name

Наименование вида начисления

Строка

Да

Hold

HoldId

Идентификатор вида удержания

Целое

Нет

Name

Наименование вида удержания

Строка

Да

Percent

Процент удержания

Число

Нет

LimitUp

Верхний предел

Денежное

Да

LimitDown

Нижний предел

Денежное

Да

Calc

CalcId

Идентификатор расчета

Целое

Нет

CalcMonth

Месяц на который выполнен расчет

Целое

Нет

CalcYear

Год расчета

Целое

Нет

Charging

ChargingId

Идентификатор начисления

Целое

Нет

Summa

Сумма начисления

Денежное

Нет

Holding

HoldingId

Идентификатор удержания

Целое

Нет

Summa

Сумма удержания

Денежное

Нет



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

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

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

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

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

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

В нашей модели альтернативных первичных ключей не выявлено.


5. Проверка модели на отсутствие избыточности.

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

1. Повторное исследование связей «один к одному»

2. Удаление избыточных связей.

В нашей модели избыточности данных не выявлено.

6. Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям.

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

Например: Проверим соответствие модели транзакции расчета зарплаты конкретному работнику на конкретный месяц по тарифному окладу:

Работник – Worker

Текущие данные по работнику – Phase по связке WorkerPhase

Значение разряда – Ratio по связке RatioPhase

Значения тарифа – Tariff по связке RatioTariff

Работы, выполненные работником в заданном месяце – Work по связке PhaseWork.

Транзакцию можно также отобразить на ER-диаграмме модели БД:

Рисунок 2. Проверка транзакции с помощью пути выполнения


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

1.3. Логическое проектирование



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

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

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

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

Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

1. каждый элемент таблицы - один элемент данных

2. все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.)

3. каждый столбец имеет уникальное имя

4. одинаковые строки в таблице отсутствуют

5. порядок следования строк и столбцов может быть произвольным


Этапы логического проектирования реляционной базы данных следующие:

1. Исключение особенностей, не совместимых с реляционной моделью.

На этом этапе выполняется следующие операции:

1) удаление двухсторонних связей «многие ко многим»

2) удаление рекурсивных связей «многие ко многим»

3) удаление сложных связей

4) удаление многозначных атрибутов

В концептуальной модели БД имеются 2 связи вида «многие ко многим»: HoldPhase и ChargePhase. Это означает, что работник может иметь по нескольку видов начислений и удержаний, равно как и 1 вид удержаний или начислений может быть у нескольких работников. Поскольку реляционная модель данных не поддерживает такой тип связи, необходимо выполнить декомпозицию, заменив связь «многие ко многим» на 2 связи «один ко многим».

Таблица 4. Новые сущности для декомпозиции связей «многие ко многим»

Сущность

Описание

Chargeit

Вид начисления у конкретного работника

Holdit

Вид удержания у конкретного работника


Таблица 5. Новые связи для декомпозиции связей «многие ко многим»

Связь

Описание

PhaseChargeit

Работник имеет конкретный вид начисления

PhaseHoldit

Работник имеет конкретный вид удержания

ChargeChargeit

Начисление назначено конкретному работнику

HoldHoldit

Удержание назначено конкретному работнику



2. Формирование отношений на основе логической модели данных.

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

Связь между сущностями отображается с помощью механизма «первичный ключ/внешний ключ». Поэтому для каждой подчиненной по связи сущности необходимо перенести в нее атрибуты первичного ключа родительской сущности.

Таблица 6. Внешние ключи

Сущность

Атрибут

Описание

Phase

WorkerId

Идентификатор работника

DivId

Идентификатор подразделения

JobId

Идентификатор должности

RatioId

Номер разряда

Work

PhaseId

Идентификатор работника

Tariff

RatioId

Номер разряда

Chargeit

PhaseId

Идентификатор работника

ChrargeId

Идентификатор вида начисления

WorkId

Идентификатор работы

Holdit

PhaseId

Идентификатор работника

HoldId

Идентификатор вида удержания

Calc

PhaseId

Идентификатор работника

Charging

ChargeId

Идентификатор вида начисления

CalcId

Идентификатор расчета

Holding

HoldId

Идентификатор вида удержания

CalcId

Идентификатор расчета


3. Проверка отношений с использованием средств нормализации.

Процесс нормализации включает следующие основные этапы:

1) приведение к 1-й нормальной форме, позволяющее удалить из отношений повторяющиеся группы атрибутов

2) приведение ко 2-й нормальной форме, позволяющее устранить частичную зависимость атрибутов от первичного ключа

3) приведение к 3-й нормальной форме, позволяющее устранить транзитивную зависимость атрибутов от первичного ключа.

4) приведение к нормальной форме Бойса-Кодда, позволяющее удалить из функциональных зависимостей оставшиеся аномалии.


4. Проверка применимости отношений для выполнения пользовательских транзакций.

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


5. Определение ограничений целостности.

Ограничения целостности данных вводятся с целью предотвратить появление в базе противоречивых данных.

Типы ограничений целостности:

  1. Обязательные данные

  2. Ограничения для доменов атрибутов

  3. Целостность сущностей

  4. Ссылочная целостность

  5. Ограничения предметной области


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

2. Выбор серверной платформы (СУБД)



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

Можно выделить несколько групп критериев выбора СУБД:


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

  1. Используемая модель данных..

  2. Триггеры и хранимые процедуры.

  3. Средства поиска.

  4. Предусмотренные типы данных..

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


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

  1. Мобильность. Независимость системы от среды, в которой она работает.

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

  3. Распределенность.

  4. Сетевые возможности.


3. Контроль работы системы

  1. Контроль использования памяти компьютера.

  2. Автонастройка.


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

  1. Средства проектирования.

  2. Многоязыковая поддержка..

  3. Возможности разработки Web-приложений.

  4. Поддерживаемые языки программирования.


5. Производительность

  1. Рейтинг TPC (Transactions per Cent). Отношение количества запросов обрабатываемых за некий промежуток времени к стоимости всей системы.

  2. Возможности параллельной архитектуры.

  3. Возможности оптимизирования запросов..


6. Надежность

  1. Восстановление после сбоев.

  2. Резервное копирование.

  3. Откат изменений.

  4. Многоуровневая система защиты.



7. Требования к рабочей среде

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

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

  3. Максимальный размер адресуемой памяти.

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


8. Смешанные критерии

  1. Качество и полнота документации.

  2. Локализованность.

  3. Модель формирования стоимости.

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

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


Расчет интегрального показателя выбора СУБД по требованиям задачи:

Таблица 7. Интегральные показатели по различным СУБД

Показатель

Весовой коэффициент

СУБД

SQL Server 2005

MySQL

Oracle

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

1

7

3

6

Функциональные возможности

2

8

6

9

Контроль

1,8

8

5

9

Разработка приложений

2,5

9

5

7

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

2

8

7

9

Надежность

2,5

8

4

8

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

2

9

7

7

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

0,5

6

9

5

Итого: 

116,9

79

112,2


Для программной реализации базы данных учета зарплаты в поликлинике выбирается система управления базами данных Microsoft SQL Server 2005 в редакции Standard Edition.

Microsoft SQL Server использует в качестве языка запросов Transact-SQL (T-SQL) - процедурное расширение языка SQL.

3. Физическое проектирование. Реализация базы данных на платформе Microsoft SQL Server



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

USE [clinic]


SET ANSI_NULLS ON

SET QUOTED_IDENTIFIER ON


CREATE TABLE [dbo].[Charge](

[ChargeId] [int] IDENTITY(1,1) NOT NULL,

[Name] [nvarchar](50) NULL,

CONSTRAINT [PK_Charge] PRIMARY KEY CLUSTERED

(

[ChargeId] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]


CREATE TABLE [dbo].[Division](

[DivId] [int] IDENTITY(1,1) NOT NULL,

[Name] [nvarchar](50) NULL,

CONSTRAINT [PK_Division] PRIMARY KEY CLUSTERED

(

[DivId] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]


CREATE TABLE [dbo].[Hold](

[HoldId] [int] IDENTITY(1,1) NOT NULL,

[Name] [nvarchar](50) NULL,

[Percent] [float] NOT NULL CONSTRAINT [DF_Hold_Percent] DEFAULT ((0)),

[LimitUp] [money] NULL,

[LimitDown] [money] NULL,

CONSTRAINT [PK_Hold] PRIMARY KEY CLUSTERED

(

[HoldId] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]


CREATE TABLE [dbo].[Job](

[JobId] [int] IDENTITY(1,1) NOT NULL,

[Name] [nvarchar](50) NULL,

CONSTRAINT [PK_Job] PRIMARY KEY CLUSTERED

(

[JobId] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]


CREATE TABLE [dbo].[Ratio](

[RatioId] [int] NOT NULL,

CONSTRAINT [PK_Ratio] PRIMARY KEY CLUSTERED

(

[RatioId] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]


CREATE TABLE [dbo].[Worker](

[WorkerId] [int] IDENTITY(1,1) NOT NULL,

[DOB] [smalldatetime] NOT NULL,

[Sex] [nvarchar](1) NOT NULL CONSTRAINT [DF_Worker_Sex] DEFAULT (N'M'),

CONSTRAINT [PK_Worker] PRIMARY KEY CLUSTERED

(

[WorkerId] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]


CREATE TABLE [dbo].[Charging](

[ChargingId] [int] IDENTITY(1,1) NOT NULL,

[Summa] [money] NULL,

[ChargeId] [int] NULL,

[WorkId] [int] NULL,

[CalcId] [int] NULL,

CONSTRAINT [PK_Charging] PRIMARY KEY CLUSTERED

(

[ChargingId] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]


CREATE TABLE [dbo].[Holding](

[HoldingId] [int] IDENTITY(1,1) NOT NULL,

[Summa] [money] NULL,

[HoldId] [int] NULL,

[CalcId] [int] NULL,

CONSTRAINT [PK_Holding] PRIMARY KEY CLUSTERED

(

[HoldingId] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]


CREATE TABLE [dbo].[ChargeIt](

[ChargeId] [int] NOT NULL,

[PhaseId] [int] NOT NULL,

CONSTRAINT [PK_ChargeIt] PRIMARY KEY CLUSTERED

(

[ChargeId] ASC,

[PhaseId] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]


CREATE TABLE [dbo].[Phase](

[PhaseId] [int] IDENTITY(1,1) NOT NULL,

[WorkerId] [int] NULL,

[Surname] [nvarchar](50) NULL,

[Name] [nvarchar](50) NULL,

[Patronymic] [nvarchar](50) NULL,

[Tabel] [nvarchar](12) NULL,

[Child] [tinyint] NULL,

[DivId] [int] NULL,

[JobId] [int] NULL,

[RatioId] [int] NULL,

CONSTRAINT [PK_Phase] PRIMARY KEY CLUSTERED

(

[PhaseId] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]


CREATE TABLE [dbo].[Holdit](

[HoldId] [int] NOT NULL,

[PhaseId] [int] NOT NULL,

CONSTRAINT [PK_Holdit] PRIMARY KEY CLUSTERED

(

[HoldId] ASC,

[PhaseId] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]


CREATE TABLE [dbo].[Calc](

[CalcId] [int] IDENTITY(1,1) NOT NULL,

[CalcMonth] [smallint] NULL,

[CalcYear] [smallint] NULL,

[PhaseId] [int] NULL,

CONSTRAINT [PK_Calc] PRIMARY KEY CLUSTERED

(

[CalcId] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]


CREATE TABLE [dbo].[Work](

[WorkId] [int] IDENTITY(1,1) NOT NULL,

[Start] [datetime] NOT NULL,

[Duration] [smallint] NOT NULL,

[Rate] [int] NOT NULL CONSTRAINT [DF_Work_Rate] DEFAULT ((1)),

[PhaseId] [int] NOT NULL,

CONSTRAINT [PK_Work] PRIMARY KEY CLUSTERED

(

[WorkId] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]


CREATE TABLE [dbo].[Tariff](

[TariffId] [int] IDENTITY(1,1) NOT NULL,

[Rate] [float] NOT NULL CONSTRAINT [DF_Tariff_Rate] DEFAULT ((1)),

[TariffYear] [smallint] NOT NULL,

[RatioId] [int] NOT NULL,

CONSTRAINT [PK_Tariff] PRIMARY KEY CLUSTERED

(

[TariffId] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]


ALTER TABLE [dbo].[Calc] WITH CHECK ADD CONSTRAINT [FK_Calc_Phase] FOREIGN KEY([PhaseId])

REFERENCES [dbo].[Phase] ([PhaseId])

ON DELETE CASCADE

ALTER TABLE [dbo].[Calc] CHECK CONSTRAINT [FK_Calc_Phase]

ALTER TABLE [dbo].[ChargeIt] WITH CHECK ADD CONSTRAINT [FK_ChargeIt_Charge] FOREIGN KEY([ChargeId])

REFERENCES [dbo].[Charge] ([ChargeId])

ON DELETE CASCADE

ALTER TABLE [dbo].[ChargeIt] CHECK CONSTRAINT [FK_ChargeIt_Charge]

ALTER TABLE [dbo].[ChargeIt] WITH CHECK ADD CONSTRAINT [FK_ChargeIt_Phase] FOREIGN KEY([PhaseId])

REFERENCES [dbo].[Phase] ([PhaseId])

ON DELETE CASCADE

ALTER TABLE [dbo].[ChargeIt] CHECK CONSTRAINT [FK_ChargeIt_Phase]

ALTER TABLE [dbo].[Charging] WITH CHECK ADD CONSTRAINT [FK_Charging_Calc] FOREIGN KEY([CalcId])

REFERENCES [dbo].[Calc] ([CalcId])

ON DELETE CASCADE

ALTER TABLE [dbo].[Charging] CHECK CONSTRAINT [FK_Charging_Calc]

ALTER TABLE [dbo].[Charging] WITH CHECK ADD CONSTRAINT [FK_Charging_Charge] FOREIGN KEY([ChargeId])

REFERENCES [dbo].[Charge] ([ChargeId])

ON DELETE CASCADE

ALTER TABLE [dbo].[Charging] CHECK CONSTRAINT [FK_Charging_Charge]

ALTER TABLE [dbo].[Charging] WITH CHECK ADD CONSTRAINT [FK_Charging_Work] FOREIGN KEY([WorkId])

REFERENCES [dbo].[Work] ([WorkId])

ALTER TABLE [dbo].[Charging] CHECK CONSTRAINT [FK_Charging_Work]

ALTER TABLE [dbo].[Holding] WITH CHECK ADD CONSTRAINT [FK_Holding_Calc] FOREIGN KEY([CalcId])

REFERENCES [dbo].[Calc] ([CalcId])

ON DELETE CASCADE

ALTER TABLE [dbo].[Holding] CHECK CONSTRAINT [FK_Holding_Calc]

ALTER TABLE [dbo].[Holding] WITH CHECK ADD CONSTRAINT [FK_Holding_Hold] FOREIGN KEY([HoldId])

REFERENCES [dbo].[Hold] ([HoldId])

ON DELETE CASCADE

ALTER TABLE [dbo].[Holding] CHECK CONSTRAINT [FK_Holding_Hold]

ALTER TABLE [dbo].[Holdit] WITH CHECK ADD CONSTRAINT [FK_Holdit_Hold] FOREIGN KEY([HoldId])

REFERENCES [dbo].[Hold] ([HoldId])

ON DELETE CASCADE

ALTER TABLE [dbo].[Holdit] CHECK CONSTRAINT [FK_Holdit_Hold]

ALTER TABLE [dbo].[Holdit] WITH CHECK ADD CONSTRAINT [FK_Holdit_Phase] FOREIGN KEY([PhaseId])

REFERENCES [dbo].[Phase] ([PhaseId])

ON DELETE CASCADE

ALTER TABLE [dbo].[Holdit] CHECK CONSTRAINT [FK_Holdit_Phase]

ALTER TABLE [dbo].[Phase] WITH CHECK ADD CONSTRAINT [FK_Phase_Division] FOREIGN KEY([DivId])

REFERENCES [dbo].[Division] ([DivId])

ON DELETE CASCADE

ALTER TABLE [dbo].[Phase] CHECK CONSTRAINT [FK_Phase_Division]

ALTER TABLE [dbo].[Phase] WITH CHECK ADD CONSTRAINT [FK_Phase_Job] FOREIGN KEY([JobId])

REFERENCES [dbo].[Job] ([JobId])

ON DELETE SET NULL

ALTER TABLE [dbo].[Phase] CHECK CONSTRAINT [FK_Phase_Job]

ALTER TABLE [dbo].[Phase] WITH CHECK ADD CONSTRAINT [FK_Phase_Ratio] FOREIGN KEY([RatioId])

REFERENCES [dbo].[Ratio] ([RatioId])

ON DELETE CASCADE

ALTER TABLE [dbo].[Phase] CHECK CONSTRAINT [FK_Phase_Ratio]

ALTER TABLE [dbo].[Phase] WITH CHECK ADD CONSTRAINT [FK_Phase_Worker] FOREIGN KEY([WorkerId])

REFERENCES [dbo].[Worker] ([WorkerId])

ON DELETE CASCADE

ALTER TABLE [dbo].[Phase] CHECK CONSTRAINT [FK_Phase_Worker]

ALTER TABLE [dbo].[Tariff] WITH CHECK ADD CONSTRAINT [FK_Tariff_Ratio] FOREIGN KEY([RatioId])

REFERENCES [dbo].[Ratio] ([RatioId])

ON DELETE CASCADE

ALTER TABLE [dbo].[Tariff] CHECK CONSTRAINT [FK_Tariff_Ratio]

ALTER TABLE [dbo].[Work] WITH CHECK ADD CONSTRAINT [FK_Work_Phase] FOREIGN KEY([PhaseId])

REFERENCES [dbo].[Phase] ([PhaseId])

ON DELETE CASCADE

ALTER TABLE [dbo].[Work] CHECK CONSTRAINT [FK_Work_Phase]


4. Типовые процедуры администрирования базы данных



Администрирование и поддержка базы данных на базе Microsoft SQL Server включает следующие основные процедуры:

1. Настройка прав доступа и аудита.

2. Конфигурирование

3. Резервное копирование и ведение журналов транзакций

4. Мониторинг и регулировка параметров для обеспечения необходимой производительности системы.


Процедуры администрирования могут выполняться с помощью штатной консолидированной среды управления SQL Server Management Studio.


5. Типовые запросы к базе данных



Типовые транзакции для применения разработанной базы данных:


1. Расчет суммы начислений заданного работника на заданный месяц года по тарифному окладу:

select sum(T.Rate * W.Duration * W.Rate)

from Phase P

join Work W on W.PhaseId = P.PhaseId

join Tariff T on T.RatioId = P.RatioId and T.TariffYear = @year

where year(W.Start) = @year and month(W.Start) = @month


2. Запрос рассчитанной зарплаты всех работников по заданному подразделению в заданный месяц года:

select P.PhaseId, P.Surname, sum(Ch.Summa) - sum(H.Summa)

from Phase P

join Calc C on C.PhaseId = P.PhaseId

left outer join Charging Ch on Ch.CalcId = C.CalcId

left outer join Holding H on H.CalcId = C.CalcId

where P.DivId = @div and C.CalcYear = @year and C.CalcMonth = @month

group by P.PhaseId, P.Surname


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

select C.CalcMonth, sum(Ch.Summa) - sum(H.Summa)

from Phase P

join Calc C on C.PhaseId = P.PhaseId

left outer join Charging Ch on Ch.CalcId = C.CalcId

left outer join Holding H on H.CalcId = C.CalcId

where P.WorkerId = @div and C.CalcYear = @year

group by C.CalcMonth

6. Оценка качества базы данных



Оценка качества БД может быть проведена согласно международному стандартe ISO 9126:1991 (ГОСТ Р ИСО / МЭК 9126-93). Этот стандарт регламентирует группы характеристик, по которым необходимо оценивать качество любых программных средств, в том числе и баз данных


1. Корректность или достоверность данных - это степень соответствия информации об объектах в БД реальным объектам вне ЭВМ в данный момент времени, определяющаяся изменениями самих объектов, некорректностями записей о их состоянии или некорректностями расчетов их характеристик.

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

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

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

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

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

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

8. Временная эффективность БД определяется длительностью выполнения заданных функций и ожидания результатов от БД в средних и/или наихудших случаях, с учетом приоритетов задач.

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

10. Практичность-применимость - зачастую значительно определяет функциональную пригодность и полезность применения БД для квалифицированных пользователей.

11. Понятность зависит от качества документации и субъективных впечатлений потенциальных пользователей от функций и характеристик ИБД. В

12. Простота использования БД - возможность удобно и комфортно ее эксплуатировать и управлять данными.

13. Изучаемость может определяться требованиями ограниченной трудоемкости и длительности подготовки пользователя к полноценной эксплуатации информации БД.

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

15. Мобильность данных БД, можно характеризовать в системном проекте в основном длительностью и трудоемкостью их инсталляции, адаптации и замещаемости при переносе ИБД на иные аппаратные и операционные платформы.

Заключение



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

Список использованной литературы



1. ГОСТ 19.201-78. «Техническое задание. Требования к содержанию и оформлению».

2. ГОСТ Р ИСО/МЭК 9126-93 «Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению».

3. Кириллов В.В., Громов Г.Ю. Введение в реляционные базы данных. - СПб: БХВ-Петербург, 2008 - 464с.

3. Конолли Т., Бегг К. Базы данных, проектирование, реализация и сопровождение. Теория и практика. 3-е издание. : Пер. с англ. – М.: Издательский дом «Вильяме», 2003. – 1440 с.

4. Станек У.Р. Microsoft SQL Server 2005. Справочник администратора. : Пер. с англ. – М.: Издательство «Русская Редакция», 2006. – 544 с.


плохо
  1
отлично
  2
Ваша оценка:

Похожие:

Постановка задачи icon1. постановка задачи
285.2kb.  
Постановка задачи icon1. постановка задачи
281.5kb.  
Постановка задачи iconПостановка задачи
46kb.  
Постановка задачи icon1. Постановка задачи
115.8kb.  
Постановка задачи iconПостановка задачи
307.4kb.  
Постановка задачи iconПостановка задачи
306.8kb.  
Постановка задачи iconИсходный код программы Условие задачи Разработка информационно-поисковой системы по подержанным автомобилям. Постановка задачи
332.7kb.   При разработке информационно-справочной системы по подержанным автомобилям было сформулировано две основных задачи
Постановка задачи icon1. 1 Постановка задачи и ее анализ
116.5kb.  
Постановка задачи iconРезультаты выполнения программы 12 12 13 2 задача линейного программирования 14 1 постановка задачи 14
228.9kb.  
Постановка задачи iconТехническое задание а Обоснование перспективности реализуемого проекта: постановка задачи
824.6kb.  
Разместите кнопку на своём сайте:
Рефераты


База данных защищена авторским правом ©CoolReferat 2000-2018
обратиться к администрации | правообладателям | пользователям
Основная база рефератов
Рефераты