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

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

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

Курсовая работа

по курсу

«Проектирование баз данных»

Содержание

Введение. Назначение баз данных

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

1.1Общее описание деятельности организации

1.2Пользователи базы данных

1.3Документы учёта и отчётности

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

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

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

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

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

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

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

4.2.1Сущности

4.2.2Атрибуты и колонки

4.2.3Домены

4.2.4Связи

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

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

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

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

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

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

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

Заключение

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

Введение

Назначение баз данных.

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

обеспечивать получение общих и/или детализированных отчетов по итогам работы;

позволять легко определять тенденции изменения важнейших показателей;

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

выполнять точный и полный анализ данных.

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

Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер». Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще - диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе «открытом подходе», то есть необходимость и возможность использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных. Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».

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

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

1.1 Общее описание деятельности организации

Oriflame Cosmetics S.A. (произносится Орифлэйм) -- косметическая компания, производящая средства по уходу за кожей лица, средства личной гигиены, парфюмерию и декоративную косметику из натуральных растительных ингредиентов. По данным официального сайта компании, она представлена в 62 странах мира, в более чем половине из них она является одним из лидеров индустрии прямых продаж. Компания предлагает свою продукцию по каталогам. Компания Орифлэйм работает методом сетевого маркетинга с элементами прямых продаж.

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

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

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

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

1.2 Пользователи базы данных

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

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

Пользователей данной базы данных можно разделить на две большие категории:

Консультанты компании (исполнители)

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

Покупатели (заказчики)

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

1.3 Документы учёта и отчётности.

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

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

Начало формы

Регистрация Нового Консультанта

Пожалуйста, введите личные данные Нового Консультанта ниже. 
Конфиденциальность персональной информации гарантируется.

Фамилия:

Имя и Отчество:

Номер паспорта:

Дата рождения (дд.мм.гггг): 

Email:

Область/регион: 

Адрес проживания (ул/дом/кв): 

Город: 

Индекс: 

Домашний телефон: 

Мобильный телефон: 

Стартовый набор: 

Номер спонсора:  

Спонсор: -___________________________

Я согласен с Правилами Он-лайн регистрации Орифлэйм

Конец формы

Накладные Консультанта

Накладная	Дата	Сумма	Долг	Пеня	На ожидании	Итого	Срок оплаты

Список заказов

Назад к отчетам

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

Номер заказа	ББ	Сумма	Дата заказа	Дата доставки	Каталог	Статус заказа

Ваша корзина

Продукт	Количество	ББ	Цена

Цена всего: 

ББ всего: 

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

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

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

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

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

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

ER-модель также отражает и схему получения товара.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2.1 Сущности

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

Name: Покупатель

Label: Пок

Persistent: v

Abbreviation: Pok

Documentation:

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

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

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

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

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

Name: Учёт

Label: Учёт

Persistent: v

Abbreviation: Uch

Documentation:

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

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

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

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

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

Name: Накладная

Label: Накл

Persistent: v

Abbreviation: Nakl

Documentation:

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

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

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

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

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

Name: Исполнитель

Label: Исп

Persistent: v

Abbreviation: Isp

Documentation:

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

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

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

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

4.2.2Атрибуты и колонки

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

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

атрибут:

Name: Номер покупателя

Label: Ном_пок

Abbreviation: #pok

Documentation:

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

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

колонка:

Data Type - Тип данных: DECIMAL

Length - Размер: 10

Ключ: PK - Primary Key

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

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

-атрибут:

Name: ФИО покупателя

Label: ФИО

Abbreviation: FIO

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

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

Documentation:

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

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

-колонка:

Data Type - Тип данных: Char

Length - Размер: 30 Точность:_____

Ключ: _________

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

атрибут:

Name: Адрес

Label: Адр

Abbreviation: Address

Documentation:

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

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

колонка:

Data Type - Тип данных: Char

Length - Размер: 50 Точность: _____

Ключ: _____________

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

атрибут:

Name: Телефон

Label: Тел

Abbreviation: Tel

Documentation:

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

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

колонка:

Data Type - Тип данных: Char

