БАЗА ДАННЫХ

ДЛЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ

«Таксопарк»

Пояснительная записка к курсовому проекту

по общепрофессиональной дисциплине

«Организация баз данных»

Специальность 552800 – Информатика и вычислительная

техника

Факультет

Кафедра

Курс 3

Семестр 6

2003

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

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

Информационная система «Таксопарк» предназначена для упрощения регулированием системы и для автоматизации её функций.

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

Раздел 1 посвящен выбору автоматизированных функций и информационного обеспечения. Здесь дается краткое описание предметной области; производится выбор и описание автоматизируемых функций; выполняется первичное описание информационного обеспечения.

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

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

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

Раздел 5 посвящен проектированию реляционной SQL-модели. Здесь выполняется перевод глобальной ER-модели в реляционную форму, специфицируются ограничения и правила поддержания целостности на реляционном уровне, записывается SQL-код для создания реляционной модели.

Раздел 6 посвящен проектированию представлений для автоматизируемых функций. Здесь выполняется определение путей доступа к данным для автоматизируемых функций, записывается SQL- код локальных просмотров для автоматизируемых функций.

1 ВЫБОР АВТОМАТИЗИРУЕМЫХ ФУНКЦИЙ И ИНФОРИАЦИОННОГО ОБЕСПЕЧЕНИЯ

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

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

1.1 Краткое описание предметной области

В данном подразделе дается краткое описание предметной области, в которой функционирует информационная система «Таксопарка». Описываются среда функционирования, объект и субъект управления, цели и задачи управления.

Таксопарк «Желтая Карета» является современным автотранспортным предприятием, которое оказывает услуги по перевозке людей на легковых автомобилях. Для состоятельных клиентов предусмотренная дополнительная услуга – VIP карта, которая позволяет накапливать скидку и оплачивать поездки со своего счета. Если поезда осуществляется одним клиентом в более чем один промежуточный пункт, а также, если нужно ждать клиента довольно продолжительное время, предусмотрена почасовая оплата с фиксированной таксой. Координирование водителей, принятие заказов у клиентов и их учет осуществляет операторская служба. Для автоматизации этого, а также и других процессов была разработана БД.

1.1.1 Среда функционирования

Среда функционирования системы «Таксопарк» включает область действий данного автотранспортного предприятия в пределах которой оно функционирует.

1.1.2 Объект управления

Объект управления представляет собой имеющиеся автомобили, водителей, рабочий персонал обеспечивающий перевозку клиентов.

1.1.3 Субъект управления (управляющая система)

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

1.1.4 Цели и задачи управления

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

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

1.1 Выбор и описание автоматизированных функций.

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

1.2.1 Перечень автоматизируемых функций

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

1) Учет сведений о сотрудниках.

2) Учет принятых вызовов.

3) Учет VIP клиентов.

4) Учет материальных средств.

5) Учет сведений о контрагентах (поставщиках).

1.2.2 Функция 1 «Учет сведений о сотрудниках».

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

1.2.3 Функция 2 «Учет принятых вызовов».

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

1.2.4 Функция 3 «Учет VIP клиентов».

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

1.2.5 Функция 4 «Учет материальных средств».

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

1.2.6 Функция 5 «Учет сведений о контрагентах (поставщиках)».

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

1.2.7 Сводка объектов, участвующих в реализации функций

Объекты предметной области, участвующие в реализации автоматизируемых функций, сведены в табл. 1.1.

Таблица 1.1 Сводка объектов, участвующих в реализации функций

1.3 Первичное описание информационного обеспечения

В данном подразделе дается первичное описание информационного обеспечения функций, выбранных для автоматизации. Информационное обеспечение каждой функции в виде совокупности атрибутов, необходимых для ее осуществления, с указанием объектов предметной области, которым принадлежат атрибуты, отражено в табл. 1.2–1.6.

Таблица 1.2 Информационное обеспечение функции 1 «Учет сведений о сотрудниках»

Таблица 1.3 Информационное обеспечение функции 2 «Учет принятых вызовов»

Таблица 1.4 Информационное обеспечение функции 3 «Учет VIP клиентов»

Таблица 1.5 Информационное обеспечение функции 4 «Учет материальных средств»

Таблица 1.5 Информационное обеспечение функции 5 «Учет сведений о контрагентах (поставщиках)»

Вывод

В результате анализа предположительного функционирования гипотетической автоматизированной системы «Таксопарк» выбраны пять автоматизируемых функций, охватывающих основные виды деятельности данного автотранспортного предприятия, информационное обеспечение которых соответствует 7 объектам предметной области и включает 101 атрибут, охватывающих сведения о всей деятельности автотранспортного предприятия и предназначенных для облегчения и упрощения работы всей системы.

2 ВЫЯВЛЕНИЕ ОГРАНИЧЕНИЙ

И ПРАВИЛ ПОДДЕРЖАНИЯ ЦЕЛОСТНОСТИ

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

2.1 Уровень атрибутов

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

2.1.1 Функция 1 «Учет сотрудников»

2.1.1.1 Домены, из которых атрибуты, относящиеся к данной функции, берут свои значения, приведены в табл. 2.1.

Таблица 2.1 Домены атрибутов для функции 1 «Учет сотрудников»

Примечание:

1) Русскоязычные фамилии, имена, отчества (первая буква прописная, остальные — строчные; возможны двойные фамилии, разделенные дефисом, многословные имена, разделенные пробелами).

