Унифицированный язык работы с БД SQL. 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Унифицированный язык работы с БД SQL.



В 1970 году Э. Подд написал статью «реляционная модель для больших банков». В исследовательской версии СУБД появился язык SEQEL.

В 1979 году появилась первая коммерческая СУБД Oracle.

В 1982 году появляется продукт DB2. Известно 3 версии стандартов языка: 89, 92 и 99 года. В настоящее время самым признанным является стандарт 92 года, и все реляционно полные сервера стараются поддерживать его. В 1986 году SYBASE появился реляционно полный сервер, в котором предложена бизнес-логика. У Microsoft полновесный сервер появился в 1998 году.

В 1992 году Microsoft предложена ODBC – унификация доступа к данным БД.

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

  1. определение схемы БД
    1. CREATE TABLE <имя таблицы> ({<имя поля><тип> (<размер>) [NOT NULL][UNIQUE][DEFAULT <опция>][CHECK <УСЛОВИЕ>]}*[<определение ограничения таблицы>]);
    2. <тип>:: = CHAR (n)/VARCHAR (n)/NUMERIC (n,m)/DECIMAL (n,m)/REAL;
    3. <определение ограничений таблицы>:: = PRYMARY KEY (<список полей>), [UNIQUE <список полей>)][{[CONSTRAINT <имя ограничения>] FOREIGN KEY (<список полей>) REFERENCES <имя таблицы> [(<список полей>)][ON DELETE <опция>][ON UPDATE <опция>]}*], [{CHECK (<условие>)}*];
    4. <опция>:: = RESTRICTED/CASCADE/SETDEFAULT/SETNULL; Определение первичного ключа, определение альтернативных ключей, определение вторичных ключей, при этом осуществляется контроль ссылочной целостности, при удалении первичного ключа, если на него ссылается вторичный. Если задана вторая опция, то происходит каскадное удаление записей вторичного ключа при удалении соответствующего первичного. Третья опция – вторичным ключам присваивается значение по умолчанию, четвертая опция – всем вторичным ключам присваивается NULL. Пример: CREATE TABLE DETAIL (DETAIL_CODE char(3), DETAIL_NAME char (10), DETAIL_WEIGHT integer NOT NULL, MATERIAL_CODE char (3), PRIMARY KEY (DETAIL_CODE), FOREIGH KEY (MATERIAL_CODE) REFERENCES MATERIAL (MATERIAL_CODE) ON DELETE RESTRICTED ON UPDATE RESTRICTED, CHECK (DETAIL_WEIGHT>0 AND DETAIL_WEIGHT<50)); Физическая модель БД может быть изображена в нотации UML в диаграмме классов уровня проектирования. При этом модель получается более богатой, чем в нотации IDEF1X.
  2. вставка записи
    1. однострочная инструкция INSERT INTO <имя_табл> [(список полей)] VALUES (<список значений>); пример: INSERT INTO MATERIAL (MATERIAL_CODE, MATERIAL_NAME) VALUES (‘M2’, ‘Сталь’); Если заполняются все поля, то имена полей не указываются. Вместо констант в списке значений могут присутствовать переменные (:А,:В). Одновременно посредством запроса можно заполнить несколько записей.
    2. Многострочная инструкция INSERT INTO <имя табл> [<список полей>] <запрос>; пример: INSERT INTO MATERIAL SELECT MATERIAL_CODE, MATERIAL_NAME FROM MATERIAL_NEW WHERE (MATERIAL_CODE = ‘M10’ OR MATERIAL_CODE = ‘M11’);
  3. обновление записей UPDATE <имя табл> SET <список вида <имя поля>=<выражение>> [WHERE <условие>]; пример: UPDATE SUPPLIER SET SUPPLIER_CITY =’Ковров’ WHERE SUPPLIER_CODE=’S4’;
  4. удаление записей DELETE FROM <имя табл> [WHERE <условие>]; пример: DELETE FROM ORDER WHERE SUPPLIER_CODE =’S2’. Если условие не указано, то удаляется вся таблица. DELETE FROM SUPPLIER WHERE SUPPLIER_CODE IN (SELECT SUPPLIER_CODE FROM ORDER WHERE ORDER_QUANTITY<200) – удаляются поставщики, которые поставляют менее 200 деталей.
  5. удаление таблицы DROP TABLE <имя табл>;
  6. реструктуризация таблицы – в процессе жизненного цикла структура базы может изменяться. ALTER TABLE <имя таблицы> [ADD <определение столбца>]/[ALTER <имя столбца>]/[DROD <имя столбца>]/[ADD <ограничение>]/[DROP <имя ограничения>]; примеры: ALTER TABLE DETAIL ADD PRICE REAL NOT NULL DEFAULT 0; ALTER TABLE ORDER DROP ORDER_DATE; ALTER TABLE SUPPLIER ADD CONSTRAINT REGION FOR EIGH KEY (CITY_ID) REFERENCES CITY (CITY_ID);
  7. выборка информации из таблиц SELECT [ALL/DIS TINCT][*/{<имя поля> [AS <новое имя>]}*] FROM {имя табл}* [WHERE <условие>][GROUP BY>][HAVING <условие> [ORDER BY <список полей>[DESC]]; Эта функция определяет структуру записи, которая получается в результате, определяет список таблиц, участвующих в выборке, условие выборки, обеспечивает группировку записей по совпадающим значениям заданного поля, используется в сочетании с предыдущей опцией, чтобы выбрать группы по заданному условию (HAVING аналогична WHERE), последняя опция задает сортировку записей в результирующей отношении. В опции select возможно использование математических функций и выражений (MAX, MIN, COUNT, AVG, SUM). Для подведения промежуточных итогов применение математических функций сопровождается предварительной группировкой по заданному условию. Для подведения итогов по всей таблице группировка не нужна. Примеры: каков средний объем заказа: SELECT AVG (ORDER_QUANTITY) AS ‘AVG_QUANT’ FROM ORDER (ответ – 250); получить сумму поставки каждой детали: SELECT O.DETAIL_CODE, SUM (O.ORDER_QUANTITY) AS SUM_QUANT FROM ORDER o GROUP BY o.DETAIL_CODE (ответ – D1 – 800, D2 – 1100, D3 – 400, D4 – 200); получить количество поставок каждой детали: SELECT O.DETAIL_CODE, COUNT (O.ORDER_ID) AS ‘SUM_ID’ FROM ORDER o GROUP BY o.DETAIL_CODE (ответ – D1 – 4, D2 – 4, D3 – 1, D4 – 1); получить имена поставщиков, поставляющих деталь D2: SELECT DISTINCT s.SUPPLIER_NAME FROM SUPPLIER s, ORDER o S INNER JOIN o ON S.SUPPLIER_CODE = O.SUPPLIER_CODE WHERE o.DETAIL_CODE = ‘D2’ (ответ – Иванов, Петров, Сидоров). Примечание: имена поставщиков находятся в таблице supplier, а информация об их поставках – в таблице order, для выборки осуществляется внутреннее соединение таблиц по равенству первичного и вторичного ключа, в результирующей таблице осуществляется выборка деталей, у которых код = D2. получить имена деталей, имеющих более 3 поставок: SELECT d.DETAIL_NAME, COUNT (*) AS ‘COUNT_ORDER’ FROM DETAIL d, ORDER o d INNER JOIN o ON d.DETAIL_CODE = o.DETAIL_CODE GROUP BY DETAIL_NAME HAVING COUNT (*)>3. Примечание: имена деталей находятся в таблице detail, а информация о поставках – order, выполняем внутреннее соединение этих таблиц, в результирующем отношении делаем группировку записей по полю detail_name, определяем количество записей в каждой группе и выбираем группы, в которых больше трех записей, в этих группах выбираем имя детали и формируется результат (ответ: болт – 4, винт – 4). Смотри методичку по MS SQL Server (37 запросов).
  8. объявление вида над таблицей CREATE VIEW <имя вида> [<список полей>] AS <SQL-запрос>. Вид применяется в 2 аспектах: для ограничения доступа к таблице, например, налоговая инспекция района может видеть только юридических лиц, относящихся к данному району; программисткий прием работы с большими справочниками для создания удобного интерфейса, например, классификатор территорий ОКАТО можно урезать до уровня муниципальных районов и г.о. Пример: CREATE VIEW BIG_DETAIL AS SELECT * FROM DETAIL d WHERE d.DETAIL_WEIGHT>10. Вид – это виртуальная таблица (запрос), которая физически не хранится, а на лету создается во время обращения к нему. работа с видом аналогична работе с простой таблицей. SELECT d.DETAIL_NAME, DETAIL_WEIGHT FROM BIG_DETAIL d WHERE d.DETAIL_NAME = ‘БОЛТ’. Виды используются для агрегации информации при организации аналитической обработки (сгруппированные представления). Раз в месяц над таблицей поставки деталей проводится количественный анализ: CREATE VIEW ORDER_G (d.DETAIL_CODE, o.ORDER_QUANTITY) AS SELECT o.DETAIL_CODE, SUM (o.ORDER_QUANTITY) FROM ORDER o GROUP BY DETAIL_CODE. Реально в ORDER G надо было добавить код года и месяца, которые могут быть получены обработкой дат поставки. Другим вариантом организации информации для аналитической обработки данных является группирование отдельной таблицы звездно-образной структуры, в которую с помощью хранимой процедур будут записываться итоги месяца. Ежемесячно посредством хранимой процедуры выполняется обработка информации в таблице поставок и по каждому поставщику определяется количество поставки каждой детали в течение месяца. Эта информация накапливается и является источником аналитической обработки в целях оценки эффективности поставок. Таким образом, можно организовывать виртуальную аналитическую таблицу, а можно реальную звездно-образную структуру. DROP VIEW <имя вида> - удаление вида.
  9. объявление прав доступа – снятие привилегий осуществляется командой REVOKE <список привилегий> ON <имя табл>/<имя вида> FROM [PUBLIC]/[<имя пользователя>] <привилегия>::=SELECT/INSERT/UPDATE/DELETE/ALL. Выдача привилегий – GRANT <список привилегий> ON < имя табл>/<имя вида>. TO [PUBLIC]/[<имя пользователя>]. Пример: REVOKE ALL ON ORDER FROM PUBLIC; GRANT SELECT ON ORDER TO ‘idr’; GRANT DELETE ON DETAIL TO ‘leonid’.
  10. создание индекса. Индекс – структура, хранящаяся в базе, и содержит упорядоченный ключ и номер страницы, на которой хранится логическая запись. CREATE [UNIQUE] INDEX <имя индекса> ON <имя табл> ({<имя поля>[ASC/DESC]}*); пример: CREATE INDEX idx1 ON SUPPLIER (SUPPLIER_NAME); индекс используется для сортировки записей в таблице.
  11. управление транзакциями COMMIT WORK, ROLL BACK WORK. Транзакции играют 2 роли: при восстановлении системы после сбоев – ведется логический журнал изменений, обеспечение параллельной работы нескольких пользователей. Для параллельной работы сервер поддердживает механизм блокировки LOCK TABLE <имя табл> IN SHARE/EXCLUSIVE. КОГДА ТРАНЗАКЦИЯ ИЗВЛЕКАЕТ ИНФОРМАЦИЮ ПРИМЕНЯЕТСЯ НЕЖЕСТКАЯ БЛОКИРОВКА (SHARE), при этом параллельные транзакции могут извлекать но не могут обновлять, когда транзакция обновляет, то применяется жесткая блокировка, при этом другие транзакции не могут обращаться к данным не могут ни извлекать ни обновлять данные, но пользователь может сам управлять для того чтобы не возникало проблем параллельной работы: пропавшее обновление, промежуточные данные, несогласованные данные и строки-призраки. для того чтобы управлять транзакциями поддерживается механизм сериализации транзакций – возможность пользователя работать с базой, как будто других пользователей нет. Команда задания степени изоляции – SET TRANSACTION [READ ONLY][READ WRITE] ISOLATION LEVEL SERIALIZABLE/REPEATABLE READ/READ COMMITED/READ UNCOMMITTED. По умолчанию идет 1 уровень, самый жесткий, когда транзакции выполняются последовательно, второй режим – транзакция не имеет доступа к промежуточным или окончательным результатам других транзакций, выполняющих обновление данных, однако во время транзакций можно увидеть строки, добавляемые другой транзакцией – если в программе не требуют повторять запрос, возвращающий набор записей в течение одной транзакции, то для повышения производительности можно поставить этот уровень. Третий – окончательные результаты могут быть видны, если не требуется повторно извлекать ту же строку в течение транзакции и она не накапливает итоги, то можно применять этот уровень изоляции, при этом промежуточные данные и проблема обновления возникнуть не могут. Четвертый – на выполнение транзакций могут повлиять как окончательные, так и промежуточные результаты других транзакций, применяется в тех приложениях, где допустимо использование грязных данных. Механизм сериализации применяется в оперативных приложениях, где важна скорость. Рассмотрим пример: LOCK TABLE ORDER IN EXCLUSIVE DELETE FROM ORDER WHERE SUPPLIER_CODE = ‘S2’; INSERT INTO ORDER VALUE S (‘D1’, ‘S22’, 600 ’01.07.04’); IF <ошибка> THEN GO TO M1 COMMIT WORK; GO TO M2; M1: ROLLBACK WORK; M2: RETURN.

Хранимые процедуры.

Современные сервера БД наряду с организацией ведения базы поддерживают бизнес-логику в теле сервера, которая позволяет поддерживать целостность БД, расширяя возможности модели, организация обработки информации, организуют клиентский интерфейс. Таким образом, классическую ИС можно построить на функциональности сервера БД, привлекая ЯВУ для организации интерфейса. Бизнес-логика организуется посредством хранимых процедур и триггеров. Разработан универсальный язык процедур: SPL – это обычный структурный язык, в котором поддерживаются условные операторы, циклы, блоки, именованные переменные. К сожалению, каждый сервер БД поддерживает свой диалект языка и процедуры, зашитые в один сервер, не будут работать в другом сервере. Считается, что развитую бизнес-логику приложения целесообразно хранить отдельно на ЯВУ для обеспечения конвертации.

Описание процедуры: CREATE PROCEDURE <имя процедуры> (<список формальных параметров>). Вызов процедуры – EXECUTE <имя процедуры> (<список фактических параметров>). Приведем пример работы с хранимой процедурой в MS SQL: CREATE PROCEDURE <имя> [{@ <имя параметра><тип>[=значение по умолчанию][OUTPUT]}*] AS <SQL-выражение>

EXEC[UTE] <имя> [{[<имя входных параметров>=]<значение входного параметра>}*].

Процедура, возвращающая список поставок за определенный интервал времени:

PROCEDURE sp_date_supp @ start DATETIME @ end DATETIME AS SELECT s.SUPPLIER_NAME, d.DETAIL_NAME, o.ORDER_QUANTITY FROM SUPPLIER s INNER JOIN ORDER o ON s.SUPPLIER_CODE = o.SUPPLIER_CODE INNER JOIN DETAIL d ON o.DETAIL_CODE = d.DETAIL_CODE WHERE o.ORDER_DATE BETWEEN @start AND @end GO. Обращение к этой процедуре: EXECUTE sp_date_supp ’01.01.2004’,’31.01.2004’ ИЛИ EXECUTE sp_date_supp @start = ’01.01.2004’, @end = ’31.01.2004’.

Результат:

SUPPLIER_NAME DETAIL_NAME ORDER_QUANTITY
Иванов Болт  
Иванов Винт  
Петров Болт  

Процедуры хранятся в БД наряду с таблицами, индексами и для описания проектов они показываются на диаграмме пакетов.

Триггеры – это особые хранимые процедуры, которые вызываются в ответ на оптуализацию содержимого БД. В отличие от хранимой процедуры каждый триггер связывается с определенной таблицей БД и СУБД его выполняет, когда данные в соответствующей таблице изменяются (реакция на команды INSERT, DELETE, UPDATE). Использование: контроль изменений – триггер может отслеживать и отменять определенные изменения, не разрешенные в БД; каскадная операция – может отслеживать определенные операции и автоматически вносить собственные изменения в другие таблицы; поддержание целостности базы – может поддерживать сложные связи между данными, расширяя возможности реляционной модели; вызов хранимых процедур (процедуры могут вызываться самостоятельно без триггеров). Первые три использования реализуются процедурами, а триггер их запускает.

Хранимая процедура Триггер
Является самостоятельными объектами БД Привязываются к таблице, виду
Явно вызывается на выполнение командой EXECUTE Реагируют на события, связанные с таблицей-владельцем
Могут входные/выходные параметры Не имеют
Могут выполняться в отдельной транзакции Выполняются в той же транзакции, в которой осуществляется изменение таблицы-владельца

MS SQL Server

CREATE TRIGGER <имя триггера> ON <имя таблицы> [BE] FOR[E]/AFTER/INSTEAD OF <триггерное событие> AS <SQL-выражение>.

Триггерное событие::= INSERT/DELETE/UPDATE. Рассмотрим пример триггера на поддержание актуального количества деталей на складе при осуществлении поставок:

CREATE TRIGGER tr_order ON ORDER FOR INSERT AS UPDATE DETAIL SET d.DETAIL_QUANTITY = d.DETAIL_QUANTITY+i.ORDER_QUANTITY FROM DETAIL d INNER JOIN INSERTED i ON d.DETAIL_CODE = i.DETAIL_CODE. Примечание: для примера в таблицу DETAIL ввели поле «количество», во время вставки в таблицу ORDER новой поставки (триггерное событие) осуществляется пересчет в таблице DETAIL количества (к существующему количеству добавляется новый объем поставки), MS SQL поддерживаются 2 рабочие таблицы: в одной из них хранятся копии всех вставляемых записей (INSERTED), а во второй хранятся копии удаляемых (DELETED).

Встроенный SQL.

SQL-конструкции встраиваются в исходный текст программы на ЯПВУ. Базовая разновидность встроенного SQL называется статическим SQL, усовершенствованный вариант, позволяющий формировать конструкции SQL прямо в программе, называется динамическим SQL. Каждый сервер поддерживает интерфейс с определенными ЯВУ, в котором можно поддерживать EXEC SQL. При этом в пользовательском программе интерактивно запрашиваются значения переменных, которые передаются в SQL-команды, они выполняются с БД и затем просматриваются результаты. Специальные программы (предкомпиляторы) преобразуют исходный текст программы на ЯПВУ в вызов соответствующих функций СУБД. Для обработки результата запроса предусмотрена работа с курсором. Курсор – это вид указателя, который может быть использован для перемещения по набору строк отношения, являющегося результатом выборки информации из БД. При этом используется команда объявления курсора DECLARE <имя курсора> CURSOR FOR <табличное выражение> [ORDER BY <список полей>] и команда чтения текущей строки курсора FETCH [NEXT/LAST/CURRENT/PREVIOUS] <имя курсора> INTO <список переменных основной программы>.

<объявление переменных>

EXEC SQL CONNECT <имя базы>

EXEC SQL DECLARE X CURSOR FOR SELECT s.SUPPLIER_CODE, s.SUPPLIER_NAME, s.SUPPLIER_CITY FROM SUPPLIER S WHERE s.SUPPLIER_CITY=:Y; EXEC SQL OPEN X; BEGIN <перебор строк выборки> EXEC SQL FETCH x INTO:S#,:Sname,:Scity; <обработка данных> END; EXEC SQL CLOSE X.

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

PREPFRE <идентификатор> FROM <базовая переменная> - формирует указания серверу в виде синтезированной текстовой строки SQL-предложения.

EXECUTE <идентификатор> USING <базовая переменная> - выполняет предложение.

15. прикладной интерфейс СУБД – в конце 80-х годов в сервере SyBase применен новый подход организации интерфейса из языка ВУ в СУБД. Типичный набор функций: функция подключения к СУБД и конкретной БД, передача инструкций в программе, контроль инструкций и ошибок, выполнения запроса и передача результатов, функция отключения. В связи с развитием объектной парадигмы появились стандартные компоненты для работы с БД, в которые зашиты функции, в частности среда Delphi поставляет компонент IBX, которая позволяет работать с СУБД interBase. Корпорация Microsoft в 1992 году разработала универсальную библиотеку – набор стандартных функций для серверов. При этом поддерживается библиотека драйверов, позволяющая переформулировать стандартную функцию в функцию сервера. Фирма Borland разработала свою библиотеку BDF. Но для ряда СУБД нет драйверов. Для работы с БД на конкретном клиентском месте должна быть установлена система BDE, DBC, в которых нужно прописать источник. Кроме того, в библиотеке драйверов надо посмотреть, есть ли соответствующий драйвер. Для тонкого клиента вся обработка идет на сервере.

Тенденции развития СУБД.

В настоящее время широкое распространение получили реляционные сервера БД. Нормализованность отношений мешает хранить сложно структурированные объекты. Поэтому тенденциями развития является синтез реляционной модели и иерархической. Направления: создание ОО СУБД и ОР СУБД, унификация организации слабоструктурированной информации в виде XML-документов с организацией их хранения. В настоящее время большинство реляционно-полных серверов включили возможность хранения XML-документов. Первое направление: ОО СУБД позволяли описывать абстрактные типы данных. Таким образом, получилась микро иерархия исходный-порожденный «таблица в таблице», связь которой осуществляется посредством указателя и соединение при выборке информации не требуется. Кроме того, появилась возможность работы с большими объектами – блобами для хранения видео, документов и веб-страниц. Кроме того, появились чисто ОО СУБД, которые позволяют во внешней памяти хранить объекты, эффективно манипулировать ими и поддерживать целостность, управление транзакциями и т.д. Но унификация не была достигнута и коммерческих СУБД не появилось.

XML СУБД – с появлением языка структурированной разметки документов открылось новое, альтернативное реляционному направление хранения информации. Любую информацию (табличную, иерархическую) можно загнать в XML-структуру.

Документ на XML имеет иерархическую структуру (узлы, атрибуты и значения атрибутов). Последние версии реляционных серверов обеспечивает хранение и навигацию по таким документам. При этом достигнута унификация языка. Пример:

ORDER [number=”896702”].

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

Итоги раздела СУБД.

Знания:

  1. принципы построения и функционирования СУБД, тенденции развития, современные подходы к интеграции данных
  2. описание методов доступа, управление данными во внешней памяти, характеристика основных функций, интерпретация основных функций языка SQL
  3. обоснование выбора конкретной СУБД

Умения:

  1. поддержание целостности БД на уровне проектирования и реализации

Навыки:

  1. использование средств СУБД для организации БД различного назначения.
  2. создание и загрузка БД
  3. реализация бизнес-логики приложения (владение аппаратом триггеров и присоединенных процедур для поддержания целостности БД и организации её ведения)
  4. владение прикладным интерфейсом СУБД на языке высокого уровня.

 

Автоматизированные ИС.

Сетевая обработка данных.

Виды автоматизированных ИС.

Методология анализа и проектирования ИС.

 

Сетевая обработка данных.

Термин применяется для описания систем с несколькими процессорами, территориально удаленными друг от друга. Имеют место 2 причины посылки транзакции: необходимы данные, которые хранятся на другом компьютере; недостаточна мощность используемой машины. Остановимся на первой причине.

Технология «клиент-сервер».

Организация сетевой обработки данных базируется на этой технологии. При этом выделяются в прикладных ИС функции и данные, которые служат многим. Обслуживающая часть называется сервером. Функции: управление работой оборудования коллективного использования, управление БД (сервер БД), поддержание сервисов Интернет. При этом может быть двухзвенная архитектура, тогда на сервере БД организована вся бизнес-логика приложения, к которой посредством запросов обращается клиентская часть. Более продвинутая – трехзвенная, кроме сервера БД и клиента существует сервер приложений, на котором расположены базовые классы – платформы конкретной ИС. В трехзвенной архитектуре хранятся сущностные экземпляры, соответствующие экземплярам базовых классов. На машинах клиентов происходит оформление заданий на составление отчетов. Эта часть может быть выполнена в 2 вариантах: толстый и тонкий.

 

Классификация ИС по способам распределения данных.

  1. схема с централизованными данными – все данные располагаются централизованно на едином сервере, к которому пользователи обращаются с клиентских мест.
  2. иерархия зависимых данных – данные на машинах нижнего уровня являются подмножеством данных верхнего уровня. На центральной машине осуществляется объединение всего множества данных нижнего уровня.
  3. иерархия независимых данных – структура данных на машинах нижнего уровня отличается от централизованной базы, внизу, как правило, выполняются рутинные операции, на машине верхнего уровня собирается агрегированная информация о деятельности филиалов нижнего уровня.
  4. схема с расщепленными данными – связываются несколько систем. Для большинства транзакций пользователю достаточно данных своего района, но в некоторых случаях могут потребоваться к данным другого района, тогда посылается запрос.
  5. схема с разделенными данными – в каждом узле сети выполняется своя обработка информации, в случае необходимости использования данных других систем посылается либо распределенный запрос, либо используется выгруженная информация. Данная система является основой для современных систем управления организациями.
  6. схема с реплицированными данными – идентичные копии данных хранятся в разных узлах системы. Такая организация имеет место, когда объем обновлений данных не значителен и обосновано тиражирование данных по узлам сети. Организация в каждом узле автономная, но в определенный момент осуществляется репликация и во всех узлах сети оказывается одинаковая.
  7. гетерогенная схема – в отличие от предыдущих схем, основанных на корпоративных сетях, данная схема предполагает работу в глобальной сети, поддерживается система имен серверов и адресации, по которой любой клиент может осуществить доступ к любой информации. Доступ бывает санкционированный и свободный.

Виды автоматизированных ИС.

АИС предназначены для хранения, обработки, поиска, распространения, передачи и представления информации.

Документальные информационно-поисковые системы.

Фактографические информационно-аналитические системы.

Геоинформационные системы.

В реальной практике имеется возможность пересечения систем.

Документальные информационно-поисковые системы.

Большая часть информации существует в виде документов – это средства закрепления различным способом на специальном материале информации о фактах, событиях, явлениях объективной действительности и мыслительной деятельности человека. Документальный поиск – это поиск сведений о документе или самого документа или его копии. Различают датоцентричные и документоцентричные объекты. Датоцентричные характеризуются строгой регулярной структурой, мелкой зернистостью и отличаются отсутствием или малым количеством смешанного содержимого (регистрационные карточки). Документоцентричные используются для восприятия человека, характеризуются менее регулярной структурой, крупнозернистыми данными и содержат мало смешанного содержимого (произведения искусства). Для хранения документоцентричных объектов в современных СУБД поддерживаются блобы. Документальные информационно-поисковые системы прошли 3 стадии развития:

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

Существует 2 класса ИПЯ: в основе ИПЯ классификационного типа лежит организация понятий в виде иерархической древовидной структуры. Примеры: УДК, ГРНТИ. В основе ИПЯ дескрипторного типа лежит алфавитный перечень единиц, выраженных словами или словосочетаниями. В целях повышения эффективности поиска используются синонимы, ассоциативные понятия. Такой словарь называется тезаурус. В ИПС, созданных на основе коммерческих СУБД, индексирование выполняется с помощью справочников. Когда поддерживается двухуровненвая классификация, то применяется категорный справочник. Существуют организации, в которых поддерживаются ИПЯ, в частности РосСтат, ОКАТО, ОКФС, ОКВЭД, ОКСМ, при создании своего справочника надо всегда посмотреть, нет ли готового классификатора и его урезать под конкретное пользование. Чаще всего используется верхушка готового и она развивается для конкретного использования. Существует в налоговой службе классификатор адресов. Существуют отраслевые классификаторы. Поисковый образ документа в идеальном варианте должен полностью проиндексирован. Каждому полю должен соответствовать какой-то классификатор. Например, библиографическая карточка включает поле ключевых слов по УДК.

· В 90-е годы появилась система управления электронными документами. Поиск в них основан на механизме полнотекстового поиска на основе инвертированной матрицы, в которую вносятся все значимые слова из всех документов в алфавитном порядке. С каждым словом связывается указатель на соответствующий документ. Разработана система распознавания образов, которая позволяет сканированные документы хранить с полнотекстовым индексированием всех слов. Для создания ИПС стали применять специализированные программные средства, в которых поддерживаются ОО БД, базовые классы, соответствующие основным шаблонам документов и автоматизированные бизнес-процессы, поддерживающее управление документами. По сути дела EDMS – это платформа, на основе которой поддерживаются соответствующие СУБД. Основные функции систем электронного документооборота: работа с документами, ведение внутренних документов, создание, согласование, утверждение, исполнение и списание дела. Следует заметить, что современные системы управления предприятиями интегрируются с системами документооборота. Исходящие и входящие документы: процедура рассмотрения документов, постановка на контроль, контроль сроков, формирование отчетов по поступлению документов. Коллективная работа с документами, при этом поддерживаются шаблоны маршрутов бизнес-процессов по каждому документу. Выделяется 2 класса систем документооборота: group ware – коллективный доступ, work flow – модель группового взаимодействия с распределением ролей, очередности обращения.

Фактографический поиск – это поиск данных, фактов, извлеченных из документов. Определим фактографические ИС. Они делятся по назначению, масштабу, виду обработки.

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

  1. системы автоматизированного проектирования и технологической подготовки производства (САПР, АСТПП). В БД этих систем хранятся нормативно-технические данные (ГОСТы, справочники, номенклатуры, архивы типовых решений, базы проектной документации и заказных спецификаций)
  2. АСУТП – диспетчеризация процессов. В БД хранится оперативная информация о технологическом процессе в целях управления объектом.
  3. АСУП (системы управления производством) – это системы планирования и управления ресурсами предприятия. С развитием корпоративных сетей, теории менеджмента, а также интеграции данных и аналитической обработки открылась возможность управления предприятием в целом.

По масштабу можно выделить локальные системы, предназначенные для учета по одному или нескольким направлениям (бухучет), финансово-управляющие системы, предназначенные для управления ресурсами непроизводственных компаний (финансовое управление), средне-интегрированные системы предназначены для управления производственным процессом на предприятиях, крупные интегрированные системы ориентированы на корпоративную консолидацию информации, управление сложными финансовыми потоками, глобальное планирование. Данный класс систем применяется в крупных корпорациях, холдингах, их свойства – территориальная распределенность, наличие нескольких ведомственных вертикалей, несколько иерархических уровней управления. С большой концентрацией производства создание крупных ИС становится актуальным. Корпорация – это стабильная, многопрофильная территориально-распределенная структура, обладающая всеми необходимыми системами жизнеобеспечения и функционирующая на принципах децентрализованного управления.

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

На малых предприятиях, в сфере услуг применяются малые и средние ИС. Для управленческих структур (холдингов) используются крупные ИС с использованием автоматизации поддержки принятия решений. Принцип управления, основанный на интеграции данных и их комплексной аналитической обработки, называется контролингом. Контролинг – это мониторинг состояния сложной системы, оценка и поддержка принятия решений, направленных на совершенствование и развитие системы. В основе информационной поддержки принятия решений лежит концепция хранилищ данных корпоративных информационно-аналитических систем. С развитием СППР теория БД получила новое развитие (технология многомерного анализа и интеллектуальный анализ данных).



Поделиться:


Последнее изменение этой страницы: 2017-01-27; просмотров: 396; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 54.198.45.0 (0.064 с.)