Создание таблиц и ограничений.
На основе спецификаций сущностей и словаря данных, сформулированных в пятом семестре, были созданы таблицы, в которых находятся описания всех атрибутов сущностей и ограничения, накладываемые на эти атрибуты. Для удобства запуска базы данных сначала были созданы таблицы без ограничений (приложение 5), затем с помощью функции ALTER были наложены все необходимые ограничения (приложение 6). Таблицы базы данных именуются в соответствии с их содержимым и на английском языке, т.к. он является интернациональным.Именование процедур и функций осуществляется по следующему шаблону: добавление <имя таблицы>INCERT, удаление-<имя таблицы>Delete, обновление -<имя таблицы>Update.
CREATE TABLE Hydrant --(Описаниегидранта) (Net BIT NOT NULL, Caliber INT NOT NULL, IDWaterSource INT NOT NULL, );
Для атрибута Сеть был выбран тип данных BIT, так как существует два типа сети: кольцевая (0)итупиковая (1).
ALTERTABLEHydrant WITH CHECK ADD CONSTRAINT HydrantCaliber CHECK (Caliber>0), CONSTRAINT HydrantWaterSourceForeign FOREIGN KEY (IDWaterSource) REFERENCES WaterSource ONUPDATECASCADE;
CREATE TABLE Pond --(Описание водоема) (Size INT NOT NULL, IDWaterSource INT NOT NULL);
ALTER TABLE Pond WITH CHECK ADD CONSTRAINT PondSize CHECK (Size>0), CONSTRAINT PondWaterSourceForeign FOREIGN KEY (IDWaterSource) REFERENCES WaterSource ON UPDATE CASCADE;
В таблице «Улица»был выделен уникальный ключ «ID Улицы».
Таблица «Улица» является справочником, поэтому на название улиц было наложено ограничение уникальности, чтобы исключить дублирование записей в таблице.
CREATE TABLE Street --(Описаниеулицы) (IDStreet INT IDENTITY NOT NULL, NameStreet VARCHAR(40) NOT NULL);
ALTER TABLE Street WITH CHECK ADD CONSTRAINT StreetPrimary PRIMARY KEY (IDStreet), CONSTRAINT NameStreetUnique UNIQUE(NameStreet);
CREATE TABLE TypeOfOrganization --(Вид организации) (IDTypeOfOrganization INT IDENTITY NOT NULL, NameTypeOfOrganization VARCHAR(50) NOT NULL);
ALTER TABLE TypeOfOrganization WITH CHECK ADD CONSTRAINT IDTypeOfOrganizationPrimary PRIMARY KEY (IDTypeOfOrganization);
CREATETABLEOrganization--(Организации) (IDOrganization INT IDENTITY NOT NULL, NameOrganization VARCHAR(50) NOT NULL, Dissolution DATETIME NULL, --(датарасформированияорганизации) IDTypeOfOrganization INT NOT NULL);
ALTER TABLE Organization WITH CHECK ADD CONSTRAINT IDOrganizationPrimary PRIMARY KEY (IDOrganization), CONSTRAINT NameOrganizationUnique UNIQUE (NameOrganization), CONSTRAINT OrganizationTypeForeign FOREIGN KEY (IDTypeOfOrganization) REFERENCES TypeOfOrganization ON UPDATE CASCADE;
Атрибут «название водоисточника» взят длиной 10 символов, т.к. название составляется по следующей схеме: ПВ-23. То есть вначале идет обозначение состоящее из 2-х букв (ПВ – для водоемов и ПГ – для гидрантов), а далее номер гидранта или водоема.
Также атрибут «номер дома» является символьной величиной, т.к. номер дома может содержать букву (22а) или другие символы (45/2). CREATETABLEWaterSource--(Водоисточник) (IDWaterSource INT IDENTITY NOT NULL, NameWaterSource VARCHAR(10) NOT NULL DEFAULT 'ПГ-', Building VARCHAR(10) NOT NULL, IDStreet INT NOT NULL, IDOrganization INT NOT NULL);
ALTER TABLE WaterSource WITH CHECK ADD CONSTRAINT IDWaterSourcePrimary PRIMARY KEY (IDWaterSource), CONSTRAINT WaterSourceStreetForeign FOREIGN KEY (IDStreet) REFERENCES Street, CONSTRAINT WaterSourceOrganizationForeign FOREIGN KEY (IDOrganization) REFERENCES Organization;
CREATE TABLE Inspection --(Проверка) (IDInspection INT IDENTITY NOT NULL, DateInspection DATETIME NOT NULL, IDWaterSource INT NOT NULL);
ALTER TABLE Inspection WITH CHECK ADD CONSTRAINT IDInspectionPrimary PRIMARY KEY (IDInspection), CONSTRAINT InspectionOrganizationForeign FOREIGN KEY (IDWaterSource) REFERENCES WaterSource;
CREATE TABLE Defect --(Неисправность) (IDDefect INT IDENTITY, NameDefect VARCHAR(100) NOT NULL, RepairTime INT NOT NULL, Serviceability BIT NOT NULL, IDTypeOfOrganization INT NOT NULL);
ALTER TABLE Defect WITH CHECK ADD CONSTRAINT IDDefectPrimary PRIMARY KEY (IDDefect), CONSTRAINT DefectTypeOrgForeign FOREIGN KEY (IDTypeOfOrganization) REFERENCES TypeOfOrganization;
CREATE TABLE Letter --(Письмо-запрос) (IDLetter INT IDENTITY NOT NULL, DataSend DATETIME NULL, LetterNumber INT NULL, DateNextInspection DATETIME NULL, TypeOfLetter VARCHAR(30) NOT NULL, IDOrganization INT NOT NULL, IDInspection INT NOT NULL);
ALTER TABLE Letter WITH CHECK ADD CONSTRAINT IDLetterPrimary PRIMARY KEY (IDLetter), CONSTRAINT LetterOrganizationForeign FOREIGN KEY (IDOrganization) REFERENCES Organization, CONSTRAINT LetterInspectionForeign FOREIGN KEY (IDInspection) REFERENCES Inspection, CONSTRAINT LetterLetterForeign FOREIGN KEY (IDLetter) REFERENCES Letter;
CREATE TABLE TestDefect --(проверка неисправности) (IDDefect INT NOT NULL, IDInspection INT NOT NULL, IDLetter INT NOT NULL);
ALTER TABLE TestDefect WITH CHECK ADD CONSTRAINT DefectTestDefectForeign FOREIGN KEY (IDDefect) REFERENCES Defect, CONSTRAINT TestDefectInspectionForeign FOREIGN KEY (IDInspection) REFERENCES Inspection, CONSTRAINT LetterTestDefectForeign FOREIGN KEY (IDLetter) REFERENCES Letter;
Хранимые процедуры Хранимые процедуры представляют собой набор команд, состоящий из одного или нескольких операторов SQL и сохраняемый в базе данных в откомпилированном виде, что обеспечивает быстрый доступ к данным. В данном курсовом проекте хранимые процедуры были применены для ограничения доступа пользователей к таблицам базы данных, а так же для разграничения прав на добавление/редактирование/удаление данных.
Процедуры добавления, удаления и обновления были реализованы для всех таблиц БД.
Процедуры добавления данных (приложение 7): · PHydrantInsert – добавление гидранта · PPondInsert – добавление водоема · PStreetInsert – добавление улицы · PToOrganozationInsert – добавление типа организации · POrganizationInsert – добавление организации · PWaterSourceInsert – добавление водоисточника · PInspectionInsert – добавление проверки · PDefectInsert – добавление неисправности · PLetterInsert – добавление письма · PTestDefectInsert – добавление в слабую сущность Проверка неисправности Процедуры обновления данных (приложение 8): · PHydrantUpdate – обновление гидранта · PPondUpdate - обновление водоема · PStreetUpdate – обновление улицы · PToOrganozationUpdate – обновление типа организации · POrganizationUpdate – обновление организации · PWaterSourceUpdate – обновление водоисточника · PInspectionUpdate– обновление проверки · PDefectUpdate – обновление неисправности · PLetterUpdate – обновление письма · PTestDefectUpdate – обновление слабой сущности Проверка неисправности Процедуры удаления данных (приложение 9): · PHydrantDelete – удаление гидранта · PPondDelete - удаление водоема · PStreetDelete – удаление улицы · PToOrganozationDelete –удаление типа организации · POrganizationDelete – удаление организации
· PWaterSourceDelete – удаление водоисточника · PInspectionDelete– удаление проверки · PDefectDelete – удаление неисправности · PLetterDelete – удаление письма · PTestDefectDelete – удаление слабой сущности Проверка неисправности В качестве примера процедуры добавления данных ниже приведенахранимая процедура, которая будет вводить данные в таблицу Organization. CREATE PROC POrganizationInsert @NameOrganization VARCHAR(50), @Dissolution DATE, @IDTypeOfOrganization INT AS INSERT INTO Organization (NameOrganization, Dissolution, IDTypeOfOrganization) VALUES (@NameOrganization, @Dissolution, @IDTypeOfOrganization)
Пример процедуры удаления данных из таблицы Street.
CREATE PROC PStreetDelete @IDStr INT AS DELETE FROM Street WHERE IDStreet=@IDStr
Пример процедуры обновления (замены) данных в таблицеDefect.
CREATE PROC PDefectUpdate @NameDefect VARCHAR(100), @RepairTime INT, @Serviceability BIT, @IDTypeOfOrganization INT, @IDDef INT AS UPDATE Defect SET NameDefect=@NameDefect, RepairTime=@RepairTime, Serviceability=@Serviceability, IDTypeOfOrganization=@IDTypeOfOrganization WHERE IDDefect=@IDDef
Выходные формы В рамках данного курсового проекта организация данных в виде БД преимущественно была необходима для того, чтобы из БД можно было оперативно получить статистические данные, отчетные формы и другую необходимую и полезную для работы информацию.
Для получения конечных отчетных форм были использованы: · Отчетные хранимые процедуры · Отчетные хранимые функции В рамках данного курсового проекта были реализованы следующие хранимые процедуры и функции (приложение 11): · PlanProverki – функция, возвращающая гидранты и водоемы подлежащие проверке в заданный день. · PPlanProverki – процедура, которая выводит данные, полученные вышеуказанной процедурой · LetterToOrganization – функция, возвращающая данные, необходимые для отправки письма в обслуживающую организацию. · PLetterToOrganization - процедура, которая выводит данные, полученные вышеуказанной процедурой · LetterToGPN - функция, возвращающая данные, необходимые для отправки письма в ГосПожНадзор. · PLetterToGosPN - процедура, которая выводит данные, полученные вышеуказанной процедурой · PWSFind – процедура, выводящая личную карточку водоисточника
Пример отчета, о гидрантах и водоемах, подлежащих проверке в заданный день. В качестве входных параметров подаем дату проверки, для которой будет выводиться отчет. Далее, используя этотпараметр, получаем данные о всех водоисточниках, подлежащих проверке.
CREATE FUNCTION PlanProverki (@DAT DATE) RETURNS @Result TABLE ( NameWaterSource VARCHAR (10), NameStreet VARCHAR(40), Building VARCHAR(10), NameDefect VARCHAR(100), RepairTime INT, DateInspection DATE) AS BEGIN
declare @IDDP TABLE ( IDWaterSource INT, DateP DATE)
INSERT INTO @IDDP SELECT WS.IDWaterSource, MAX(DateInspection) [DP] FROM WaterSource WS INNER JOIN Street S ON WS.IDStreet=S.IDStreet INNER JOIN Inspection I ON WS.IDWaterSource=I.IDWaterSource INNER JOIN TestDefect TD
ON TD.IDInspection=I.IDInspection INNER JOIN Defect D ON D.IDDefect=TD.IDDefect GROUP BY WS.IDWaterSource
INSERT INTO @Result SELECT WS.NameWaterSource [Название], S.NameStreet [Улица], WS.Building [Дом], D.NameDefect [Неисправность], D.RepairTime [Время на устранение], I.DateInspection [Датапроверки] FROM WaterSource WS INNER JOIN Street S ON WS.IDStreet=S.IDStreet INNER JOIN Inspection I ON WS.IDWaterSource=I.IDWaterSource INNER JOIN TestDefect TD ON TD.IDInspection=I.IDInspection INNER JOIN Defect D ON D.IDDefect=TD.IDDefect INNER JOIN @IDDP IDDP ON IDDP.IDWaterSource=WS.IDWaterSource WHERE ((IDDP.DateP=I.DateInspection) AND (D.NameDefect='исправен') AND (DATEADD(dd,30,IDDP.DateP)<=@DAT))
INSERT INTO @Result SELECT WS.NameWaterSource [Название], S.NameStreet [Улица], WS.Building [Дом], D.NameDefect [Неисправность], D.RepairTime [Время на устранение], I.DateInspection [Датапроверки] FROM WaterSource WS INNER JOIN Street S ON WS.IDStreet=S.IDStreet INNER JOIN Inspection I ON WS.IDWaterSource=I.IDWaterSource INNER JOIN TestDefect TD ON TD.IDInspection=I.IDInspection INNER JOIN Defect D ON D.IDDefect=TD.IDDefect INNER JOIN @IDDP IDDP ON IDDP.IDWaterSource=WS.IDWaterSource INNER JOIN Letter L ON L.IDLetter=TD.IDLetter WHERE ((IDDP.DateP=I.DateInspection) AND (D.NameDefect!='исправен') AND (L.DateNextInspection<=@DAT)) RETURN; END
Процедура, которая отображает данные, полученные функцией.
CREATE PROC PPlanProverki(@Dat DATE) AS SELECT NameWaterSource [Название], NameStreet [Улица], Building [Дом], NameDefect [Неисправность], RepairTime [Время на устранение], DateInspection [Дата предыдущей проверки] FROM PlanProverki(@Dat)
EXEC PPlanProverki '21-01-2012'
Обеспечение безопасности
В ходе изучения предметной области в рамках курсового проекта по дисциплине «Управление данными» были определены основные пользователи для работы с базой данных: · Начальник караула · Начальник части
Начальник караулавносит/редактирует данные о водоисточниках, результатах проверок, а также создает отчеты о необходимых проверках. Начальник частиформирует письма в ГосПожНадзор и в обслуживающие организации, но также может выполнять все функции, которые выполняет начальник караула.
Так как начальников караула в части несколько (в рассматриваемой части 4), а также заместитель начальника части может выполнять функции начальника части, было создано две роли (приложение 12 - роли): · Начальника караула · Начальник части
CREATE ROLE NachKar
CREATE ROLE Nach
Ролям были выделены следующие права доступа (приложение 12 – права на роли):
Где R – права на чтение, W - права на запись, E – права на редактирование, D – права на удаление.
В свою очередь на каждую роль были созданы пользователи (приложение 12 - пользователи): · Начальник караула 1 · Начальник караула 2 · Начальник караула 3 · Начальник караула 4 · Начальник части · Заместитель начальника части
USE WaterSources CREATE USER NachKar1 WITHOUT LOGIN
USE WaterSources CREATE USER NachKar2 WITHOUT LOGIN
USE WaterSources CREATE USER NachKar3 WITHOUT LOGIN
USE WaterSources CREATE USER NachKar4 WITHOUT LOGIN
USE WaterSources CREATE USER Nach1 WITHOUT LOGIN
USE WaterSources CREATE USER ZamNach1 WITHOUT LOGIN
Добавление пользователей к ролям (приложение 12 – добавление пользователей к ролям): sp_addrolemember NachKar, NachKar1 sp_addrolemember NachKar, NachKar2 sp_addrolemember NachKar, NachKar3 sp_addrolemember NachKar, NachKar4
sp_addrolemember Nach, Nach1 sp_addrolemember Nach, ZamNac
Таким образом, безопасность базы данных была обеспечена за счет создания необходимого числа учетных записей для различных ролей пользователей БД, ограничения их доступа к таблицам и предоставления им права выполнения хранимых процедур, отвечающих за необходимые им действия.
Оптимизация
Несмотря на то, что пользователей у системы немного, это не понижает требования к ее быстродействию. Первоначально анализ оптимизации проводился на уровне запросов, было выяснено, что в первую очередь надо связывать сущности, у которых меньше строк и больше критериев для соединения, и далее по возрастанию, тогда результирующий набор строк будет формироваться быстрее. Кроме того, по возможности стоит проанализировать все вводимые данные и на их основе сформировать ограничения CHECK. При реализации процедур и функций по возможности стоит избегать сильной вложенности одних процедур в другие, это замедляет поиск. Триггеры стоит использовать только в крайних случаях, потому что они сильно нагружают систему. Для того, чтобы поиск по данным и запросы осуществлялись быстрее были введены такие объекты базы данных, как индексы. Индекс – особый объект БД, создаваемый с целью увеличения производительности поиска данных. По умолчанию в СУБД Microsoft SQL Server создаются кластеризованные индексы. Помимо кластеризованных, в данном курсовом проекте были использованы некластеризованные индексы, которые накладывались на внешние ключи.
Примерыиндексов (приложение 13): CREATE UNIQUE INDEX UniqueStreet ON Street (NameStreet ASC)
CREATE NONCLUSTERED INDEX OrganizationIDTypeOfOrganization ON Organization (IDTypeOfOrganization ASC) CREATE UNIQUE INDEX UniqueNameOrganization ONOrganization (NameOrganizationASC)
Тестирование
Для проверки корректности физической модели и правильности реализованных процедур и функций в хранилище данных были введены тестовые данные для каждой из имеющихся сущностей. Процедура тестирования заключалась в том, что с помощью скрипта создавалась новая база данных. Далее создавались все декларативные ограничения, накладываемые на эти таблицы. После создавались хранимые процедуры вставки, обновления и удаления; хранимые процедуры и функции, необходимые для формирования отчетом; триггеры; индексы; матрица доступа. Далее запускались тестовые данные для таблиц, затем вызывались функции формирования отчетов (приложение 14).
EXEC PStreetInsert 'Стахановская' EXEC PStreetInsert 'Савина' EXEC PStreetInsert 'Заводская' EXEC PStreetInsert 'Кирова' EXEC PStreetInsert 'Лесозаводская' EXEC PStreetInsert 'Школьная' EXEC PStreetInsert 'Почтовая' EXEC PStreetInsert 'Северная'
EXEC PToOrganozationInsert 'балансосодержащая' EXEC PToOrganozationInsert 'обслуживающая'
EXEC POrganizationInsert 'МУП "Сыктывкарский Водоканал"',NULL,1 EXEC POrganizationInsert '"СпецАвтоХозяйство"',NULL,2 EXEC POrganizationInsert 'ТСЖ "Лесозаводское"',NULL,2 EXEC POrganizationInsert 'ТСЖ "Северная-61"',NULL,2
EXEC PWaterSourceInsert 'ПГ-93','40', 1, 1 EXEC PWaterSourceInsert 'ПГ-6','7', 2, 2 EXEC PWaterSourceInsert 'ПГ-14','68', 3, 1 EXEC PWaterSourceInsert 'ПГ-5','79-а', 4, 2 EXEC PWaterSourceInsert 'ПГ-41','61', 8, 4 EXEC PWaterSourceInsert 'ПГ-97','2/5', 6, 3 EXEC PWaterSourceInsert 'ПВ-300','69', 2, 1
EXEC PHydrantInsert 1,250,1 EXEC PHydrantInsert 0,200,2 EXEC PHydrantInsert 0,100,3 EXEC PHydrantInsert 0,150,4 EXEC PHydrantInsert 0,150,5 EXEC PHydrantInsert 0,200,6
EXEC PPondInsert 300,7
EXEC PInspectionInsert '23-06-2011',1 EXEC PInspectionInsert '26-07-2011',1 EXEC PInspectionInsert '28-08-2011',1 EXEC PInspectionInsert '10-09-2011',1 EXEC PInspectionInsert '13-10-2011',1 EXEC PInspectionInsert '18-11-2011',1 EXEC PInspectionInsert '19-12-2011',1 EXEC PInspectionInsert '25-08-2011',2 EXEC PInspectionInsert '26-09-2011',2 EXEC PInspectionInsert '30-10-2011',2 EXEC PInspectionInsert '5-11-2011',2 EXEC PInspectionInsert '13-11-2011',2 EXEC PInspectionInsert '25-11-2011',2
EXEC PDefectInsert 'исправен', 0, 1,1 EXEC PDefectInsert 'исправен', 0, 1,1 EXEC PDefectInsert 'поломан кран', 10, 1,1 EXEC PDefectInsert 'исправен', 0, 1,1 EXEC PDefectInsert 'исправен', 0, 1,1 EXEC PDefectInsert 'исправен', 0, 1,1 EXEC PDefectInsert 'поломан кран', 10, 0,1 EXEC PDefectInsert 'исправен', 0, 1,2 EXEC PDefectInsert 'исправен', 0, 1,2 EXEC PDefectInsert 'нет конуса', 4, 1,2 EXEC PDefectInsert 'не очищен', 5, 1,2 EXEC PDefectInsert 'исправен', 0, 1,2 EXEC PDefectInsert 'исправен', 0, 1,2 EXEC PDefectUpdate 'поломан кран', 10, 0,1,3 EXEC PDefectDelete 4 EXEC PInspectionDelete 8 EXEC PInspectionUpdate '10-12-2011',2,12
EXEC PLetterInsert '29-08-2011',NULL,'10-09-2011','в организацию',1,3 EXEC PLetterInsert '30-10-2011',NULL,'5-11-2011','в организацию',2,9 EXEC PLetterInsert '6-11-2011',NULL,'13-11-2011','в организацию',2,10 EXEC PLetterInsert '21-12-2011',NULL,'05-01-2012','в организацию',1,13
EXEC PTestDefectInsert 1,1,NULL EXEC PTestDefectInsert 2,2,NULL EXEC PTestDefectInsert 3,3,1 EXEC PTestDefectInsert 5,4,NULL EXEC PTestDefectInsert 6,5,NULL EXEC PTestDefectInsert 7,6,NULL EXEC PTestDefectInsert 8,7,NULL EXEC PTestDefectInsert 9,9,2 EXEC PTestDefectInsert 10,10,3 EXEC PTestDefectInsert 11,11,NULL EXEC PTestDefectInsert 12,12,NULL EXEC PTestDefectInsert 13,13,4
EXEC PPlanProverki '21-01-2012'
EXEC PLetterToOrganization 1
Заключение
Данный курсовой проект является продолжением курсовых проектов по дисциплинам «Управление данными» и «Информационные технологии». В ходе выполнения этих курсовых проектов была выбрана и изучена предметная область «Учет состояния пожарных гидрантов и водоемов, закрепленных за учебной пожарной частью». Выделены такие основные сущности и процессы, как Street, Hydrant,Pond, TypeOfOrganization, Organization, WaterSource, Inspection, Defect, Letterи TestDefect была построена логическая модель базы данных, а также определены атрибуты таблиц и выбраны типы данных. В данном курсовомпроекте была реализована физическая модель базы данных из вышеперечисленных сущностей, были расставлены ограничения PRIMARY KEY, FOREIGN KEY, UNIQUE. Проанализированы данные, которые будут храниться в БД, и на их основе были выделены ограничения CHECK, необходимые для контроля вводимой информации об объеме водоема и диаметре сети гидранта. Помимо декларативной целостности, была реализована процедурная целостность, которая представлена триггерами. Было реализовано 3 триггера: 1)триггер, контролирующий, чтобы не было возможности изменять данные о неисправности, если уже об этой неисправности было направлено письмо в обслуживающую организацию 2) триггер, контролирующий, чтобы внесенная дата отправки письма была не раньше, чем дата проверки 3) триггер, контролирующий, чтобы дата следующей проверки была больше, чем дата проверки и время, отведенное на ремонт. На основе сформированных в курсовом проекте по «УД» запросов были реализованы хранимые процедуры и функции, которые обеспечивают управление базой данных, а также предоставление пользователям всех необходимых выходных форм. Были реализованы все необходимые процедуры добавления, обновления и удаления данных. Эти процедуры созданы для всех без исключения таблиц. Были реализованы триггеры (TrDefect – триггер, контролирующий, чтобы не было возможности изменять данные о неисправности, если уже об этой неисправности было направлено письмо в обслуживающую организацию). Для обеспечения безопасности и надежности хранилища данных были выделены две основные роли Начальник караула (ROLE NachKar) и Начальник части (ROLE Nach) и в них были включены основные пользователи системы, такие как Начальник караула1 (NachKar1), Начальник караула2 (NachKar2), Начальник караула3 (NachKar3), Начальник караула4 (NachKar4), Начальник (Nach1) и Заместитель начальника (ZamNach1), и им были предоставлены только необходимые им права на работу с данными хранилища. В рамках курсового проекта были протестированы все процедуры ввода, удаления и изменения данных, а так же процедуры создания отчетов. Тестирование БД позволило установить корректность физической модели базы данных, всех процедур и функций, реализованных для данного курсового проекта. Таким образом, в результате выполнения курсового проекта было создано хранилище данных для информационной системы «Источники наружного противопожарного водоснабжения»необходимое для ее реализации.
Библиографический список
1. Виейра Роберт. Программирование баз данных Microsoft SQL Server 2005 для профессионалов.: Пер. с англ. – М.: ООО «И.Д.Вильямс», 2008. – 1072 с.: ил. – Парал.тит.англ.; 2. К. Дж. Дейт. Введение в системы баз данных.: Пер. с англ. М.: Изд. Вильямс, 2006. - 1328 с.: ил. – Парал. тит. англ.; 3. Коннолли Томас, Бегг Каролин. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 3-е изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2003. – 1440 с.: ил. – Парал. тит. англ.; 4. Николаева Н.А. Язык структурированных запросов. Лабораторные работы: учебное пособие / Н.А. Николаева, Т.Ю. Калинина. – Ухта: УГТУ, 2006. – 124 с. ил.
Воспользуйтесь поиском по сайту: ©2015 - 2024 megalektsii.ru Все авторские права принадлежат авторам лекционных материалов. Обратная связь с нами...
|