2) ддммгг, где дд – день, мм – месяц, гг – год

3) номер автомобиля должен быть: xЦ1xxЦ2, где x(англ. буквы), Ц1-число от 000 до 999, Ц2-число от 00 до 99.

4) Внедорожник, седан, хэтч-бэк, кабриолет, универсал.

5) Гг – год.

6) Вес в килограммах.

7) Категория водительских прав должна быть одинаковой с категорией ТС.

8) Дата выдачи прав - Дата рождения >=18

9) Дата выдачи паспорта - Дата рождения >=16

10) Город – улица – дом - квартира.

2.1.1.2 Динамические ограничения атрибутов объектов, участвующих в реализации данной функции, приведены в табл. 2.2.

Таблица 2.2 – Динамические ограничения на уровне атрибутов для функции 1«Учет сотрудников»

2.1.1.3 Операционные правила для атрибутов объектов, участвующих в реализации данной функции, не выявлены.

2.1.2 Функция 2 «Учет принятых вызовов»

2.1.2.1 Домены, из которых атрибуты, относящиеся к данной функции, берут свои значения, приведены в табл. 2.3.

Таблица 2.3 Домены атрибутов для функции 2 «Учет принятых вызовов»

Примечания:

1) ддмм, где дд – день, мм – месяц.

2) Расстояние Маршрута в км.

3) Общая Стоимость Услуги в рублях.

4) номер автомобиля должен быть: xЦ1xxЦ2, где x(англ. буквы), Ц1-число от 000 до 999, Ц2-число от 00 до 99.

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

6) ддммгг, где дд – день, мм – месяц, гг – год

7) Если флаг VIP клиента = истина, то поле номера VIP карты не пусто.

8) Если флаг почасовой оплаты = истина, то поле время движения не пусто

2.1.2.2 Динамические ограничения атрибутов объектов, участвующих в реализации данной функции, приведены в табл. 2.4

Таблица 2.4 – Динамические ограничения на уровне атрибутов для функции 2 «Учет принятых вызовов»

2.1.2.3 Операционные правила для атрибутов объектов, участвующих в реализации данной функции, не выявлены

2.1.3 Функция 3 «Учет VIP клиентов»

2.1.3.1 Домены, из которых атрибуты, относящиеся к данной функции, берут свои значения, приведены в табл. 2.5.

Таблица 2.5 Домены атрибутов для функции 3 «Учет VIP клиентов»

Примечание:

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

2) ддммгг, где дд – день, мм – месяц, гг – год

3) Текущий Баланс в рублях.

4) Город – улица – дом - квартира.

2.3.1.2Динамические ограничения атрибутов объектов, участвующих в реализации данной функции, приведены в табл. 2.6

Таблица 2.6 – Динамические ограничения на уровне атрибутов для функции 3 «Учет VIP клиентов»

2.3.1.3 Операционные правила для атрибутов объектов, участвующих в реализации данной функции, не выявлены

2.1.4 Функция 4 «Учет материальных средств»

2.1.4.1 Домены, из которых атрибуты, относящиеся к данной функции, берут свои значения, приведены в табл. 2.7.

Таблица 2.7 Домены атрибутов для функции 4 «Учет материальных средств»

Примечание:

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

2) Стоимость в рублях.

3) ддммгг, где дд – день, мм – месяц, гг – год

4) Если код сотрудника ответственного за мат. средство и использующего мат. средство совпадают, то должны и совпадать соответствующие фамилии.

2.3.1.2Динамические ограничения атрибутов объектов, участвующих в реализации данной функции, приведены в табл. 2.8

Таблица 2.8 – Динамические ограничения на уровне атрибутов для функции 4 «Учет материальных средств»

2.3.1.4 Операционные правила для атрибутов объектов, участвующих в реализации данной функции, не выявлены

2.1.5 Функция 5 «Учет сведений о контрагентах (поставщиках)»

2.1.5.1 Домены, из которых атрибуты, относящиеся к данной функции, берут свои значения, приведены в табл. 2.9.

Таблица 2.9 Домены атрибутов для функции 5 «Учет сведений о контрагентах (поставщиках)»

Примечание:

1) ддммгг, где дд – день, мм – месяц, гг – год

2.3.1.2Динамические ограничения атрибутов объектов, участвующих в реализации данной функции, приведены в табл. 2.10.

Таблица 2.10 – Динамические ограничения на уровне атрибутов для функции 5 «Учет материальных средств»

2.3.1.5 Операционные правила для атрибутов объектов, участвующих в реализации данной функции, не выявлены

2.2 Уровень кортежей

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

2.2.1 Функция 1 «Учет сведений о сотрудниках»

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

Таблица 2.11 – Статические ограничения для групп атрибутов на уровне кортежей функции 1 «Учет сведений о сотрудниках»

2.2.1.2 Динамические ограничения для кортежей атрибутов, соответствующих данной функции не выявлены.

2.2.1.3 Операционные правила для кортежей атрибутов соответствующих данной функции не выявлены.

2.2.2 Функция 2 «Учет принятых вызовов»

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

Таблица 2.12 – Статические ограничения для групп атрибутов на уровне кортежей функции 2 «Учет принятых вызовов»

2.2.2.2 Динамические ограничения для кортежей атрибутов, соответствующих данной функции не выявлены.

2.2.2.3 Операционные правила для кортежей атрибутов соответствующих данной функции не выявлены.