Length - Размер: 16 Точность:_____

Ключ: _____________

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

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

Name: Номер накладной

Label: Ном_накл

Abbreviation: #nakl

Documentation:

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

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

колонка:

Data Type - Тип данных: DECIMAL

Length - Размер: 10 Точность:_____

Ключ: PK-Primary Key

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

- атрибут:

Name: Дата подачи заявки

Label: звк_ДП

Abbreviation: zvk_DP

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

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

Documentation:

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

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

Data Type - Тип данных: Date

Length - Размер:____ Точность:_____

Ключ: ________

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

- атрибут:

Name: Дата исполнения заявки

Label: звк_ДИ

Abbreviation: zvk_DI

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

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

Documentation:

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

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

- колонка:

Data Type - Тип данных: Date

Length - Размер:____ Точность:_____

Ключ: ________

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

- атрибут:

Name: Количество товаров

Label: Кол_тов

Abbreviation: Kol_tov

Documentation:

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

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

- колонка:

Data Type - Тип данных: INTEGER

Length - Размер:____ Точность:_____

Ключ: ________

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

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

- колонка:

Data Type - Тип данных: DECIMAL

Length - Размер: 10 Точность:_____

Ключ: FK - Foreign Key

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

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

- колонка:

Data Type - Тип данных: DECIMAL

Length - Размер: 10 Точность:_____

Ключ: FK - Foreign Key

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

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

- колонка:

Data Type - Тип данных: CHAR

Length - Размер: 10 Точность:_____

Ключ: FK - Foreign Key

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

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

- атрибут:

Name: Номер накладной

Label: Ном_накл

Abbreviation: #nakl

Documentation:

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

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

- колонка:

Data Type - Тип данных: DECIMAL

Length - Размер: 10 Точность:_____

Ключ: PK-Primary Key

№2 Атрибут: «Код товара» сущности Накладная

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

- колонка:

Data Type - Тип данных: DECIMAL

Length - Размер: 10 Точность:_____

Ключ: FK - Foreign Key

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

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

- атрибут:

Name: Номер исполнителя

Label: Ном_исп

Abbreviation: #isp

Documentation:

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

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

- колонка:

Data Type - Тип данных: DECIMAL

Length - Размер: 10 Точность:_____

Ключ: PK-Primary Key

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

- атрибут:

Name: ФИО исполнителя

Label: ФИО

Abbreviation: FIO

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

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

Documentetion:

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

2.Примеры экземпляров атрибута: Алексеев Петр Александрович.

Data Type - Тип данных: Char

Length - Размер: 30 Точность:_____

Ключ: ______

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

- атрибут:

Name: Уровень

Label: Уров

Abbreviation: Urov

Documentetion:

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

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

Data Type - Тип данных: Char

Length - Размер: 15 Точность:_____

Ключ: ______

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

- атрибут:

Name: Трудовой Стаж

Label: Тр_стаж

Abbreviation: Stazh

Documentetion:

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

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

Data Type - Тип данных: Char

Length - Размер: 15 Точность:_____

Ключ: ______

4.2.3Домены

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

Name: _______________________

Label: ______________________

Abbreviation: ________________

Base Type: ________________

Length: _____________

Precision: ____

Scale: ___

Owner: ___________

Minimum Length: ___

Maximum Length: ____

Anumeration Values (список допустимых значений):

_______________________

_______________________

Patterns: ( маска)_________

Documentation: ____________

№1 Домен: «Дата»

Name: Дата

Label: Дата

Abbreviation: Data

Base Type: Date

Length: __

Patterns: 99.99.99

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

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

Name: ФИО

Label: ФИО

Abbreviation: FIO

Base Type: Char

Length: 30

Patterns: АБВ

4.2.4Связи

1. Связь «Учёт - Покупатель»

Verb Phrase со стороны родительской сущности - заносится в

Verb Phrase со стороны дочерней сущности - содержит

Documentation: Покупатель в учёте.

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

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

2. Связь «Учёт - Исполнитель»

Verb Phrase со стороны родительской сущности - заносится в

Verb Phrase со стороны дочерней сущности - содержит

