Информационные системы
Электронный учебник
Лекция № 12. «Подготовка инсталляционного скрипта для создания БД»
Основной целью настоящей лекции является формирование навыков решения следующей профессиональной задачи проектирования баз данных этапа создания физической модели базы данных, а именно - подготовки инсталляционного скрипта для создания базы данных. Проектировщик базы данных, выполнив задачи предыдущей лекции, фактически выполнил свою основную работу над созданием скрипта для создания базы данных. Если работа по проектированию базы данных закончена, то зачем проектировщику еще что-то делать, кроме того как проанализировать и проверить проделанную работу, отредактировать окончательный вариант скрипта и создать физическую базу данных? Принято считать, что задача создания базы данных, так же как и управление базой данных, является задачей администратора базы данных. Значит, можно задокументировать проделанную работу и передать ее администратору базы данных. Однако процесс проектирования физической модели базы данных не закончен. Из нашего рассмотрения выпали следующие вопросы: · требования по обеспечению потенциальных пользователей к базе данных и ее объектам, так называемые требования безопасности базы данных; · требования к размещению и хранению объектов базы данных на физических носителях в рамках операционной системы, т.е. привязка объектов базы данных файлам операционной системы. Однако одним из главных результатов проектирования базы данных является создание физической базы данных на основе разработанного в процессе проектирования инсталляционного скрипта. Поэтому проектировщик базы данных должен вместе с администратором базы данных рассмотреть вышеуказанные задачи и подготовить такой инсталляционный скрипт для создания базы, а не передавать эту работу администратору базы данных, хотя на практике последнее часто происходит. С другой стороны, проектировщик базы данных в организации зачастую выступает в качестве администратора базы данных. Это тоже одна из важных причин рассмотрения решения этих вопросов в рамках этого курса. Таким образом, задача настоящей лекции состоит из решения четырех крупных подзадач: · создание пользователей, их идентификация и назначение им привилегий; · привязка разработанных объектов реляционной базы данных к параметрам физического хранения базы данных с помощью создания специальных объектов базы данных; · создание инсталляционного скрипта; · документирование базы данных. Средства разграничения доступа в СУБД OracleСовременный уровень развития средств вычислительной техники характеризуется высокой степенью распределенной обработки данных, когда логически единая информационная база данных размещается в сетевой среде. Вычислительные сети характеризуются объединением различных компьютеров на основе программно-аппаратной платформы, асинхронной многопользовательской обработкой и развитыми средствами разграничения доступа. При этом реальная сложность организации управления доступа скрыта от пользователя. Логическое пространство базы данных должно выглядеть для пользователя так, как если бы вся база данных располагалась на его локальном компьютере. При работе с базой данных должна быть обеспечена высокая степень безопасности данных практически без усложнения работы пользователя. Одной из неотъемлемых функций любой промышленной СУБД, в том числе и Oracle, является обеспечение защиты информации на уровне доступа к данным. Для этого в СУБД Oracle используется система избирательного управления доступом. Это означает, что администратор базы данных создает пользователей и управляет их полномочиями на выполнение конкретных операций с конкретными объектами в базе данных. Задача распознавания пользователей и разграничения доступа между различными пользователями базы данных решается как на уровне средств операционной системы, так и на уровне СУБД. Стандартным подходом к решению этой задачи на обоих уровнях является поддержка механизма создания (регистрации) пользователя и назначения ему привилегий. С другой стороны, каждый пользователь, создающий некоторый объект, должен иметь право на управление доступом к этому объекту. Типичное решение состоит в реализации концепции привилегий или прав доступа. Привилегия - это некоторый поддерживаемый СУБД или операционной системой признак, который определяет, может ли конкретный пользователь выполнить конкретную операцию. Для этого администраторы базы данных создают пользователей базы данных и предоставляют им некоторые полномочия по доступу к объектам базы данных. Обеспечение правомерности доступа пользователя реализуется средствами аутентификации системы, простейшим из которых является использование пароля, подтверждающего подлинность пользователя. Для входа в базу данных пользователь должен ввести имя и подтвердить свою подлинность паролем. В СУБД Oracle реализована поддержка принципа безопасности по умолчанию, который состоит в назначении наименьших привилегий. Т.е. пользователь может получить доступ к объекту базы данных или выполнить определенные действия в базе данных, только если ему это явно разрешено. Концепция обеспечения безопасности доступа, принятая в Oracle, предусматривает выполнение следующих действий: · идентификацию и аутентификацию пользователей; · контроль глобальных действий в базе данных, определяющих доступность ее объектов; · контроль доступа к объектам базы данных; · контроль операций, производимых над объектами базы данных. Проектировщик базы данных решает эти задачи, исходя из предположения, что база данных доступна. В терминах СУБД Oracle это означает, что администратор базы данных запустил экземпляр (instance) сервера базы данных. Создание пользователей и назначение им привилегийСоздание пользователейОдной из задач, которая чаще всего решается в процессе эксплуатации базы данных, является создание пользователей базы данных. В контексте баз данных термин "пользователь" имеет два основных значения: · это человек, который входит в базу данных для выполнения работы; · это область схемы приложения, в которой хранятся объекты, используемые этим приложением. На самом деле под созданием пользователя базы данных понимают создание учетной записи пользователя (user account) в словаре данных, с помощью которой пользователь может войти в базу данных для выполнения своей работы. Учетные записи представляют собой способ организации доступа пользователя к базе данных, выдачи разрешений на выполнение требуемых задач, а также отслеживания выполняемых пользователем действий. Такая учетная запись включает имя пользователя базы данных, которое присваивают пользователю в базе данных, пароль, указание которого разрешает доступ к объектам базы данных, уровень полномочий или уровень доступа и еще ряд опциональных параметров. Уровень доступа означает тип операций, которые данный пользователь может выполнять (создавать таблицу, определять пользователей и т.д). Пользователь является объектом базы данных. При создании пользователя базы данных обязательным является указание имени. Остальные параметры могут быть установлены администратором базы данных позже с помощью команды SQL ALTER USER. Создание пользователей называется еще задачей авторизации или аутентификации пользователей. Решение этой задачи возлагается на администраторов базы данных. Проектировщик во время проектирования базы данных, совместно с администратором базы данных, может создать всех потенциальных пользователей. Хорошим тоном проектирования является создание проектировщиком следующих пользователей: разработчиков приложения базы данных и тестировщиков базы данных. Именно эти лица получают спроектированную базу данных в опытную эксплуатацию. Чтобы создать пользователей базы данных, проектировщик должен иметь список лиц, которым будут разрешен доступ к базе данных. Для создания пользователей базы данных или учетной записи пользователя используется команда SQL CREATE USER, неполный синтаксис которой приведен ниже: CREATE USER имя_пользователя IDENTIFIED BY [пароль|EXTERNALLY]; Ключевое слов EXTERNALLY указывает, что должна быть использована аутентификация операционной системы. Для исключения пользователей из базы данных применяется команда DROP USER. В качестве примера создадим пользователей нашей учебной базы данных. Допустим, что у нас есть следующий фрагмент списка лиц, которые в организации будут пользоваться базой данных: ...Иванов А.А. - разработчик приложенияПетров В.В. - разработчик приложенияСидоров С.С. - тестировщик базы данных…Иванов и Петров уже имеют системную аутентификацию, и администратор базы данных решил, что учетная запись для их доступа к базе данных будет такой же. Их имена для входа в систему - Ivan и Peter, соответственно. Сидоров - это новый сотрудник, который будет принят на работу через 1,5 месяца специально для тестирования базы данных. Совместно с администратором базы данных было решено, что его имя для входа в базу данных будет Sidorov, а пароль - alsy_. Тогда проектировщик базы данных может включить в свой скрипт следующие команды: CREATE USER Ivan IDENTIFIED BY EXTERNALLY;CREATE USER Peter IDENTIFIED BY EXTERNALLY;CREATE USER Sidorov IDENTIFIED BY 'alsy_';Назначение привилегийС каждой учетной записью связана так называемая область привилегий, которая остается пустой при создании ее с помощью команды CREATE USER. Привилегия - это поддерживаемый системой признак, который определяет, может ли конкретный пользователь выполнить конкретную операцию, т.е. разрешение на выполнение в системе определенного действия. Таким образом, имеется несколько типов привилегий, соответствующих нескольким типам операций, и, следовательно, предполагается, что пользователь в системе будет обладать определенным набором привилегий. Для понимания действия этого механизма определения привилегий важно понятие владельца таблицы. Будучи пользователем, определенным в базе данных, вы являетесь владельцем любой созданной вами таблицы. Вы можете разрешить доступ к вашей таблице другим пользователям, определяя им привилегии прав доступа к своим таблицам. Множество базовых привилегий определено стандартом ANSI SLQ, но, как правило, в конкретных СУБД поддерживаются дополнительные типы привилегий. Например, в СУБД Oracle их около сотни. Все привилегии могут быть разделены на два класса: системные привилегии и привилегии прав доступа к объектам базы данных. Системная привилегия - это привилегия, которая дает пользователю право на выполнение какой-либо операции в масштабе базы данных. Например, привилегия SELECT ANY TABLE дает пользователю право выполнять выборку из любой таблицы базы данных. Привилегия прав доступа к объекту - это разрешение пользователю на выполнение определенной операции над определенным объектом базы данных. Например, пользователю может быть предоставлена привилегия SELECT на выполнение выборки из конкретной таблицы. Для предоставления привилегий или, как еще говорят, авторизации доступа в SQL предусмотрена команда GRANT - ее может выполнить обычно только системный администратор, который предопределен в системе как SYSADM (наивысший уровень доступа, при котором возможно выполнение всех операций над БД). В СУБД Oracle такой пользователь должен обладать привилегией GRANT ANY RPIVILEGE. Команда GRANT для определения системных привилегий имеет следующий синтаксис: GRANT системная_привилегия [ { , системная_привиления } ѕ] TO { пользователь | PUBLIC } [{, пользователь} ѕ ] [WITH ADMIN OPTION]В СУБД Oracle привилегии прав доступа к объекту могут быть предоставлены двум объектам системы: пользователям и ролям. Роль представляет собой поименованный набор привилегий. Предложения команды GRANT в данном случае управляют разграничением доступа к объектам базы данных: таблицам, представлениям, процедурам и т.д. Синтаксис команды имеет вид GRANT {привилегия_доступа_к_объекту | ALL PRIVILEGES} [ имя_столбца [{ , имя_столбца } ѕ] ][{ , привилегия_доступа_к_объекту } ѕ ]ON [имя_схемы.]имя_объектаTO { пользователь | PUBLIC } [WITH GRANT OPTION]Список привилегий доступа показан в таблице 13.1 ниже.
Таким образом, команда GRANT состоит из трех предложений. GRANT - для присвоения привилегий, ON - для определения таблицы и TO - для определения пользователей. Допустим, что вы хотите дать право на доступ к таблице EMPLOYEE пользователю PETROV. Тогда следует выполнить команду GRANT SELECTON EMPLOYEETO PETROV;Вы можете также дать привилегии на выполнение обновления, добавления, удаления данных в таблицах и виртуальных таблицах (UPDATE, INSERT, DELETE), а также для изменения структуры таблицы (ALTER) и право на использование индекса (INDEX). При определении привилегии на обновление вы можете указать список колонок, обновлять которые вы разрешаете другим пользователям таблицы. Можно разрешить доступ на выборку таблицы и группе пользователей. Допустим, что вы желаете разрешить доступ к таблице EMPLOYEE всем пользователям, но исключить при этом доступ к колонкам SAL, COMM и FINE. Хорошим решением в данном случае будет создать виртуальную таблицу и разрешить доступ к ней всем пользователям: CREATE VIEW EMP AS SELECT EMPNO,ENAME,JOB,AGE,HIREDATE,DEPNOFROM EMPLOYEE; Теперь вы можете разрешить доступ всем пользователям к созданной виртуальной таблице, используя ключевое слово PUBLIC. GRANT SELECTON EMPTO PUBLIC;Вы можете организовать и более сложные механизмы защиты данных. Например, вы можете, используя виртуальные таблицы, ограничить доступ к данным таблицы EMPLOYEE руководителям подразделений таким образом, что они не будут иметь доступа к информации по другим подразделениям. При этом удобно воспользоваться ключевым словом USER для идентификации пользователя: CREATE VIEW EMPDEPT AS SELECT * FROM EMPLOYEE WHERE DEPNO IN ( SELECT DEPNO FROM EMPLOYEE WHERE ENAME = USER );Теперь вы можете определить привилегии доступа для всех руководителей организации: GRANT SELECT,UPDATEON EMPDEPTTO IVLEVДля отмены привилегий доступа в SQL предназначена команда REVOKE. Эта команда, так же как и команда GRANT, включает предложения ON и TO. Предложение REVOKE определяет отменяемую привилегию. Чтобы отменить привилегии на добавление строк в таблицу пользователю PETROV, нужно выполнить команду REVOKE INSERTON DEPARTAMENTTO PETROV;Оценка размера базы данныхБазы данных существуют и функционируют в конкретной программно-аппаратной среде. Компьютер представляет собой аппаратную среду, состоящую из множества различных компонент - центрального процессора, оперативной и внешней памяти и т.д. Для обеспечения взаимодействия аппаратных компонент служит операционная система. Операционные системы варьируются в зависимости от используемой аппаратуры. Операционная система представляет собой промежуточный уровень между компьютерной аппаратурой и программами. СУБД - это программа для поддержки базы данных. База данных хранится в файлах операционной системы, которые располагаются во внешней памяти компьютера, на жестких дисках. Файлы операционной системы обычно располагаются внутри логически поименованных областей жесткого диска, которые называются каталогами. Приложения базы данных взаимодействуют с данными в ней через цепочку программных взаимодействий: Размер базы данных во многих практических ситуациях является критическим параметром ее эксплуатации. Проектировщик БД должен уметь оценивать как размер БД, так и возможный ее рост во времени. Отправной точкой решения задачи оценки размера БД является вычисление размера каждой таблицы БД. Чтобы это сделать, необходимо вычислить размер каждой колонки в таблице и на основании этих данных оценить размер самой таблицы. Далее следует оценить размер всех индексов, представлений и других объектов. Поскольку ОС распределяет память под файлы в страницах, то при вычислении размера базы данных необходимо оценить число страниц, которое она занимает. Для ОС типа Windows размер страницы составляет 1024 байта. Формулы для оценки размера БДС целью упрощения вычислений размера базы данных, в настоящем разделе мы будем проводить вычисления на примере СУБД SQLBASE. Размер базы данных может быть оценен по формуле Вычисление размера колонки. Вычисление размера колонки зависит от типа домена колонки. Размер колонки или столбца таблицы - это число символов, которое отводится СУБД для хранения колонки заданного типа. Как правило, в определении таблицы задаются максимальные размеры полей указанного типа для данной предметной области. Например, предполагается, что колонка адреса компании не будет занимать более 50 символов. С другой стороны, на практике, на реальных данных средний размер колонки адреса компании может составлять 30 символов. Расчет размера базы данных целесообразно проводить исходя из среднего размера колонок таблиц. Типичные размеры колонок заданного типа приведены в таблице 13.2 ниже.
Размер строки таблицы определяется как сумма размеров всех ее колонок по формуле Data _ Length = Вычисление размера таблицы. Основываясь на значении Data_Length можно оценить размер обычной таблицы или хэш-таблицы. Формулы для выполнения такой оценки приведены в таблицах 13.3 и 13.4. Различие в методике расчета размера хэш-таблицы заключается в необходимости учитывать параметр загрузки хэш-таблицы (packing_density), который устанавливается при определении такой таблицы.
Вычисление размера индекса. Для каждого созданного B-Tree индекса его размер оценивается следующим образом: вычисляется размер индексного ключа, оценивается число строк в таблице, затем оценивается число страниц, которое занимает индекс. Расчет выполняется по формулам, приведенным в таблице 13.5.
Вычисление размера заголовка представления. Для каждого представления существует фиксированная часть заголовка и переменная часть заголовка, которая зависит от его сложности. Формулы для расчета размера заголовка представления приведены в таблице 13.6.
Оценка размера фиксированной системной области. Размер системной области в страницах (Total_Fixed_Overhead_Pages) для базы данных СУБД SQLBASE оценивается по следующей формуле: Total_Fixed_Overhead_Pages = 12*число_таблиц + 2*число_хэш_индексов + 602112/1024
Создание табличных пространствПроектировщик базы данных работает с логическими объектами - табличными пространствами, таблицами, представлениями, индексами и т.д., так называемыми логическими файлами СУБД Oracle. Информация о содержимом логических файлов хранится в словаре данных. Одним из самых трудных для понимания и объяснения объектов реляционной базы данных Oracle является табличное пространство (tablespace). Табличным пространством в Oracle называется логическая область хранения данных, размер которой ограничен размером используемого жесткого диска. Физические файлы создаются на уровне табличного пространства. Выделением места для табличных пространств и способом их совместного использования управляют администраторы базы данных. Поэтому проектировщики базы данных должны при использовании табличных пространств работать в тесном сотрудничестве с ними. Табличные пространства можно создавать, менять и удалять. Для создания табличных пространств в СУБД Oracle предусмотрена команда SQL CREATE TABLESPACE, параметры которой приведены в таблице 13.8.
В качестве примера создадим табличное пространство, не используя никаких параметров, как показано ниже. CREATE TABLESPACE my_tsDATAFILE 'c:\ora9i\oradata\orcr\myfile01.dbf'SIZE 2M;Ключевое слово TABLESPACE задает имя табличной области (my_ts), ключевое слово DATAFILE задает спецификацию файла операционной системы ('c:\ora9i\oradata\orcr\myfile01.dbf'), в котором будут размещаться данные создаваемой табличной области, ключевое слово SIZE задает размер табличного пространства в мегабайтах. Остальные значения параметров принимаются по умолчанию. В частности, поскольку значение по умолчанию для параметра AUTOEXTEND есть ON (см. таблицу 13.8), то разрешено автоматическое расширение пространства, выделенного для данного табличного пространства. По умолчанию созданное табличное пространство переходит в оперативный режим (ONLINE) и является постоянным табличным пространством (PERMANENT). Для изменения параметров табличного пространства используется команда ALTER TABLESPACE, а для удаления - команда DROP. Чтобы разместить объект базы данных в определенном табличном пространстве, необходимо явно указать это табличное пространство в командах SQL. Например, команда CREATE TABLE CUSTOMER(CUSTOMER_ID CHAR(5) NOT NULL,CUSTOMER_NAME VARCHAR(25),CUSTOMER_ADDR VARCHAR(50),CUSTOMER_RATING CHAR(10))TABLESPASE my_st,PCTFREE 15;размещает таблицу CUSTOMER и табличном пространстве my_st. Проверка физической модели реляционной базы данныхПеред созданием физической базы данных проектировщик базы данных должен проверить созданную им модель физической структуры базы данных на полноту и корректность. Полнота в данном случае означает, что следует убедиться в том, что: · все сущности логической модели базы данных нашли свое отражение в объектах физической модели; · в соответствии анализом транзакций системы и требованиями производительности приняты соответствующие проектные решения, которые получили свое отражение в объектах физической структуры; · определен круг пользователей системы, их роли, и созданы соответствующие объекты базы данных для поддержки; · оценен потенциальный размер базы данных и ее возможный рост, а полученные оценки нашли свое отражение в объектах базы данных, связанных с управлением файловым пространством базы данных. Корректность означает, что в процессе денормализации логической модели базы данных при ее преобразовании в физическую с учетом требований по производительности не была потеряна реляционность отношений базы данных на физическом уровне модели. Заметим, что наших лекциях не нашли своего отражения ряд вопросов проектирования базы данных, а именно - связанных с выбором программно-аппаратной архитектуры (например, трехзвенная архитектура "клиент-сервер"), настройкой производительности, работой с физическим пространством базы данных и т.д. Как правило, эти вопросы, по большей части связанные с конкретной реализацией базы данных, решаются непосредственно администраторами баз данных, а проектировщики редко привлекаются к решению, в том числе и этих задач, на стадии управления изменениями в процессе начального, тестового, опытного этапов эксплуатации базы данных. В наших лекциях мы акцентировали внимание на тех задачах проектировщика базы данных, которые в основном не зависят от учета конкретной программно-аппаратной среды функционирования базы данных. На этом этапе проектирования базы данных важно завершить документирование модели. Все объекты и их элементы физической модели должны быть описаны и прокомментированы. В результате должен быть создан подробный отчет по физической модели. В этом случае неоценимую поддержку в работе проектировщика оказывают CASE-средства поддержки процесса проектирования, например, хорошо известный Erwin или PowerDesigner, которые позволяют в автоматическом режиме создавать такие отчеты. После разработки или генерирования скрипта создания физической базы данных, загрузки в нее реальных или тестовых данных, проектировщик базы данных обязан с помощью средств СУБД получить информацию о параметрах объектов базы данных, чтобы сопоставить ее с предполагаемыми параметрами, и при необходимости выполнить их корректировку (не забывая отразить эти действия в отчете). Основные параметры объектов, которые следовало бы проконтролировать после создания физической базы данных, приведены в таблицах 13.9.- 13.14. Это касается основных объектов - таблиц, индексов, представлений, синонимов, ролей и пользователей.
Подготовка скрипта создания физической базы данныхРассмотрим решение этой задачи на учебном примере, который мы использовали в предыдущих лекциях. 1. Создание реляционных таблиц. Сначала проектировщик базы данных собирает команды создания таблиц базы данных, которые в нашем случае могут иметь вид CREATE TABLE DEPARTAMENT ( DEPNO integer NOT NULL, DNAME char(20), LOC char(20), MANAGER char(20), PHONE char(15),PRIMARY KEY (DEPNO) определение первичного ключа ); CREATE TABLE EMPLOYEE( EMPNO integer NOT NULL, ENAME char(25), LNAME char(10), DEPNO int, SSECNO char(10), JOB char(25), AGE date, HIREDATE date NOT NULL WITH DEFAULT, SAL dec(9,2), COMM dec(9,2), FINE dec(9,2), PRIMARY KEY (EMPNO)); CREATE TABLE PROJECT (PROJNO char(8) NOT NULL,PNAME char(25),BUDGET dec(9,2),PRIMARY KEY (PROJNO));CREATE TABLE EMP_PRJ( EMPNO integer NOT NULL, PROJNO char(8) NOT NULL, WORKS number, PRIMARY KEY (EMPNO, PROJNO), FOREING KEY (EMPNO) REFERENCES EMPLOYEE, FOREING KEY (PROJNO) REFERENCES PROJECT);2. Создание индексов. На втором шаге проектировщик базы данных собирает команды создания индексов, которые он решил построить. В нашем случае проектировщик мог принять решения не строить дополнительных индексов, а СУБД Oracle индекс первичного ключа строится автоматически. Поэтому этот раздел скрипта у нас пуст. 3. Создание представлений. Проектировщик базы данных принял решение создать внешнюю схему для пользователей базы данных и разработал следующий фрагмент скрипта: CREATE VIEW DEPARTAMENT_VAS SELECT DEPNO, DNAME, LOC, MANAGER, PHONEFROM DEPARTAMENT; CREATE VIEW EMPLOYEE_VAS SELECT EMPNO, ENAME, LNAME, DEPNO, SSECNO, JOB, AGE, HIREDATE, SAL, COMM, FINEFROM EMPLOYEE;CREATE VIEW PROJECT_V AS SELECT PROJNO, PNAME, BUDGETFROM PROJECT;Кроме этого, проектировщик решил добавить в физическую модель базы данных еще четыре представления: CREATE VIEW PERSPROJAS SELECT ENAME, JOB, PNAMEFROM EMPLOYEE, PROJECT, EMPL_PROJ WHERE EMPLOYEE.EMPNO= EMPL_PROJ.EMPNO AND EMPL_PROJ.PROJNO=PROJECT.PROJNO; CREATE VIEW EMPLIST AS SELECT DEPNO, EMPNO, ENAME, JOB FROM EMPLOYEE GROOP BY DEPNO, EMPNO, ENAME, JOB; CREATE VIEW PERSPROJAS SELECT ENAME, JOB, PNAMEFROM EMPLOYEE, PROJECTWHERE EMPLOYEE.PROJNO=PROJECT.PROJNO; CREATE VIEW CURPROJ ASSELECT *FROM PROJECTWHERE START_DATE < SYSDATE WITH CHECK OPTION;4. Создание синонимов. Проектировщик базы данных решил создать один синоним и добавил в скрип команду его создания: CREATE PUBLIC SYNONYM EMP FOR EPMPLOYEE;5. Создание пользователей и предоставление привилегий. Проектировщик базы данных решил создать трех пользователей базы данных и не определять никаких ролей, поэтому добавил в скрипт следующие команды: CREATE USER Ivan IDENTIFIED BY EXTERNALLY;CREATE USER Peter IDENTIFIED BY EXTERNALLY;CREATE USER Sidorov IDENTIFIED BY 'alsy_';Проектировщик базы данных определил пользователям следующие привилегии: GRANT SELECTON EMPLOYEE, DEPARTAMENT, PROJECT, EMP_PRJTO Ivan, Peter, Sidorov; GRANT INSERT,UPDATEON EMPLOYEE, DEPARTAMENT, PROJECT, EMP_PRJTO Ivan;Никаких других проектных решений проектировщик базы данных принимать не стал. Далее он составил подробный отчет по каждому объекту базы данных, фрагмент отчета для реляционной таблицы DEPARTAMENT (таблица 13.15) и предал полученные результаты руководителю ИТ-проекта.
После выполнения этих действий можно ожидать, что свои основные задачи в рамках ИТ-проекта проектировщик решил успешно.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||