2.2.3 Функция 3 «Учет VIP клиентов»

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

Таблица 2.13 – Статические ограничения для групп атрибутов на уровне кортежей функции 3 «Учет VIP клиентов»

2.2.3.2 Динамические ограничения для кортежей атрибутов, соответствующих данной функции не выявлены.

2.2.3.3 Операционные правила для кортежей атрибутов соответствующих данной функции не выявлены.

2.2.4 Функция 4 «Учет материальных средств»

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

Таблица 2.14 – Статические ограничения для групп атрибутов на уровне кортежей функции 4 «Учет материальных средств»

2.2.4.2 Динамические ограничения для кортежей атрибутов, соответствующих данной функции не выявлены.

2.2.4.3 Операционные правила для кортежей атрибутов соответствующих данной функции не выявлены.

2.2.5 Функция 5 «Учет сведений о контрагентах (поставщиках)»

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

Таблица 2.15 – Статические ограничения для групп атрибутов на уровне кортежей функции 5 «Учет сведений о контрагентах (поставщиках)»

2.2.4.2 Динамические ограничения для кортежей атрибутов, соответствующих данной функции не выявлены.

2.2.4.3 Операционные правила для кортежей атрибутов соответствующих данной функции не выявлены.

Уровень множеств кортежей

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

2.3.1 Функция 1 «Учет сведений о сотрудниках»

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

Таблица 2.16 – Ограничения уникальности на уровне множеств кортежей для функции 1 «Учет сведений о сотрудниках»

Таблица 2.17 – Другие ограничения на уровне множеств кортежей для функции 1 «Учет сведений о сотрудниках»

2.3.1.2 Динамические ограничения для множества кортежей, соответствующих данной функции не выявлены.

2.3.1.3 Операционные правила для множеств кортежей, соответствующих данной функции не выявлены.

2.3.2 Функция 2 «Учет принятых вызовов»

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

Таблица 2.18 – Ограничения уникальности на уровне множеств кортежей для функции 2 «Учет принятых вызовов»

2.3.2.2 Динамические ограничения для множества кортежей, соответствующих данной функции не выявлены.

2.3.2.3 Операционные правила для множеств кортежей, соответствующих данной функции не выявлены.

2.3.3 Функция 3 «Учет VIP клиентов»

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

Таблица 2.19 – Ограничения уникальности на уровне множеств кортежей для функции 3 «Учет VIP клиентов»

2.3.3.2 Динамические ограничения для множества кортежей, соответствующих данной функции не выявлены.

2.3.3.3 Операционные правила для множеств кортежей, соответствующих данной функции не выявлены.

2.3.4 Функция 4 «Учет материальных средств»

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

Таблица 2.20 – Ограничения уникальности на уровне множеств кортежей для функции 4 «Учет материальных средств»

2.3.4.2 Динамические ограничения для множества кортежей, соответствующих данной функции не выявлены.

2.3.4.3 Операционные правила для множеств кортежей, соответствующих данной функции не выявлены.

2.3.5 Функция 5 «Учет сведений о контрагентах (поставщиках)»

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

Таблица 2.21 – Ограничения уникальности на уровне множеств кортежей для функции 5 «Учет сведений о контрагентах (поставщиках)»

2.3.1.2 Динамические ограничения для множества кортежей, соответствующих данной функции не выявлены.

2.3.1.3 Операционные правила для множеств кортежей, соответствующих данной функции не выявлены.

2.4 Уровень базы данных

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

2.4.1 Функция 1 «Учет сведений о сотрудниках»

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

Таблица 2.22 – Статические ограничения на уровне базы данных для функции 1 «Учет сведений о сотрудниках»

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

Таблица 2.23 – Динамические ограничения на уровне базы данных для функции 1 «Учет сведений о сотрудниках»

2.4.1.3 Операционные правила на уровне базы данных для данной функции не выявлены.

2.4.2 Функция 2 «Учет принятых вызовов»

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

Таблица 2.24 – Статические ограничения на уровне базы данных для функции 2 «Учет принятых вызовов»

2.4.2.2 Динамические ограничения на уровне базы данных для данной функции не выявлены.

2.4.2.3 Операционные правила на уровне базы данных для данной функции не выявлены.

2.4.3 Функция 3 «Учет VIP клиентов»

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

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

Таблица 2.25 – Динамические ограничения на уровне базы данных для функции 3 «Учет VIP клиентов»

2.4.3.2 Динамические ограничения на уровне базы данных для данной функции не выявлены.

2.4.3.3 Операционные правила на уровне базы данных для данной функции не выявлены.

2.4.4 Функция 4 «Учет материальных средств»

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

Таблица 2.26 – Динамические ограничения на уровне базы данных для функции 4 «Учет материальных средств»

2.4.4.2 Динамические ограничения на уровне базы данных для данной функции не выявлены.

2.4.4.3 Операционные правила на уровне базы данных для данной функции не выявлены.

2.4.5 Функция 5 «Учет кадров»

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

Таблица 2.27 – Динамические ограничения на уровне базы данных для функции 5 «Учет кадров»

2.4.5.2 Динамические ограничения на уровне базы данных для данной функции не выявлены.

2.4.5.3 Операционные правила на уровне базы данных для данной функции не выявлены.

2.5 Вывод

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

Общее число ограничений на уровне атрибутов составляет 127 (в том числе динамических 6), на уровне кортежей — 11 , на уровне множеств кортежей — 11 и на уровне базы данных — 7(2).

