Курсовая работа по БД. Курсова БД. 1. Изучение предметной области "Магазин по продаже компьютерных комплектующих" 4
 Скачать 448.43 Kb.
|
СодержаниеВведение. 2 1.Изучение предметной области “Магазин по продаже компьютерных комплектующих” 4 1.1 Описание предметной области “Магазин по продаже компьютерных комплектующих” 4 1.2 Правило построение ER и реляционной модели данных. 5 Преобразование ER-модели в реляционную модель. 5 1.3 Выявление сущностей и связей для предметной области “Магазин по продаже компьютерных комплектующих” 9 1.4 Основные термины. 11 2.Создание ER и реляционной модели данных, запросов, представлений, хранимых процедур, курсоров и триггеров для предметной области “Магазин по продаже компьютерных комплектующих” 17 2.1 Создание ER и реляционной модели данных для предметной области “магазин по продаже компьютерных комплектующих” 17 2.2 Создание таблиц в MS SQL Server 2008 для предметной области “Магазин по продаже компьютерных комплектующих” 19 2.3 Создание запросов для предметной области “Магазин по продаже компьютерных комплектующих” 25 2.4 Создание хранимых процедур для предметной области “Магазин по продаже компьютерных комплектующих” 30 2.5 Создание представлений для предметной области “Магазин по продаже компьютерных комплектующих” 33 Заключение. 37 Список используемой литературы. 38 Введение.Актуальность курсовой работы, определена как необходимость создания и проектирования баз данных. В современном мире, существует большое множество разнообразных баз данных. Без которых век информационных технологий не мог бы существовать и прогрессивно развиваться. Современный мир не может обойтись без структурированной и отсортированной информации, базы данных позволяют реализовать это. Базы данных необходимы для многих областей деятельности человека, будь то банковское дело, продовольственный магазин или же учет домашних расходов. Базы данных встречаются на каждом шагу. Практически любая система это хорошо построенная база данных, например учет единого налога в министерстве налогов и сборов. Цель: создать базу данных, удовлетворяющею потребностям администратора магазина. В качестве предметной области рассматривается магазин по продаже компьютерных комплектующих. Задачи: проанализировать и исследовать предметную область “Магазин по продаже компьютерных комплектующих” построить ER и реляционную модель данных разработать сценарий таблиц для реализации его в MS SQL Server заполнить таблицы создать запросы создать представления создать хранимые процедуры создать курсоры создать триггеры 1.Изучение предметной области “Магазин по продаже компьютерных комплектующих”1.1 Описание предметной области “Магазин по продаже компьютерных комплектующих”Задачей курсовой работы является, приобретение практических навыков по формулированию требований к разрабатываемым базам данных и построению их моделей. В данном курсовом проекте в качестве предметной области рассматривается “магазин по продаже компьютерных комплектующих”.Данная база данных создается для администратора магазина. Система должна выводить информацию о: Цене проданного товара Цене товара у различных поставщиков Наличии товара, на каком либо складе Сотруднике который, обслуживал определенный заказ Перечини товара в заказе Исходные данные о магазине: Заказчик приходит либо звонит в магазин для того чтобы оформить заказ .Сотрудник из отдела по продажам оформляет заказ .Сотрудник из отдела по сборке заказа собирает заказ на основе состава заказа предоставляемым сотрудником из от отдела по продажам .Заказ доставляется сотрудником из отдела по доставкам .Товар храниться на различных складах. 1.2 Правило построение ER и реляционной модели данных.Для “ручного” построения ER-модели на практике будем использовать простую систему обозначений, предложенную Питером Ченом. Первичный ключ может состоять из нескольких атрибутов, тогда подчеркивается каждый из них. Объект и его атрибуты соединяются ненаправленными дугами. Ромб связи и прямоугольник объекта соединяются ненаправленными дугами в сторону “ко многим” и направленными в сторону “к одному”.Связь может соединять сущность саму с собой. Если связь соединяет две сущности, она называется бинарной. Связь может соединять более двух сущностей, например, связь, соединяющая три сущности, называется тернарной. Иногда используют также понятие “слабая сущность”. Это сущность, которая не может быть однозначно идентифицирована с помощью собственных атрибутов, а только через связь с другой сущностью. Иногда для более удобной классификации используются так называемые подтипы сущностей. Их обозначают с помощью треугольника с надписью “есть” (т.е., “является”). Пусть, например, среди контрагентов могут быть как физические, так и юридические лица. Поскольку они имеют разные атрибуты, то удобно создать для них подтипы: Преобразование ER-модели в реляционную модель.1) Преобразование сущностей Преобразование обычной сущности Обычная сущность преобразуется в отдельную таблицу, полями таблицы будут все атрибуты сущности: Сущность (Ключ, Атрибут1, Атрибут2) Преобразование слабой сущности Слабая сущность преобразуется в отдельную таблицу, полями таблицы будут все атрибуты сущности плюс ключевые атрибуты всех сущностей, с помощью которых данная слабая сущность идентифицируется. Ключевые поля всех родительских таблиц войдут в ключ дочерней таблицы. Для дочерней таблицы они будут называться внешними ключами. Сущность1 (Ключ1, Ключ2, Атрибут1, Атрибут2) Преобразование подтипов сущностей. 1 способ. Создается одна таблица, в которую помещают все атрибуты. Для того, чтобы указать, к какому подтипу относится объект, приходится вводить дополнительное поле-признак. Сущность1(Ключ, Атрибут1, Атрибут2, Атрибут3, Атрибут4, Атрибут4, Признак) Недостатком этого способа является то, что в таблице остается много незаполненных полей: для объекта подтипа 1 атрибуты 4 и 5, а для объекта подтипа 2 – атрибуты 2 и 3 останутся пустыми. 2 способ .Создается отдельная таблица для каждого подтипа. В нее включаются все атрибуты этого подтипа и все атрибуты надтипа. Подтип1(Ключ, Атрибут1, Атрибут2, Атрибут3) Подтип2(Ключ, Атрибут1, Атрибут4, Атрибут5) Недостатком этого подхода является то, что подтипы теперь никак не связаны друг с другом. 3 способ . Создается одна таблица для надтипа, и по одной таблице для каждого подтипа, в которую включаются ключевые поля надтипа: Сущность1(Ключ, Атрибут1) Подтип1(Ключ, Атрибут2, Атрибут3) Подтип2(Ключ, Атрибут4, Атрибут5) Недостатком этого подхода является то, что информация о каждом объекте теперь раскидана по двум таблицам. 2) Преобразование связей Связь М:М Создается новая таблица, содержащая ключевые поля каждой сущности, участвующей в связи, и собственные атрибуты связи, если таковые имеются. В названии обычно отражают, какие именно сущности связываются, или называют новую таблицу именем связи. Сущ1Сущ2(Ключ1, Ключ2, Атрибут1). Связь 1:М 1 способ. Точно так же, как и в случае М:М, создается новая таблица, содержащая ключевые поля каждой сущности, участвующей в связи. В названии обычно отражают, какие именно сущности связываются, или называют новую таблицу именем связи. Ключом будет ключ второй сущности. (Этот способ предпочтительнее использовать в том случае, если связь не является “ровно к одному”, то есть не все экземпляры сущностей участвуют в связи.) Сущ1Сущ2(Ключ1, Ключ2). 2 способ. Новая таблица не создается, а в таблицу дочерней сущности добавляют ключевые поля родительской сущности (в ключ дочерней сущности они входить не будут!). Ключевые поля родительской сущности представляют собой внешний ключ (foreign key) для дочерней сущности. (Этот способ предпочтительнее использовать в том случае, если связь является связью “ровно к одному”, то есть все экземпляры сущностей участвуют в связи. В этом случае поле внешнего ключа никогда не будет пустым.) Таблица дочерней сущности: Сущность2(Ключ2, Атрибут1, Ключ1). 3.Связь1:1 1 способ. Точно так же, как и в случае М:М, создается новая таблица, содержащая ключевые поля каждой сущности, участвующей в связи. В названии обычно отражают, какие именно сущности связываются, или называют новую таблицу именем связи. Ключом будет ключ любой сущности. (Этот способ предпочтительнее использовать в том случае, если связь не является “ровно к одному”, то есть не все экземпляры сущностей участвуют в связи.) Сущ1Сущ2(Ключ1, Ключ2) или Сущ1Сущ2(Ключ1, Ключ2). 2 способ. Точно так же, как и во 2 случае 1:М, новая таблица не создается, а в таблицу одной из сущностей (будем считать ее дочерней) добавляют ключевые поля другой сущности (будем считать ее родительской). (Если связь не является связью “ровно к одному” по отношению к родительской таблице, то есть не все экземпляры сущностей участвуют в связи, поле внешнего ключа в некоторых записях может быть пустым.) Таблица дочерней сущности: Сущность1(Ключ1, Атрибут1, Ключ2), или Сущность2(Ключ2, Атрибут2, Ключ1). 3 способ. Две таблицы для сущностей, связанных 1:1, объединяются в одну. Ключом новой таблицы может быть комбинация ключей обеих таблиц. Если хотя бы в одном направлении связь “ровно к одному”, то ключ этой сущности можно считать ключом объединенной таблицы. Таблицы Сущность1(Ключ1, Атрибут1) и Сущность2(Ключ2, Атрибут2) заменяются на Сущ1Сущ2(Ключ1, Атрибут1, Ключ2, Атрибут2) [или, возможно, Сущ1Сущ2(Ключ1, Атрибут1, Ключ2, Атрибут2), или Сущ1Сущ2(Ключ1, Атрибут1, Ключ2, Атрибут2)]. Примечание 1: Для связи сущности с самой собой применяются те же правила, но так как одна и та же сущность участвует в связи дважды, ключевые поля должны войти в одну и ту же таблицу два раза. Поэтому приходится переименовывать один из ключей. Рассмотрим связь 1:M, способ 2. Переименован внешний ключ. Сущность1(Ключ1, Атрибут1, ЕщеОдинКлюч1). Примечание 2: Для связей с арностью более 2 обычно применяется тот же способ, что и для бинарной связи M:M – создается новая таблица, содержащая ключевые поля всех связанных таблиц. Сущ1Сущ2Сущ3(Ключ1, Ключ2, Ключ3). 1.3 Выявление сущностей и связей для предметной области “Магазин по продаже компьютерных комплектующих”Перейдем непосредственно к нашей базе данных. В дальнейшем создавая ER модель ,нам перед этим необходимо определиться с сущностями нашей предметной области. Ключевые поля подчеркиваются прямой линией ,внешние ключи волнистой) Выявляем сущности нашей предметной области: 1.Создаем сущность сотрудник ключевым полем, является номер сотрудника, атрибутами: ФИО ,телефон ,адрес ,отдел в котором он работает. Сотрудник (№ сотрудника ,ФИО ,Телефон , Адрес ,отдел) 2.Создаем сущность заказчики ключевым полем, является номер заказчика, атрибутами: ФИО ,телефон ,адрес. Заказчики(№ заказчика ,ФИО ,Телефон ,Адрес) 3.Создаем сущность заказ ключевым полем, является номер заказа атрибутами: наименование товара ,количество ,дата оформление заказа, стоимость. Заказ(№ заказа ,Наименование ,Кол-во ,Дата ,Стоимость) 4.Создаем сущность товар ключевым полем ,является номер товара, атрибутами: наименование товара ,его стоимость , технические характеристики, количество. Товар(№товара ,Наименование ,Стоимость ,Кол-во ,Тех.хар.) 5.Создаем сущность склад ключевым полем, является номер склада, атрибутами: телефон и адрес. Склад(№склада ,Телефон ,Адрес) 6.Создаем сущность поставщик ключевым полем, является номер счета поставщика ,атрибутами: ФИО администратора фирмы поставщика ,адрес , банк для оплаты товара , стоимость , реквизиты ,телефон. Поставщик( № счета ,ФИО ,Телефон ,Адрес ,Стоимость, Реквизиты ,Банк) Далее установим связи между сущностями. Один сотрудник может принимать несколько заказов вследствие чего связь один ко многим .Несколько товаров могут состоять в нескольких заказах , связь многие ко многим в дальнейшем создадим отдельную таблицу для связи. Несколько сотрудников могут доставлять заказы нескольким заказчикам ,связь многие ко многим, в дальнейшем создадим отдельную таблицу для связи. Разные поставщики могут поставлять разный товар ,связь многие ко многим в дальнейшим создадим отдельную таблицу для связи. Множество товаров хранятся на одном складе, связь многие к одному. В дальнейшим создадим уже схематическую ER модель, ее же преобразуем в реляционную модель. 1.4 Основные термины.База данных - это совокупность сведений о реальных объектах, процессах, событиях или явлениях, относящихся к определённой теме или задаче, организованная таким образом, чтобы обеспечить удобное представление этой совокупности, как в целом, так и любой её части. Информационная система – это совокупность программно-аппаратных средств, способов и людей, которые обеспечивают сбор, хранение, обработку и выдачу информации для решения поставленных задач. На ранних стадиях использования информационных систем применялась файловая модель обработки. В дальнейшем в информационных системах стали применяться базы данных. Базы данных являются современной формой организации, хранения и доступа к информации. Примерами крупных информационных систем являются банковские системы, системы заказов железнодорожных билетов и т.д. Предметная область – это часть реального мира, подлежащая изучению с целью создания базы данных для автоматизации процесса управления. Наборы принципов, которые определяют организацию логической структуры хранения данных в базе, называются моделями данных. Система управления базами данных (СУБД) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных. Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Sav Zigzag, Microsoft SQL Server Compact, ЛИНТЕР. Модель Сущность-Связь (ER-модель) — модель данных, позволяющая описывать концептуальные схемы. Представляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных. В этом смысле ER-модель является мета-моделью данных, то есть средством описания моделей данных.ER-модель удобна при проектировании информационных систем, баз данных, архитектур компьютерных приложений, и других систем (далее, моделей). С её помощью можно выделить ключевые сущности, присутствующие в модели, и обозначить отношения, которые могут устанавливаться между этими сущностями .ER-модель является одной из самых простых визуальных моделей данных (графических нотаций). Она позволяет обозначить структуру «крупными мазками», в общих чертах. Это общее описание структуры называется ER-диаграммой или онтологией выбранной предметной области .На этапе перехода к реализации данной ER-диаграммы в виде реальной информационной системы или программы, происходит отображение ER-модели в более детальную модель данных реляционной (объектной, сетевой, логической, или др.) базы данных, которая называется даталогической моделью данных по отношению к исходной ER-диаграмме . Связи между объектами могут быть 3-х типов: Один – к одному. Этот тип связи означает, что каждому объекту первого вида соответствует не более одного объекта второго вида, и наоборот. Например: сотрудник может руководить только одним отделом, и у каждого отдела есть только один руководитель. Один – ко многим. Этот тип связи означает, что каждому объекту первого вида может соответствовать более одного объекта второго вида, но каждому объекту второго вида соответствует не более одного объекта первого вида. Например: в каждом отделе может быть множество сотрудников, но каждый сотрудник работает только в одном отделе. Многие – ко многим. Этот тип связи означает, что каждому объекту первого вида может соответствовать более одного объекта второго вида, и наоборот. Например: каждый счет может включать множество товаров, и каждый товар может входить в разные счета. Ключ – это столбец (может быть несколько столбцов), добавляемый к таблице и позволяющий установить связь с записями в другой таблице. Существуют ключи двух типов: первичные и вторичные или внешние. Первичный ключ – это одно или несколько полей (столбцов), комбинация значений которых однозначно определяет каждую запись в таблице. Первичный ключ не допускает значений Null и всегда должен иметь уникальный индекс. Первичный ключ используется для связывания таблицы с внешними ключами в других таблицах. Внешний (вторичный) ключ - это одно или несколько полей (столбцов) в таблице, содержащих ссылку на поле или поля первичного ключа в другой таблице. Внешний ключ определяет способ объединения таблиц. Из двух логически связанных таблиц одну называют таблицей первичного ключа или главной таблицей, а другую таблицей вторичного (внешнего) ключа или подчиненной таблицей. Существует три типа первичных ключей: ключевые поля счетчика (счетчик), простой ключ и составной ключ. Поле счетчика (Тип данных «Счетчик»). Тип данных поля в базе данных, в котором для каждой добавляемой в таблицу записи в поле автоматически заносится уникальное числовое значение. Простой ключ. Если поле содержит уникальные значения, такие как коды или инвентарные номера, то это поле можно определить как первичный ключ. В качестве ключа можно определить любое поле, содержащее данные, если это поле не содержит повторяющиеся значения или значения Null. Составной ключ. В случаях, когда невозможно гарантировать уникальность значений каждого поля, существует возможность создать ключ, состоящий из нескольких полей. Чаще всего такая ситуация возникает для таблицы, используемой для связывания двух таблиц многие - ко - многим. Необходимо еще раз отметить, что в поле первичного ключа должны быть только уникальные значения в каждой строке таблицы, т.е. совпадение не допускается, а в поле вторичного или внешнего ключа совпадение значений в строках таблицы допускается. Если возникают затруднения с выбором подходящего типа первичного ключа, то в качеcтве ключа целесообразно выбрать поле счетчика. Программы, которые предназначены для структурирования информации, размещения ее в таблицах и манипулирования данными называются системами управления базами данных (СУБД). Другими словами СУБД предназначены как для создания и ведения базы данных, так и для доступа к данным. В настоящее время насчитывается более 50 типов СУБД для персональных компьютеров. К наиболее распространенным типам СУБД относятся: MS SQL Server, Oracle, Informix, Sybase, DB2, MS Access и т. д Сущность – любой конкретный или абстрактный объект в рассматриваемой предметной области. Сущности – это базовые типы информации, которые хранятся в БД (в реляционной БД каждой сущности назначается таблица). К сущностям могут относиться: студенты, клиенты, подразделения и т.д. Экземпляр сущности и тип сущности - это разные понятия. Понятие тип сущности относится к набору однородных личностей, предметов или событий, выступающих как целое (например, студент, клиент и т.д.). Экземпляр сущности относится, например, к конкретной личности в наборе. Типом сущности может быть студент, а экземпляром – Петров, Сидоров и т. д. Атрибут – это свойство сущности в предметной области. Его наименование должно быть уникальным для конкретного типа сущности. Например, для сущности студент могут быть использованы следующие атрибуты: фамилия, имя, отчество, дата и место рождения, паспортные данные и т.д. В реляционной БД атрибуты хранятся в полях таблиц. Связь – взаимосвязь между сущностями в предметной области. Связи представляют собой соединения между частями БД (в реляционной БД – это соединение между записями таблиц). Сущности – это данные, которые классифицируются по типу, а связи показывают, как эти типы данных соотносятся один с другим. Если описать некоторую предметную область в терминах сущности – связь, то получим модель сущность - связь для этой БД. Хранимая процедура — объект базы данных, представляющий собой набор SQL-инструкций, который компилируется один раз и хранится на сервере. Хранимые процедуры очень похожи на обыкновенные процедуры языков высокого уровня, у них могут быть входные и выходные параметры и локальные переменные, в них могут производиться числовые вычисления и операции над символьными данными, результаты которых могут присваиваться переменным и параметрам. В хранимых процедурах могут выполняться стандартные операции с базами данных (как DDL, так и DML). Кроме того, в хранимых процедурах возможны циклы и ветвления, то есть в них могут использоваться инструкции управления процессом исполнения. Представление — виртуальная (логическая) таблица, представляющая собой поименованный запрос (алиас к запросу), который будет подставлен как подзапрос при использовании представления. В отличие от обычных таблиц реляционной БД, представление не является самостоятельной частью набора данных, хранящегося в базе. Содержимое представления динамически вычисляется на основании данных, находящихся в реальных таблицах. Изменение данных в реальной таблице БД немедленно отражается в содержимом всех представлений, построенных на основании этой таблицы. 2.Создание ER и реляционной модели данных, запросов, представлений, хранимых процедур, курсоров и триггеров для предметной области “Магазин по продаже компьютерных комплектующих”2.1 Создание ER и реляционной модели данных для предметной области “магазин по продаже компьютерных комплектующих”На следующем рисунке 1, представлена ER модель которая отображает сущности и связи.  Рисунок 1.ER модель.Далее представлена реляционная модель данных. Заказ(№Заказа ,Наименование ,Кол-во ,Дата ,Стоимость ,№Сотрудника) Сотрудники(№Сотрудника, ФИО, Телефон, Адрес , Отдел) Товар(№Товара, Наименование, Стоимость, Тех.характеристики, №Склада ) Сборка заказа(№Склада, №Товара) Заказчики(№Заказчика ,ФИО, Телефон, Адрес) Доставка(№Сотрудника, №Заказчика, Дата, Время) Склад(№Склада, Телефон, Адрес) Поставщик(№Счета, ФИО, Адрес, Банк, Стоимость, Реквизиты, Телефон) Поставка товара(№Товара, №Счета, Дата, Место, Время) Содержание заказа(№Заказа ,№товара) 2.2 Создание таблиц в MS SQL Server 2008 для предметной области “Магазин по продаже компьютерных комплектующих”В этом разделе представлен сценарий создания таблиц в MS SQL Server 2008. Создадим базу данных “KOMPLEKT”, которая будет храниться на сервере: CREATE DATABASE KOMPLEKT Создадим таблицу, в которой будут храниться данные о сотрудниках: CREATE TABLE sotr (sotr_num NUMERIC(3) IDENTITY PRIMARY KEY, sotr_fio VARCHAR(10), sotr_tel NUMERIC(10), sotr_id NUMERIC(10), sotr_otdel VARCHAR(10), ); Создадим таблицу, в которой будут храниться данные о заказчиках: CREATE TABLE zakazchiki (zakazchiki_num NUMERIC(3) IDENTITY PRIMARY KEY, zakazchiki_fio VARCHAR(10), zakazchiki_tel NUMERIC(10), zakazchiki_id NUMERIC(10), ); Создадим таблицу, в которой будут храниться данные о складе, на котором храниться товар: CREATE TABLE sklad (sklad_num NUMERIC(10) IDENTITY PRIMARY KEY, sklad_tel NUMERIC(10), sklad_id NUMERIC(10), ); Создадим таблицу, в которой будут храниться данные о поставщиках: CREATE TABLE postavshik (postavshik_chet_num NUMERIC(3) IDENTITY PRIMARY KEY, postavshik_fio VARCHAR(10), postavshik_id NUMERIC(10), postavshik_bank VARCHAR(10), postavshik_stoimost NUMERIC(10), postavshik_rekvezitu NUMERIC(10), postavshik_tel NUMERIC(10), ); Создадим таблицу, в которой будут храниться данные о заказе: CREATE TABLE zakaz (zakaz_num NUMERIC(3) IDENTITY PRIMARY KEY, zakaz_naim VARCHAR(10), zakaz_kol_vo NUMERIC(3), zakaz_date NUMERIC(10), zakaz_stoim NUMERIC(10), sotr_num NUMERIC(3), CONSTRAINT zakaz_sotr_num FOREIGN KEY (sotr_num) REFERENCES sotr (sotr_num) ); Создадим таблицу, в которой будут храниться данные о товаре: CREATE TABLE Tovar (Tovar_num NUMERIC(10) IDENTITY PRIMARY KEY, Tovar_naim VARCHAR(10), Tovar_stoim NUMERIC(10), Tovar_teh_har VARCHAR(10), Sklad_num NUMERIC(10), Tovar_stoim_1ED NUMERIC(10) CONSTRAINT Tovar_sklad_num FOREIGN KEY(sklad_num) REFERENCES sklad (sklad_num) Создадим таблицу, в которой будут храниться данные о сборке заказа: CREATE TABLE sborka_zakaza (sklad_num NUMERIC(10), tovar_num NUMERIC(10), CONSTRAINT sborka_zakaza_num PRIMARY KEY (sklad_num, tovar_num), CONSTRAINT sborka_zakaza_sklad_num FOREIGN KEY (sklad_num) REFERENCES sklad (sklad_num), CONSTRAINT sborka_zakaza_tovar_num FOREIGN KEY (tovar_num) REFERENCES tovar (tovar_num) ); Создадим таблицу, в которой будут храниться данные о доставке товара: CREATE TABLE dostavka (sotr_num NUMERIC(3), zakazchiki_num NUMERIC(3), data DATETIME, CONSTRAINT dostavka_num PRIMARY KEY (sotr_num, zakazchiki_num), CONSTRAINT dostavka_sotr_num FOREIGN KEY (sotr_num) REFERENCES sotr (sotr_num), CONSTRAINT dostavka_zakazchiki_num FOREIGN KEY (zakazchiki_num) REFERENCES zakazchiki (zakazchiki_num) ); Создадим таблицу, в которой будут храниться данные о составе определенного заказа: CREATE TABLE sostav_zakaz (zakaz_num NUMERIC(3), tovar_num NUMERIC(10), CONSTRAINT sostav PRIMARY KEY (zakaz_num, tovar_num), CONSTRAINT sostav_zakaz_zakaz_num FOREIGN KEY (zakaz_num) REFERENCES zakaz (zakaz_num), CONSTRAINT sostav_zakaz_zakaza_tovar_num FOREIGN KEY (tovar_num) REFERENCES tovar (tovar_num) ); Создадим таблицу, в которой будут храниться данные о поставке товара фирмой поставщика: CREATE TABLE postavka (tovar_num NUMERIC(10), postavshik_chet_num NUMERIC(3), data DATATIME, mesto VARCHAR(10), CONSTRAINT postavka_num PRIMARY KEY (tovar_num, postavshik_chet_num), CONSTRAINT postavka_tovar_num FOREIGN KEY (tovar_num) REFERENCES tovar (tovar_num), CONSTRAINT postavka_postavchik_chet_num FOREIGN KEY (postavshik_chet_num) REFERENCES postavshik (postavshik_chet_num) ); 2.3 Создание запросов для предметной области “Магазин по продаже компьютерных комплектующих”Приведем сценарий и результат работы запросов: 1.Запрос выводит: наименование заказа и общую их стоимость.  Рисунок 2.1. Пример запроса “Сумма заказа” 2.Запрос выводит: ФИО сотрудника доставлявший определенный заказ  Рисунок 2.2. Пример запроса “ФИО сотрудника доставки” 3.Запрос выводит: Модель и стоимость товара с технической характеристикой “2.8Ghz”.  Рисунок 2.3.Пример запроса “Техническая характеристика товара” 4.Запрос выводит: номер заказа, наименование и стоимость товара входящий в определенный заказ, наименование товара упорядочено в алфавитном порядке.  Рисунок 2.4.Пример запроса “Данные о заказе” 5.Запрос выводит: поставки товара фирмой поставщика в город Москва, ФИО и телефон администратора.  Рисунок 2.5.Пример запроса “Данные о доставке” 2.4 Создание хранимых процедур для предметной области “Магазин по продаже компьютерных комплектующих”Приведем сценарий и результат работы хранимых процедур: 1.Процдура уменьшает всю стоимость товара на 80% CREATE PROC my_proc1 AS UPDATE tovar SET tovar_stoim=tovar_stoim*0.2 EXEC my_proc1-запускает процедуру До применение процедуры:  После применение процедуры  Рисунок 3.1. Пример хранимой процедуры “Уменьшение стоимости” 2.Процедура с входным параметром. В этом примере мы вызываем процедуру для вывода наименование и стоимость модели с входным параметром, техническая характеристика “3.2Ghz”.  Рисунок 3.2. Пример хранимой процедуры “Техническая характеристика” 3.Процедура с входным и выходным параметром, входной параметр номер склада в нашем случаи 1, выходным параметром является сумма товара.  Рисунок 3.3. Пример хранимой процедуры “Сумма товара” 2.5 Создание представлений для предметной области “Магазин по продаже компьютерных комплектующих”Приведем сценарий и результат работы представлений: 1.Не обновляемое представление, так как имеется итоговое значение.Изменяемым будет являться любое другое представление без использование итогового значаения. CREATE VIEW sss AS Select zakaz_naim AS'Наименование' ,zakaz_stoim AS'Стоимость' from zakaz Union Select 'Итого', sum (zakaz_stoim) from zakaz  Рисунок 4.1. Пример представления “Не обновляемый” 2.Горизонтальное представление ,ускоряет работу с запросами при выходе которых получается горизонтальный результат. Запрос показывает, какому именно заказчику доставил заказ определенный работник, в нашем случаи Дрэ Д.В. CREATE VIEW aa AS Select sotr_fio, zakazchiki_num from dostavka Join sotr on (dostavka.sotr_num=sotr.sotr_num) where sotr_fio='Дрэ Д.В.'  Рисунок 4.2. Пример представления “Горизонтальное” 3.Вертикально представление, ускоряет работу с запросами при выходе которых получается вертикальный результат. Запрос показывает номер товара хранящийся на определенном складе, в нашем случаи на складе номер 1. CREATE VIEW aaa AS Select tovar_num From sborka_zakaza where sborka_zakaza.sklad_num=1  Рисунок 4.3. Пример представления “Вертикальное” Заключение.В данной курсовой работе были выполнены все поставленные задачи: подчеркнута актуальность предметной области “Магазин по продаже компьютерных комплектующих ,разработан план работы над созданием базой данных и реализации ее в MS SQL Server 2008, разобраны потребности от базы данных для кого она и создавалась в нашем случаи для администратора. В теоретической части оговаривается о ходе работы магазина компьютерных комплектующих, правило создание ER и реляционной модели данных, даны определения основным понятиям необходимые для создания и реализации базы данных, описано создание моделей данных для нашей предметной области. В практической части предоставлены ER и реляционная модель данных, код написание таблиц для MS SQL server 2008.Созданные запросы, представления ,хранимые процедуры ,курсоры, триггеры, написаны с применением скриншотов выполненной работы и расписаны каждые действия пошагово. Предыдущие действия выполнялись в связи с поставленной задачей и необходимостью их использование администратором. Список используемой литературы.1. М.Ф. Гарсиа, Дж. Рединг, Э Уолен, С.А. ДеЛюк. «Microsoft SQL Server 2000. Справочник администратора». Издательство: «ЭКОМ», Москва, 2002. 2. «Администрирование Microsoft SQL Server 2000. Учебный курс MCSA/MCSE, MCDBA. Сертификационный экзамен 70-228». Издательство «Русская редакция», Издание 2-е, исправленное. Москва, 2003. 3. «Проектирование и реализация баз данных Microsoft SQL Server 2000. Учебный курс MCAD/MCSE/MCDBA». Экзамен 70-229. Издательство «Русская редакция», Питер, Microsoft Corporation, 2006 г. 4. Mike Aubert. «Изучи сервер Windows SQL 2000 за 15 минут в неделю» (серия статей). 5. Учебное пособие к «Microsoft Official Course 2072a Administering a Microsoft SQL Server 2000 Database» 6. Системы Управления Базами Данных #1/97 стр. 30-50. А.В. Шуленин. 7. Microsoft SQL Server 6.5. Комплект документации. 8. MS SQL Server 6.5 Unleashed, by David Solomon, Ray Rankins, et al, ISBN 0-672-30956-4. 9. Microsoft SQL Server 6.5 DBA Survival Guide, by Mark Spenik & Orryn Sledge, ISBN 0-672-30797-9. 10. Hitchhiker's Guide to Visual Basic & SQL Server, by William.R.Vaughn, ISBN 1-55615-906-4. 11. Clustering Support for Microsoft SQL Server. White Paper. 12. Кастер Х. "Основы Windows NT и NTFS", Microsoft Press. "Русская Редакция", 1996. 13. Transaction Processing,by Jim Gray & Andreas Reuter,ISBN 1-55860-190-2 14. Круглински Д. "Основы Visual C++", части IV-V, Microsoft Press. "Русская Редакция", 1997. 15. Inside COM, by Dale Rogerson, Microsoft Press, ISBN 1-57231-349-8. 16. Шуленин А. "Microsoft SQL Server и активный Internet". Материалы Форума "Информационные |