Моделирование базы данных для обработки заказов на косметику

 Накладная

Дата

Сумма

Долг

Пеня

На ожидании

Итого

Срок оплаты

Назад к отчетам <javascript:WebForm_DoPostBackWithOptions(new%20WebForm_PostBackOptions(%22ctl00$cphContent$btnBackToBusiness%22,%20%22%22,%20true,%20%22%22,%20%22%22,%20false,%20true))>

Номер консультанта =­­

Ваша корзина

Цена всего:

ББ всего:

2. Инфологическое моделирование предметной области

.1 ER модель предметной области

Описание ER модели

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

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

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

По накладной определяется товар из нужного каталога. Накладная в свою очередь заносится в журнал.

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

3. Представление базы данных в графическом виде (диаграмма)

Имена таблиц и атрибутов должны быть в русском алфавите.

4. Моделирование предметной области

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

Необходимо разработать базу данных для обработки заказов на косметику. Она будет содержать:

Информацию о покупателях

Информацию о накладных

Информацию об исполнителях

Информацию о каталогах

Информацию об учёте

Информацию о товарах

.2 Анкеты описания сущностей, атрибутов и связей

.2.1 Сущности

№ 1 Сущность «Покупатель».: Покупатель: Пок

Persistent: v: Pok:

Определение: Человек, который делает заявку на приобретение товара.

Примеры возможных запросов: Список покупателей.

Примеры экземпляров сущности: Петров И.И.

Идентификатор сущности: «Ном_пок».

№ 2 Сущность «Учёт».

Name: Учёт: Учёт: v

Abbreviation: Uch:

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

Примеры возможных запросов: Дата подачи заявки.

Примеры экземпляров сущности: № 777777.

Идентификатор сущности: «Ном_накл».

№ 3 Сущность «Накладная».: Накладная: Накл

Persistent: v: Nakl:

1. Определение: Сведения о товаре в накладной.

2. Примеры возможных запросов: 1.Код товара.

3. Примеры экземпляров сущности: 54637.

. Идентификатор сущности: «Ном_накл».

№ 4 Сущность «Исполнитель».: Исполнитель : Исп

Persistent: v: Isp:

Определение: Сведения об исполнителях.

Примеры возможных запросов: Номер исполнителя.

Примеры экземпляров сущности: 10300.

Идентификатор сущности: «Ном_исп».

.2.2Атрибуты и колонки

Атрибуты (Колонки) Сущности (Таблицы) Покупатель:

№1 Атрибут: «Номер покупателя» сущности Покупатель

атрибут:: Номер покупателя: Ном_пок: #pok:

. Определение: Номер покупателя.

. Примеры экземпляров атрибута: 9860, 2346.

колонка:Type - Тип данных: DECIMAL

Length - Размер: 10

Режим нулевых значений: - Not Null

№2 Атрибут: «ФИО покупателя» сущности Покупатель

атрибут:: ФИО покупателя: ФИО: FIO

Привязка к домену:

Имя домена: ФИО:

. Определение: Фамилия, имя, отчество покупателя.

. Примеры экземпляров атрибута: Сергеев Анатолий Юрьевич.

колонка:Type - Тип данных: Char- Размер: 30 Точность:_____

Ключ: _________

№3 Атрибут: «Адрес» сущности Покупатель

атрибут:: Адрес: Адр: Address

Documentation:

1. Определение: Адрес покупателя.

. Примеры экземпляров атрибута: г. Москва, Новая Басманная ул., д.999, кв.666.

колонка:Type - Тип данных: Char- Размер: 50 Точность: _____

Ключ: _____________

№4 Атрибут: «Телефон» сущности Покупатель

атрибут:: Телефон: Тел: Tel

Documentation:

1. Определение: контактный номер телефона покупателя.

. Примеры экземпляров атрибута: 356-67-47.

колонка:Type - Тип данных: Char- Размер: 16 Точность:_____

Ключ: _____________

Атрибуты (Колонки) Сущности(Таблицы) Учёт:

№1 Атрибут: «Номер_накладной» сущности Учёт: Номер накладной

Label: Ном_накл: #nakl:

1. Определение: Номер накладной.

. Примеры экземпляров атрибута: 9834510.

колонка:Type - Тип данных: DECIMAL- Размер: 10 Точность:_____

Ключ: PK-Primary Key

№2 Атрибут: «Дата подачи заявки» сущности Учёт

- атрибут:: Дата подачи заявки: звк_ДП: zvk_DP

Привязка к домену:

Имя домена: Дата:

1.Определение: Дата подачи заявки покупателем.

2.Примеры экземпляров: 13/05/2011.Type - Тип данных: Date- Размер:____ Точность:_____

Ключ: ________

№3 Атрибут: «Дата исполнения заявки» сущности Учёт

- атрибут:: Дата исполнения заявки: звк_ДИ: zvk_DI