3 ПРОЕКТИРОВАНИЕ ЛОКАЛЬНЫХ ER -МОДЕЛЕЙ

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

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

3.1 Составление локальных исходных ER -моделей

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

3.1.1 Функция 1 «Учет сведений о сотрудниках»

Исходная ER-модель для данной функции, полученная на основе описания, приведенного в разд. 1, представлена на рисунке 3.1.

Сотрудник Код сотрудника

1 1 1 Фамилия

Имя

Отчество

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

Адрес

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

Водительские права

Дата выдачи прав

Личный автомобиль

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

Образование

1 1 1

Паспорт Транспортное средство ЗАПИСЬ

Серия Номер Дата записи

Номер Марка модель Автор записи

КемВыдан VIN Флаг актуальности

ДатаВыдачи Тип ТС Дата изменения

КодПодразделения Категория ТС Автор изменения

АдресРегистрации Год выпуска

Модель двигателя

Номер двигателя

Шасси (рама)

Кузов (коляска)

Цвет

Мощность двигателя

Серия паспорта ТС

РММ

Масса без нагрузки

Рисунок 3.1 — Исходная ER-модель для функции 1 «Учет сведений о сотрудниках»

Модель содержит сущность «Сотрудник» с атрибутами «Код сотрудника », «ФИО», «Дата рождения», «Адрес», «Должность», «Водительские права», «Дата выдачи прав», «Личный автомобиль», «Семейное положение», «Образование»; сущность «Паспорт», включающую в себя следующие агрегаты и атрибуты: «Серия », «Номер », «КемВыдан», «ДатаВыдачи», «КодПодразделения», «АдресРегистрации»; сущность «Транспортное средство» , включающую в себя следующие агрегаты и атрибуты: «Номер », «Марка модель », «VIN», «Тип ТС», «Категория ТС», «Год выпуска», «Модель двигателя», «Номер двигателя», «Шасси (рама)», «Кузов (коляска)», «Цвет», «Мощность двигателя», «Серия паспорта ТС», «РММ», «Масса без нагрузки». Сущность «ЗАПИСЬ», включающую в себя следующие агрегаты и атрибуты: «Дата записи », «Автор записи », «Флаг актуальности», «Дата изменения», «Автор изменения».

3.1.2 Функция 2 «Учет принятых вызовов»

Исходная ER-модель для данной функции, полученная на основе описания, приведенного в разд. 1, представлена на рисунке 3.2.

Вызов Код вызова

М Код сотрудника

М 1 ФИО сотрудника

Цвет машины

Номер машины

И ИМ СД Флаг VIP клиента

Номер VIP карты

Время

Флаг почасовой оплаты

Время движения

Расстояние

Телефон

Общая стоимость

Флаг состояния

1 1 1

НАЧАЛО КОНЕЦ ЗАПИСЬ

КодПунткта КодПункта

Улица Улица Дата записи

Дом Дом Автор записи

Подъезд Подъезд Флаг актуальности

Дата изменения

Автор изменения

Рисунок 3.2 — Исходная ER-модель для функции 1 «Учет принятых вызовов»

Модель содержит сущность «Вызов» с атрибутами «Код вызова », «Код сотрудника», «ФИО сотрудника», «Цвет машины», «Номер машины», «Флаг VIP клиента», «Время», «Флаг почасовой оплаты», «Время движения», «Расстояние», «Телефон», «Общая стоимость», «Флаг состояния»; сущность «НАЧАЛО», включающую в себя следующие агрегаты и атрибуты: «КодПунткта », «Улица», «Дом», «Подъезд»; сущность «КОНЕЦ» , включающую в себя следующие агрегаты и атрибуты: «КодПунткта », «Улица», «Дом», «Подъезд». Сущность «ЗАПИСЬ», включающую в себя следующие агрегаты и атрибуты: «Дата записи », «Автор записи », «Флаг актуальности», «Дата изменения», «Автор изменения».

3.1.3 Функция 3 «Учет VIP клиентов»

Исходная ER-модель для данной функции, полученная на основе описания, приведенного в разд. 1, представлена на рисунке 3.3.

VIP Клиент Код клиента

1 1 Фамилия

Имя

Отчество

Номер VIP карты

Номер договора

имеет СД Дата договора

Скидка

Баланс

Адрес

Телефон

1 1

Паспорт ЗАПИСЬ

Серия Дата записи

Номер Автор записи

КемВыдан Флаг актуальности

ДатаВыдачи Дата изменения

КодПодразделения Автор изменения

АдресРегистрации

Рисунок 3.3 — Исходная ER-модель для функции 1 «Учет VIP клиентов»

Модель содержит сущность «VIP Клиент » с атрибутами «Код клиента », «ФИО», «Номер VIP карты», «Номер договора», «Дата договора», «Скидка», «Баланс», «Адрес», «Телефон»; сущность «Паспорт», включающую в себя следующие агрегаты и атрибуты: «Серия », «Номер », «КемВыдан», «КодПодразделения», «АдресРегистрации»; Сущность «ЗАПИСЬ», включающую в себя следующие агрегаты и атрибуты: «Дата записи », «Автор записи », «Флаг актуальности», «Дата изменения», «Автор изменения».

3.1.4 Функция 4 «Учет материальных средств»

Исходная ER-модель для данной функции, полученная на основе описания, приведенного в разд. 1, представлена на рисунке 3.4.