Documentation: Исполнитель в учёте.

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

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

. Связь «Учёт - Накладная»

Verb Phrase со стороны родительской сущности - заносится в

Verb Phrase со стороны дочерней сущности - состоит из

Documentation: Накладная из учёта.

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

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

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

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

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

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

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

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

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

CREATE SCHEMA Admin;

CREATE TABLE POK (

#POK DECIMAL(10 , 0) NOT NULL,

FIO CHAR(30),

ADDRESS CHAR(50),

TEL CHAR(16)

)

DATA CAPTURE NONE ;

CREATE 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,

ZVK_DP DATE,

ZVK_DI DATE,

KOL_TOV INTEGER

)

DATA CAPTURE NONE ;

CREATE TABLE NAKL (

#NAKL DECIMAL(10 , 0) NOT NULL,

KOD DECIMAL(10 , 0) NOT NULL

)

DATA CAPTURE NONE ;

CREATE TABLE ISP (

#ISP DECIMAL(10 , 0) NOT NULL,

FIO CHAR(30),

UROV CHAR(15),

STAZH CHAR(15)

)

DATA CAPTURE NONE ;

CREATE TABLE KAT (

#KAT CHAR(10) NOT NULL,

RUK CHAR(15),

DATE_NACH DATE,

DATE_KON DATE,

KOL_TOV INTEGER

)

DATA CAPTURE NONE ;

CREATE TABLE TOV (

KOD DECIMAL(10 , 0) NOT NULL,

#KAT CHAR(10) NOT NULL,

NAIM CHAR(30),

BB INTEGER,

OPT_CEN FLOAT(7),

DIS_CEN FLOAT(7),

POTR_CEN FLOAT(7),

SKID CHAR(5)

)

DATA CAPTURE NONE ;

CREATE TABLE Spisok nakladnih (

#NAKL DECIMAL(10 , 0) NOT NULL,

Kol_tov CHAR(5)

)

DATA CAPTURE NONE ;

ALTER TABLE POK ADD CONSTRAINT POK_PK PRIMARY KEY (#POK);

ALTER TABLE UCHET ADD CONSTRAINT UCHET_PK PRIMARY KEY (#NAKL);

ALTER TABLE NAKL ADD CONSTRAINT NAKL_PK PRIMARY KEY (#NAKL);

ALTER TABLE ISP ADD CONSTRAINT ISP_PK PRIMARY KEY (#ISP);

ALTER TABLE KAT ADD CONSTRAINT KAT_PK PRIMARY KEY (#KAT);

ALTER TABLE TOV ADD CONSTRAINT TOV_PK PRIMARY KEY (KOD);

ALTER TABLE Spisok nakladnih ADD CONSTRAINT NAKL_X_UCHET_PK PRIMARY KEY (#NAKL);

ALTER TABLE UCHET ADD CONSTRAINT UCHET_POK_FK FOREIGN KEY (#POK)

REFERENCES POK (#POK);

ALTER TABLE UCHET ADD CONSTRAINT UCHET_ISP_FK FOREIGN KEY (#ISP)

REFERENCES ISP (#ISP);

ALTER TABLE UCHET ADD CONSTRAINT UCHET_KAT_FK FOREIGN KEY (#KAT)

REFERENCES KAT (#KAT);

ALTER TABLE UCHET ADD CONSTRAINT UCHET_NAKL_FK FOREIGN KEY (#NAKL)

REFERENCES NAKL (#NAKL)

NOT ENFORCED;

ALTER TABLE NAKL ADD CONSTRAINT NAKL_TOV_FK FOREIGN KEY (KOD)

REFERENCES TOV (KOD);

ALTER TABLE TOV ADD CONSTRAINT TOV_KAT_FK FOREIGN KEY (#KAT)

REFERENCES KAT (#KAT);

ALTER TABLE Spisok nakladnih ADD CONSTRAINT NAKL_X_UCHET_NAKL_FK FOREIGN KEY (#NAKL)

REFERENCES NAKL (#NAKL);

ALTER 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.

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

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

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

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

Размещено на Allbest.ru