Привязка к домену:

Имя домена: Дата:

1.Определение: Дата исполнения заявки исполнителем.

2.Примеры экземпляров: 23/06/2011.

- колонка:Type - Тип данных: Date- Размер:____ Точность:_____

Ключ: ________

№4 Атрибут: «Количество товаров» сущности Учёт

- атрибут:: Количество товаров: Кол_тов: Kol_tov:

1.Определение: Количество товаров в заявке.

2.Примеры экземпляров: 3.

- колонка:Type - Тип данных: INTEGER- Размер:____ Точность:_____

Ключ: ________

№5 Атрибут: «Номер покупателя» сущности Учёт

Наследуется от атрибута сущности Покупатель по неидентифицирующей связи

- колонка:Type - Тип данных: DECIMAL - Размер: 10 Точность:_____

Ключ: FK - Foreign Key

№6 Атрибут: «Номер исполнителя» сущности Учёт

Наследуется от атрибута сущности Исполнитель по неидентифицирующей связи

- колонка:Type - Тип данных: DECIMAL - Размер: 10 Точность:_____

Ключ: FK - Foreign Key

№7 Атрибут: «Номер каталога» сущности Учёт

Наследуется от атрибута сущности Каталог по неидентифицирующей связи

- колонка:Type - Тип данных: CHAR - Размер: 10 Точность:_____

Ключ: FK - Foreign Key

Атрибуты (Колонки) Сущности(Таблицы) Накладная:

№1 Атрибут: «Номер накладной» сущности Накладная

- атрибут:: Номер накладной: Ном_накл: #nakl:

1.Определение: Номер накладной.

2.Примеры экземпляров: 334001.

- колонка:Type - Тип данных: DECIMAL- Размер: 10 Точность:_____

Ключ: PK-Primary Key

Наследуется от атрибута сущности Товар по неидентифицирующей связи

- колонка:Type - Тип данных: DECIMAL - Размер: 10 Точность:_____

Ключ: FK - Foreign Key

Атрибуты (Колонки) Сущности(Таблицы) Исполнитель:

№1 Атрибут: «Номер_исполнителя» сущности Исполнитель

- атрибут:: Номер исполнителя: Ном_исп: #isp :

1.Определение: Номер исполнителя.

2.Примеры экземпляров: 342401.

- колонка:Type - Тип данных: DECIMAL- Размер: 10 Точность:_____

Ключ: PK-Primary Key

№2_Атрибут: «ФИО исполнителя» сущности Исполнитель

- атрибут:: ФИО исполнителя : ФИО : FIO

Привязка к домену:

Имя домена: ФИО:

.Определение: Фамилия, имя и отчество исполнителя.

.Примеры экземпляров атрибута: Алексеев Петр Александрович.Type - Тип данных: Char- Размер: 30 Точность:_____

Ключ: ______

№3_Атрибут: «Уровень» сущности Исполнитель

- атрибут:

Name: Уровень: Уров: Urov

Documentetion:

.Определение: Уровень исполнителя.

.Примеры экземпляров атрибута: консультант.Type - Тип данных: Char- Размер: 15 Точность:_____

Ключ: ______

№4_Атрибут: «Трудовой Стаж» сущности Исполнитель

- атрибут:: Трудовой Стаж: Тр_стаж: Stazh:

.Определение: Трудовой стаж работы исполнителя.

.Примеры экземпляров атрибута: 4 года.Type - Тип данных: Char- Размер: 15 Точность:_____

Ключ: ______

.2.3Домены

Формат описания доменов:

Name: _______________________: ______________________: ________________Type: ________________: _____________: ____: ___: ___________Length: ___Length: ____Values (список допустимых значений):

_______________________

_______________________: ( маска)_________: ____________

№1 Домен: «Дата» : Дата: Дата: DataType: Date: __: 99.99.99

Documentation: Дата вводится в формате ДД(день).ММ(месяц).ГГ(год)

№2 Домен: «ФИО» : ФИО : ФИО

Abbreviation: FIOType: Char: 30

Patterns: АБВ

.2.4Связи

. Связь «Учёт - Покупатель»Phrase со стороны родительской сущности - заносится вPhrase со стороны дочерней сущности - содержит : Покупатель в учёте.

Тип связи: неидентифицирующая.