Модель содержит сущность «Материальное средство» с атрибутами «Код материального средства », «Код ответственного сот-ка», «Фамилия отв-го сот-ка», «Номинальная стоимость», «Описание», «Прилагаемые части», «Месторасположение», «Назначение», «Периодичность обслуживания», «Сервисные работы», «Эксплуатация», «Код сот-ка исп-го средство», «Фамилия», «Дополнительная инфо-я»; Сущность «ЗАПИСЬ», включающую в себя следующие агрегаты и атрибуты: «Дата записи », «Автор записи », «Флаг актуальности», «Дата изменения», «Автор изменения».

Материальное средство Код материального редства

Код ответственного сот-ка

1 Фамилия отв-го сот-ка

Номинальная стоимость

Описание

Прилагаемые части

СД Месторасположение

Назначение

Периодичность обслуживания

Сервисные работы

Эксплуатация

Код сот-ка исп-го средство

Фамилия

Дополнительная инфо-я

1ЗАПИСЬ

Дата записи

Автор записи

Флаг актуальности

Дата изменения

Автор изменения

Рисунок 3.4 — Исходная ER-модель для функции 1 «Учет материальных средств»

3.1.5 Функция 5 «Учет сведений о контрагентах (поставщиках)»

Исходная ER-модель для данной функции, полученная на основе описания, приведенного в разд. 1, представлена на рисунке 3.5.

Контрагент Код контрагента

1 1 Наименование

Вид контрагента

ИНН

ОКОНХ

ОКПО

может иметь вызвал Юр. адрес

Телефон

Факс

М Электропочта

КРЕДИТ ПОСТАВЩИКА Расчетные счета

Комментарий

Договор

Валюта Дата договора

Осн. договор 1

Сумма ЗАПИСЬ

Глубина

Дата записи

Автор записи

Флаг актуальности

Дата изменения

Автор изменения

Рисунок 3.5 — Исходная ER-модель для функции 1 «Учет сведений о контрагентах (поставщиках)»

Модель содержит сущность «Контрагент» с атрибутами «Код контрагента », «Вид контрагента», «ИНН», «ОКОНХ», «ОКПО», «Юр. адрес», «Телефон», «Факс», «Электропочта», «Расчетные счета», «Комментарий», «Договор», «Дата договора»; сущность «КРЕДИТ ПОСТАВЩИКА», включающую в себя следующие агрегаты и атрибуты: «Валюта», «Осн. договор», «Сумма», «Глубина; Сущность «ЗАПИСЬ», включающую в себя следующие агрегаты и атрибуты: «Дата записи », «Автор записи », «Флаг актуальности», «Дата изменения», «Автор изменения».

3.2 Нормализация локальных ER -моделей

В данном подразделе на основе анализа и преобразования исходных ER-моделей для каждой автоматизируемой функции строятся нормализованные ER-модели, не содержащие «скрытых» сущностей.

Нарушение первой нормальной формы (1NF): атрибут Личный автомобиль в модели №1; атрибут Электропочта в модели №5; атрибут Телефон в сущностях ВЫЗОВ, КОНТРАГЕНТ, VIP КЛИЕНТ.

В сущности ТРАНСПОРТНОЕ СРЕДСТВО атрибуты Тип ТС и Категория ТС зависят от части сцепленного ключа Номер-Марка модель (марка модель).

Нарушение третьей нормальной формы (3NF): в сущности ВЫЗОВ фио сотрудника зависит от его кода и от вызова; в сущности VIP КЛИЕНТ Номер договора зависит от номера карты и от номера клиента.

3.2.1 Функция 1 «Учет сведений о сотрудниках»

Нормализованная ER-модель для данной функции, полученная на основе описания, приведенного в разд. 1, представлена на рисунке 3.6.

Сотрудник Код сотрудника

Фамилия

Имя

Отчество

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

имеет Адрес

имеет имеет S Должность

Водительские права

Дата выдачи прав

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

Образование

Паспорт Транспортное средство ЗАПИСЬ

Серия Номер Дата записи

КемВыдан VIN Автор записи

КодПодразделения Год выпуска Флаг актуальности

АдресРегистрации Модель двигателя Дата изменения

Номер Номер двигателя ТС Автор изменения

Дата выдачи Шасси (рама)

Кузов (коляска) ЛИЧНЫЙ А/М

Мощность двигателя Номер

Серия паспорта ТС Цвет

РММ Марка

Масса без нагрузки Тип ТС

Цвет Категория ТС

Рисунок 3.6 — Нормализованная ER-модель для функции 1 «Учет сведений о сотрудниках»

3.2.2 Функция 2 «Учет принятых вызовов»

ВЫЗОВ Код вызова

∞ Флаг VIP клиента

Номер VIP карты

∞ 1 Время

Флаг почасовой оплаты

Время движения

I I IS S Расстояние

Общая стоимость

Флаг состояния

1 1 1

НАЧАЛО КОНЕЦ СОТРУДНИК ЗАПИСЬ

КодПункта КодПункта

Улица Улица Код сотрудника Дата записи

Дом Дом ФИО Автор записи

Подъезд Подъезд Цвет а/м Флаг актуальности

Номер а/м Дата изменения

Автор изменения

I T

ТЕЛЕФОН

Код телефона

Вид номера

Номер

Рисунок 3.7 — Нормализованная ER-модель для функции 2 «Учет принятых вызовов»

3.2.3 Функция 3 «Учет VIP клиентов»

VIP Клиент Код клиента

1 1 Фамилия

Имя

Отчество

Скидка

Баланс

имеет имеет сделал Адрес

Телефон

1 1

Паспорт VIP КАРТА ЗАПИСЬ

Серия Номер VIP карты Дата записи

КемВыдан Номер договора Автор записи

КодПодразделения Дата договора Флаг актуальности

АдресРегистрации Дата изменения Автор изменения

имеет

имеет НОМЕР ТЕЛЕФОН

Код телефона

Номер Вид номера

ДатаВыдачи Номер

Рисунок 3.8 — Нормализованная ER-модель для функции 3 «Учет VIP клиентов»

3.2.4 Функция 4 «Учет материальных средств»

имеет

1

Рисунок 3.9 – Нормализованная ER-модель для функции 4 «Учет материальных средств»

3.2.5 Функция 5 «Учет сведений о контрагентах (поставщиках)»

Контрагент Код контрагента

Наименование

1 1 1 Вид контрагента

ИНН

ОКОНХ

ОКПО

может иметь вызвал имеет Юр. адрес

Телефон

Факс

М Расчетные счета

КРЕДИТ ПОСТАВЩИКА Комментарий

Договор

НомерКредита Дата договора

Валюта

Осн. договор 1 М

Сумма ЗАПИСЬ Электопочта

Глубина Код электропочты

Дата записи Директор

Автор записи Главбух

Флаг актуальности Менеджер

Дата изменения

Автор изменения

Рисунок 3.1.0 – Нормализованная ER-модель для функции 5 «Учет сведений о контрагентах (поставщиках)»

3.3. Перевод целостных и операционных ограничений на уровне локальных моделей

3.3.1 Модель1: Атрибут Водительские права => атрибут Категория ТС

3.3.2 Модель.1: атрибут Дата выдачи прав – ат. Дата рождения<= 18 лет

3.3.3 Модель.1: атрибут Дата выдачи паспорта – ат. Дата рождения <= 16 лет

3.3.4 Модель.2: если ат. флаг VIP клиента=истина, то ат. номер карты не пуст

3.3.5 Модель.2: если ат. флаг почасовой оплаты=истина, то ат. время движения не пуст

3.3.6 Модель.2: ат.НАЧАЛО_МАРШРУТА.Улица не = ат. КОНЕЦ_МАРШРУТА.Улица

3.3.7 Модель.3: если ат. Баланс <1000 руб., то ат.Скидка <= 10%

3.3.8 Модель.3: атрибут Дата Договора <(раньше) ат.Дата записи

3.3.9 Модель.4: атрибут Номинальная стоимость < ат. Затраты на Эксплуатацию

3.3.10 Модель.4: если ат. Код ответ-го сот-ка= ат. Код сот-ка , то ат. ФИО ответ-го сот-ка должен быть равным ат. ФИО ответ-го сот-ка

3.3.11 Модель.5: атрибут Телефон должен соответствовать коду города, который указан в ат. Юридический адрес

3.3.12 Модель.5: атрибут Факс должен соответствовать коду города, который указан в ат. Юридический адрес

3.3.13 Модель.5: атрибут Дата Договора <(раньше) ат. Дата записи

3.3 Вывод

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

4 ПРОЕКТИРОВАНИЕ ГЛОБАЛЬНОЙ ER -МОДЕЛИ

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

4.1 Выявление и слияние эквивалентных сущностей

4.1.1 Сущности ЗАПИСЬ в локальных моделях эквивалентны, следовательно происходит их слияние в сущность ЗАПИСЬ в глобальной модели

4.1.2 Сущности ПАСПОРТ и НОМЕР (паспорта) в локальных моделях эквивалентны, следовательно происходит их слияние в сущность ПАСПОРТ и НОМЕР (паспорта) в глобальной модели соответственно

4.1.3 Сущности МАРКА МОДЕЛЬ в локальной модели №1 эквивалентны, следовательно происходит их слияние в сущность МАРКА МОДЕЛЬ в глобальной модели

4.1.4 Сущность СОТРУДНИК в локальной модели №2 эквивалентна сущности СОТРУДНИК в модели №1, следовательно происходит их слияние в сущность СОТРУДНИК в глобальной модели

4.1.5 Сущности ТЕЛЕФОН в моделях № 2,3,5 эквивалентны, следовательно, происходит их слияние в сущность ТЕЛЕФОН в глобальной модели

4.2 Выявление и синтез обобщающих сущностей

4.2.1 Сущности Личный А/М и ТС (Транспортное средство предприятия) имеют общие атрибуты, поэтому вводим обобщающую сущность АВТОМОБИЛЬ

4.3 Выявление и устранение дублирующихся атрибутов

4.3.1 В сущности МАТЕРИАЛЬНОЕ СРЕДСТВО есть атрибуты ФИО ответственного сотрудника и ФИО сотрудника, которые дублируются в сущности СОТРУДНИК, следовательно нужно убрать эти атрибуты из сущности МАТЕРИАЛЬНОЕ СРЕДСТВО

Выявление и устранение дублирующихся связей

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

4.4 Графическое представление глобальной ER-модели

Глобальная ER-модель представлена на рисунке 4.1

VIP Клиент Вызов ТС

1 М

1 М М 1

Имеет Заявка Выполнение Использование

Использование

1 1

1 М

VIP Карта Мат. Средство Сотрудник

М

1

М Поставка

Поставщик