Кардинальность связи (Cardinality - 0, 1, ∞; 1, ∞ (P); 0, 1 (Z); точно N (N);

. Связь «Учёт - Исполнитель»Phrase со стороны родительской сущности - заносится вPhrase со стороны дочерней сущности - содержит: Исполнитель в учёте.

Тип связи: неидентифицирующая,

Кардинальность связи (Cardinality - 0, 1, ∞; 1, ∞ (P); 0, 1 (Z); точно N (N);

. Связь «Учёт - Накладная»Phrase со стороны родительской сущности - заносится вPhrase со стороны дочерней сущности - состоит из: Накладная из учёта.

Тип связи: неопределенная.

5. Графические материалы

.1 Сущности и первичные ключи

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

5.3 Атрибуты сущностей

.4 Физический уровень

5.5 Частная модель

6. SQL-скрипт схемы базы данных

база данные заказ

CREATE SCHEMA Admin;TABLE POK (

#POK DECIMAL(10 , 0) NOT NULL,CHAR(30),CHAR(50),CHAR(16)

)CAPTURE NONE ;

TABLE UCHET (

#NAKL DECIMAL(10 , 0) NOT NULL,

#POK DECIMAL(10 , 0) NOT NULL,

#ISP DECIMAL(10 , 0) NOT NULL,

#KAT CHAR(10) NOT NULL,_DP DATE,_DI DATE,_TOV INTEGER

)CAPTURE NONE ;TABLE NAKL (

)CAPTURE NONE ;TABLE ISP (

#ISP DECIMAL(10 , 0) NOT NULL,CHAR(30),CHAR(15),CHAR(15)

)CAPTURE NONE ;TABLE KAT (

#KAT CHAR(10) NOT NULL,CHAR(15),_NACH DATE,_KON DATE,_TOV INTEGER

)CAPTURE NONE ;TABLE TOV (DECIMAL(10 , 0) NOT NULL,

#KAT CHAR(10) NOT NULL,CHAR(30),INTEGER,_CEN FLOAT(7),_CEN FLOAT(7),_CEN FLOAT(7),CHAR(5)

)CAPTURE NONE ;TABLE Spisok nakladnih (

#NAKL DECIMAL(10 , 0) NOT NULL,_tov CHAR(5)

)CAPTURE NONE ;TABLE POK ADD CONSTRAINT POK_PK PRIMARY KEY (#POK);TABLE UCHET ADD CONSTRAINT UCHET_PK PRIMARY KEY (#NAKL);TABLE NAKL ADD CONSTRAINT NAKL_PK PRIMARY KEY (#NAKL);TABLE ISP ADD CONSTRAINT ISP_PK PRIMARY KEY (#ISP);TABLE KAT ADD CONSTRAINT KAT_PK PRIMARY KEY (#KAT);TABLE TOV ADD CONSTRAINT TOV_PK PRIMARY KEY (KOD);TABLE Spisok nakladnih ADD CONSTRAINT NAKL_X_UCHET_PK PRIMARY KEY (#NAKL);TABLE UCHET ADD CONSTRAINT UCHET_POK_FK FOREIGN KEY (#POK)POK (#POK);TABLE UCHET ADD CONSTRAINT UCHET_ISP_FK FOREIGN KEY (#ISP)ISP (#ISP);TABLE UCHET ADD CONSTRAINT UCHET_KAT_FK FOREIGN KEY (#KAT)KAT (#KAT);TABLE UCHET ADD CONSTRAINT UCHET_NAKL_FK FOREIGN KEY (#NAKL)NAKL (#NAKL)ENFORCED;TABLE NAKL ADD CONSTRAINT NAKL_TOV_FK FOREIGN KEY (KOD)TOV (KOD);TABLE TOV ADD CONSTRAINT TOV_KAT_FK FOREIGN KEY (#KAT)KAT (#KAT);TABLE Spisok nakladnih ADD CONSTRAINT NAKL_X_UCHET_NAKL_FK FOREIGN KEY (#NAKL)NAKL (#NAKL);TABLE Spisok nakladnih ADD CONSTRAINT NAKL_X_UCHET_UCHET_FK FOREIGN KEY (#NAKL)

REFERENCES UCHET (#NAKL);

Заключение

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

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

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

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

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

Главным результатом данной курсовой работы является разработка функционирующей базы данных для обработки заказов на косметику, с удобным управлением и выполнением всех необходимых задач. Было выполнено полное описание предметной области и её анализ, выявлены и описаны основные объекты с их атрибутами и связи между ними, построены модель в нотации Чена и представление базы данных в графическом виде, для реализации которых, использовались средства IBM Rational Data Architect.

Список литературы

1.Костюк В.В., "Лабораторный практикум по курсу « Проектирование баз данных» ", М., РГУИТП, 2012.

.Гайдамакин Н.А. Автоматизированные информационные системы, базы и банки данных. Вводный курс: Учебное пособие. - М.: Гелиос АРВ, 2010.

.Зеленков Ю.А. Введение в базы данных. - 2007.

.Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. Проф. А.Д. Хомоненко - СПб.: КОРОНА принт, 2009.

.Введение в системы баз данных. К. Дж. Дейт, 2008.

© 2003 - 2022 «Библиофонд»

Обратная связь

Пользовательское соглашение

Политика конфиденциальности

Полная версия

Помощь по учебным работам

Консультация по курсовой работе

Консультация по дипломной работе ВКР

Консультация по реферату

Консультация по отчетам о практике