1

Паспорт

Рисунок 4.1 – Глобальная ER-модель

4.5 Перевод целостных и операционных ограничений на уровень глобальной модели

4.5.1 Сущность СОТРУДНИК Атрибут Водительские права => Сущность МАРКА МОДЕЛЬ атрибут Категория ТС

4.5.2 Сущность СОТРУДНИК атрибут Дата выдачи прав – Сущность СОТРУДНИК ат. Дата рождения<= 18 лет

4.5.3 Сущность НОМЕР атрибут Дата выдачи паспорта – Сущность СОТРУДНИК ат. Дата рождения <= 16 лет

4.5.4 Сущность ВЫЗОВ: если ат. флаг VIP клиента=истина, то Сущность ВЫЗОВ ат. номер карты не пуст

4.5.5 Сущность ВЫЗОВ: если ат. флаг почасовой оплаты=истина, то Сущность ВЫЗОВ ат. время движения не пуст

4.5.6 Сущность НАЧАЛО ат.Улица не = Сущность КОНЕЦ ат. Улица

4.5.7 Сущность VIP КЛИЕНТ если ат. Баланс <1000 руб., то ат.Скидка <= 10%

4.5.8 Сущность VIP КАРТА: атрибут Дата Договора <(раньше) Сущность ЗАПИСЬ ат.Дата записи

4.5.9 Сущность МАТЕРИАЛЬНОЕ СРЕДСТВО атрибут Номинальная стоимость < Сущность МАТЕРИАЛЬНОЕ СРЕДСТВО ат. Затраты на Эксплуатацию

4.5.10 Сущность КОНТРАГЕНТ: атрибут Телефон должен соответствовать коду города, который указан в ат. Сущность КОНТРАГЕНТ Юридический адрес

4.5.11 Сущность КОНТРАГЕНТ: атрибут Факс должен соответствовать коду города, который указан в Сущность КОНТРАГЕНТ ат. Юридический адрес

4.5.12 Сущность КОНТРАГЕНТ: атрибут Дата Договора <(раньше) Сущность ЗАПИСЬ ат. Дата записи

4.6 Вывод

В результате проектирования глобальной ER-модели, соответствующей автоматизируемым функциям, получена модель, включающая 7 сущностей, 2 связи типа «многие ко многим» и 8 связей типа «один ко многим».

5 ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ SQL -МОДЕЛИ

Данный раздел посвящен проектированию реляционной SQL-модели. Здесь выполняется перевод глобальной ER-модели в реляционную форму, специфицируются ограничения и правила поддержания целостности на реляционном уровне, записывается SQL-код для создания реляционной модели.

5.1 Перевод глобальной ER -модели в реляционную форму

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

Конкретные данные приведены в таблице 5.1

Таблица 5.1 - «Копирование первичных ключей при устранении связей типа «один ко многим».

5.2 SQL-код для создания реляционной модели

Create Table Сотрудник (

Код_сотрудника Int Not Null,

Фамилия Char (20),

Имя Char (20),

Отчество Char (20),

Дата_рожд Date,

Адрес Char (20),

Права Char (20),

Должность Char (20),

Образование Char (20),

Серия_Паспорта Int Not Null,

№Паспорта Int Not Null,

№телефона Int Not Null,

№ТС Char (6),

Дата_записи Date,

Primary key (Код_сотрудника) )

Create table Транспортное_Средство(

Код_мат_средства Int Not Null,

№TC Char (6),

Марка Char (20),

Цвет Char (20),

VIN Int,

Категория Char (20),

Дата_Выпуска Date,

№Двигателя Int,

№Кузова Int,

Двигатель Int,

Масса Int,

Дата_записи Date,

Primary Key (Код_мат_средства)

)

Create Table Поставщик(

Код_Поставщика Int Not Null,

Код_Мат_средства Int NOt Null,

Наименование Char (20),

Вид Char (20),

ИНН Int,

ОКОНХ Int,

Юр_адрес Char (20),

Факс Int,

Договор Char (20),

Дата_договора Date,

Коментарий Char (20),

Дата_записи Date,

Primary Key (Код_Поставщика)

)

Create Table Паспорт (

Серия_паспорта Char (20),

№Паспорта Int Not Null,

Кем_Выдан Char (20),

Код_подразделения Char (20),

Адрес_регистрации Char (20),

Дата_регистрации Date,

Дата_записи Date,

Primary Key (Серия_паспорта)

)

Create Table Материальное_Средство (

Код_мат_средства Int Not Null,

Код_отв_сотрудника Int,

Стоимость Int,

Описание Char (20),

Назначение Char (20),

Эксплуатация Char (20),

Доп_инфо Char (20),

Дата_записи Date,

Primary Key (Код_мат_средства)

)

Create Table Вызов (

Код_Вызова Int Not Null,

Влаг_VIP_Клиента Char (20),

№VIP_Карты Int,

Время_заказа Date,

Флаг_почасовой_оплаты Char (20),

Время_жвижения Date,

Расстояние Int,

Стоимость_р_ч Int,

Стоимость_р_км Int,

Стоимость_заказа Int,

Флаг_состояния Char (20),

Код_сотрудника Int Not Null,

№ТС Char (6),

Дата_записи Date,

Primary Key (Код_Вызова)

)

Create Table VIP_Клиент (Код_VIP_Клиента Int Not Null,

№VIP_Карты Int,

Фамилия Char (20),

Имя Char (20),

Отчество Char (20),

Скидка Int,

Баланс Int,

Адрес Char (20),

Серия_Паспорта Char (20),

№Паспорта Int,

Дата_записи Date,

Primary Key (Код_VIP_Клиента)

)

Create Table VIP_Карта (№VIP_Карты Int Not Null,

№Договора Int,

Дата_Договора Date,

Дата_записи Date,

Primary Key (№VIP_Карты))

6 ПРОЕКТИРОВАНИЕ ПРЕДСТАВЛЕНИЙ

ДЛЯ АВТОМАТИЗИРУЕМЫХ ФУНКЦИЙ

Данный раздел посвящен проектированию представлений для автоматизируемых функций. Здесь выполняется определение путей доступа к данным для автоматизируемых функций, записывается SQL-код локальных просмотров для автоматизируемых функций.

6.1 Определение способа и формы представления

Для 5 функций был выбран способ реализации представления в виде запроса (Select), форма представления была выбрана в виде иерархии таблиц.

6.2 SQL – код для реализации выборки.

VIP_Клиент

SELECT [VIP КЛИЕНТ].№VIP_Карты,

[VIP КЛИЕНТ].Фамилия,

[VIP КАРТА].№Договора,

ПАСПОРТ.Адрес_регистр

FROM ПАСПОРТ INNER JOIN ([VIP КАРТА] RIGHT JOIN [VIP КЛИЕНТ] ON [VIP КАРТА].№VIP_Карты = [VIP КЛИЕНТ].№VIP_Карты) ON (ПАСПОРТ.№Паспорта = [VIP КЛИЕНТ].№Паспорта) AND (ПАСПОРТ.Серия_Паспорта = [VIP КЛИЕНТ].Серия_Паспорта);

Вызов

SELECT ВЫЗОВ.Время_заказа,

[ТРАНСПОРТНОЕ СРЕДСТВО].Цвет,

СОТРУДНИК.Фамилия, [VIP КЛИЕНТ].№VIP_Карты

FROM [VIP КЛИЕНТ] INNER JOIN (СОТРУДНИК RIGHT JOIN ([ТРАНСПОРТНОЕ СРЕДСТВО] INNER JOIN ВЫЗОВ ON [ТРАНСПОРТНОЕ СРЕДСТВО].№ТС = ВЫЗОВ.№ТС) ON СОТРУДНИК.Код_сотрудника = ВЫЗОВ.Код_сотрудника) ON [VIP КЛИЕНТ].№VIP_Карты = ВЫЗОВ.№VIP_Карты;

Поставщик

SELECT [МАТЕРИАЛЬОЕ СРЕДСТВО].Код_мат_ср, ПОСТАВЩИК.Наименование,

ПОСТАВЩИК.Факс,

ПОСТАВЩИК.ИНН,

СОТРУДНИК.Фамилия,

СОТРУДНИК.Должность

FROM СОТРУДНИК INNER JOIN ([МАТЕРИАЛЬОЕ СРЕДСТВО] INNER JOIN ПОСТАВЩИК ON [МАТЕРИАЛЬОЕ СРЕДСТВО].Код_мат_ср = ПОСТАВЩИК.Код_мат_средства) ON СОТРУДНИК.Код_сотрудника = [МАТЕРИАЛЬОЕ СРЕДСТВО].Код_отв_сотр;

Сотр_мат_Средство

SELECT СОТРУДНИК.Фамилия,

ПАСПОРТ.Адрес_регистр,

СОТРУДНИК.Адрес,

[МАТЕРИАЛЬОЕ СРЕДСТВО].Описание,

[МАТЕРИАЛЬОЕ СРЕДСТВО].Стоимость

FROM (ПАСПОРТ INNER JOIN СОТРУДНИК ON (ПАСПОРТ.№Паспорта = СОТРУДНИК.№Паспорта) AND (ПАСПОРТ.Серия_Паспорта = СОТРУДНИК.Серия_Паспорта)) INNER JOIN [МАТЕРИАЛЬОЕ СРЕДСТВО] ON СОТРУДНИК.Код_сотрудника = [МАТЕРИАЛЬОЕ СРЕДСТВО].Код_отв_сотр;

Сотрудник

SELECT СОТРУДНИК.Фамилия,

[ТРАНСПОРТНОЕ СРЕДСТВО].№ТС,

ПАСПОРТ.Адрес_регистр,

[МАТЕРИАЛЬОЕ СРЕДСТВО].Код_мат_ср,

[МАТЕРИАЛЬОЕ СРЕДСТВО].Описание

FROM ПАСПОРТ INNER JOIN ((СОТРУДНИК INNER JOIN [ТРАНСПОРТНОЕ СРЕДСТВО] ON СОТРУДНИК.№ТС = [ТРАНСПОРТНОЕ СРЕДСТВО].№ТС) LEFT JOIN [МАТЕРИАЛЬОЕ СРЕДСТВО] ON СОТРУДНИК.Код_сотрудника = [МАТЕРИАЛЬОЕ СРЕДСТВО].Код_отв_сотр) ON (ПАСПОРТ.№Паспорта = СОТРУДНИК.№Паспорта) AND (ПАСПОРТ.Серия_Паспорта = СОТРУДНИК.Серия_Паспорта);

Заключение

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

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

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

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

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

В разделе 5 записала SQL-код для создания реляционной модели

В разделе 6 записала SQL-код локальных запросов для автоматизируемых функций.