Лабораторные работы БД. Отчет по лабораторной работе. 2 Используя ms access перенести полученную модель в бд, используя таблицы и схему данных
 Скачать 5.14 Mb.
|
|
Тема: Изменение данных и структуры БД. Клиентский интерфейс для БД. Цель: Развитие навыков программирования приложений, использую- щих БД, знакомство с частями SDL и DML языка SQL. Навыки и умения: модификация данных и определение структуры БД с помощью SQL, использование инструментария MS Access (редактор макро- сов, VBA модули, конструктор форм), написание клиентского интерфейса. Теоретическая часть Структура языка SQL Все операторы языка SQL можно условно разделить на три группы опе- раторов. Оператор языка запросов – SELECT (был рассмотрен в предыдущих лабораторных работах), операторы языка манипуляции данными (Insert, Update, Delete) и операторы языка определения данных (Create, Drop, Alter). Запросы DML (ЯМД) К запросам языка манипуляции данными (Data Manipulation Language) относятся запросы на добавление, удаление и модификацию кортежей. Добавление кортежа производится командой: INSERT INTO имя_таблицы [(<список столбцов>)] VALUES (<список значений>) Список столбцов и список значений указываются через запятую, а зна- чения добавляются в соответствующие столбцы. Если необходимо добавить кортеж целиком (т.е. значения есть для всех полей и их порядок совпадает с порядком полей в отношении), то описание списка столбцов можно опустить. Пример 1: Три следующих запроса будут верно исполнены для отношения R1: INSERT INTO R1(ФИО, Дисциплина, Оценка) VALUES («Попова», «БД», 3); INSERT INTO R1 VALUES («Попова», «Моделирование», 3); INSERT INTO R1(ФИО, Дисциплина) VALUES («Бурковский», «Се- ти ЭВМ»); Оператор удаления данных DELETE позволяет удалить одну или не- сколько строк из таблицы в соответствии с условиями, которые задаются для удаляемых строк. Синтаксис оператора DELETE следующий: DELETE FROM <имя_таблицы> [WHERE <условия_отбора>] Если условия отбора не задаются, то из таблицы удаляются все строки. Операция обновления данных UPDATE требуется тогда, когда происходят изменения данных, которые надо отразить в базе данных. Запрос на обновление может изменить сразу целую группу записей. Этот запрос состоит из трех частей: • Предложение UPDATE, которое указывает на обновляемую таблицу; • Предложение SET, задающее данные для обновления; • Необязательный критерий WHERE, ограничивающий число записей, на которые воздействует запрос на обновление. Пример 2: Изменить на 3 оценку по дисциплине «БД» у студента Миронова в таб- лице R1: UPDATE R1 SET R1.Оценка = 3 WHERE R1.ФИО = «Миронов» AND R1.Дисциплина = «БД»; Запросы SDL (ЯОД) Команды языка определения схемы данных (Schema Definition Language – SDL) представляют собой инструкции SQL, которые позволяют создавать и модифицировать элементы структуры базы данных. Например, используя SDL, можно создавать, удалять таблицы и изменять их структуру, создавать и удалять индексы. Создание таблицы. Оператор создания таблицы имеет следующий вид: CREATE TABLE <имя таблицы> (<имя столбца> <тип данных> [NOT NULL] [,<имя столбца> <тип данных> [NOT NULL]]…) Обязательными операндами оператора являются имя создаваемой таб- лицы и имя хотя бы одного столбца (поля) с указанием типа данных, храни- мых в этом столбце. При создании таблицы для отдельных полей могут указываться некото- рые дополнительные правила контроля вводимых в них значений. Например, конструкция NOT NULL (не пустое) служит для определения обязательного поля. В табл. 1 перечислены типы данных, которые можно использовать при создании таблиц, используя Microsoft Jet SDL и предложение CREATE (СУБД Access). Тип данных SQL тип Счетчик COUNTER Текстовый TEXT Memo LONGTEXT Денежный CURRENCY Дата/время DATETIME Числовой (одинарное с плавающей точкой) SINGLE Числовой (двойное с плавающей точкой) DOUBLE Числовой (целое) INTEGER Числовой (длинное целое) LONG Числовой (байт) BYTE С помощью конструкции CONSTRAINT можно задать первичный ключ таблицы. Пример 3: Создание таблицы TABL1: CREATE TABLE TABL1 ( [FIL1] COUNTER, [FIL2] TEXT (10), [FIL3] CURRENCY, [FIL4] DATETIME, [FIL5] BYTE, [FIL6] INTEGER, [FIL7] SINGLE, [FIL8] LONG, [FIL9] DOUBLE, CONSTRAINT PrimaryKey PRIMARY KEY ([FIL1]) ); В примере 3 поле FIL1 объявлено ключевым, для данного поля создан индекс с именем PrimaryKey. Похожим образом задается внешний ключ: Пример 4: Создание таблицы TABL2: CREATE TABLE TABL2 ( [FIL1] INTEGER, [FIL2] TEXT (10) NOT NULL, [FIL3] CURRENCY, [FIL4] LONGTEXT, CONSTRAINT PrimaryKey PRIMARY KEY ([FIL1],[FIL2]), CONSTRAINT ForeignKey FOREIGN KEY ([FIL1]) REFERENCES TABL1 ([FIL1])); В данной таблице поле FIL1 объявлено внешним ключом. Между табли- цами TABL1 и TABL2 устанавливается связь «один-ко-многим» по полю FIL1. Для удаления таблиц служит инструкция DROP TABLE <имя таблицы> Для модификации структуры таблицы (добавление, удаление полей, изменения типов полей) используется оператор ALTER TABLE изменения структуры таблицы имеет следующий вид: ALTER TABLE <имя таблицы>MODIFY | ADD | DROP <имя поля> [<тип данных>] Создание индексов Помимо создания индексов в процессе формирова- ния таблицы (с помощью предложения CONSTRAINT), можно также созда- вать индексы уже после того, как таблица сформирована: CREATE [UNIQUE] INDEX <имя индекса>ON <имя таблицы> (<имя столбца> [ASC | DESC] [, <имя столбца> [ASC | DESC]…) Этот оператор позволяет создать индекс для одного или нескольких столбцов заданной таблицы с целью ускорения выполнения запросных и по- исковых операций с таблицей. Для одной таблицы можно создать несколько индексов. Для удаления индексов служит инструкция DROP INDEX <имя индекса> ON<имя таблицы> Создание форм и отчетов в среде MS Access СУБД MS Access предоставляет программисту инструментарий для со- здания форм и отчетов (для пользователя). Соответствующие объекты можно найти среди объектов БД. Доступно как создание форм (отчетов) по опреде- ленным таблицам (запросам), так и самостоятельное создание в режиме ди- зайнера. Встроенный язык Visual Basic for Application СУБД MS Access предоставляет возможность описания процедур на языке высокого уровня Visual Basic for Application (VBA). Этот язык встроен во все программные средства, относящиеся к MS Office, и он позволяет рабо- тать с объектами БД через выполнение SQL-запросов. Язык VBA является родственником VB и Basic. Также этот язык является процедурным, поддер- живает деление на модули, поддерживает дизайнер форм. Обеспечивает об- работку исключительных ситуаций и выполнение транзакций. Процедуры и функции, описанные в области видимости public, могут также быть исполь- зованы при построении SQL-запросов, подобно встроенным функциям СУБД. Создать модули можно на соответствующей странице объектов MS Access. Задание на лабораторную работу 1. Создать базу данных по предметной области своего варианта, ко- торая должна минимум содержать таблицу, состоящую минимум из 6 по- лей. Реализовать кодовые поля в основной таблице и справочник(и) для расшифровки этих полей. Для создания таблиц БД использовать скрип- товый файл или макрокоманду, содержащую набор SQL-команд из части языка SDL; 2. Реализовать процедуры Добавления, Удаления, Поиска и Измене- ния, с помощью SQL; 3. Организовать оконный интерфейс для функций, созданных на предыдущем этапе (добавления, удаления, поиска и изменения); 4. Поиск должен осуществляться с использованием индексов, т.е. по- ля, по которым осуществляется поиск, должны быть проиндексированы. 5. Организовать вывод результатов в виде отчетов. Бонус (+ 25%): Организовать механизм авторизации – вход в БД по паролю для нескольких пользователей (статья справки «Пароли (MDB)»). Прием работы Прием происходит при наличии оформленного отчета и работающей БД, созданной в среде MS Access. Вопросы 1. На какие части можно разделить язык SQL, какие команды им соответствуют? 2. Для чего используются индексы? 3. Как обновить несколько полей для нескольких кортежей таблицы одним запросом? 4. Что определяет ключевое слово Constraint? 5. Что такое VBA? 6. Можно ли выполнить добавление данных без указания названия полей, в кото- рые добавляются значения? (почему нельзя или как можно) 7. Как создать форму в MS ACCESS? 8. Как создать отчет в MS ACCESS? Лабораторная работа № 1 ПОСТРОЕНИЕ МОДЕЛЕЙ ПРЕДМЕТНОЙ ОБЛАСТИ С ИСПОЛЬЗОВАНИЕМ CASE-СРЕДСТВ (ERWIN PROCESS MODELER, BPWIN ИЛИ RAMUS EDUCATIONAL) Цель работы: Создание функциональной модели системы в нотации IDEF0. Методика выполнения работы (на примере Erwin Process Modeler): 1. Создадим новую модель на примере деятельности компании по сборке и продаже компьютеров. 2. Разработаем диаграмму верхнего уровня модели (контекстную). 3. Определим функции, на которые может быть разложена функция, обозначенная на контекстной странице модели. Это: • Продажи и маркетинг; • Сборка и тестирование; • Отгрузка и получение. 4. Создадим диаграмму декомпозиции первого уровня. Для этого: • зададим имя заготовке контекстной диаграммы, выбрав свойства модели (меню Model>Model Properties…), свойства диаграммы – двойной клик мыши на свободном поле диаграммы, или пункт меню Diagram Properties…, или контекстное меню на свободном поле диаграммы. • зададим свойства модели. На вкладке General зададим информацию о модели. Временные рамки Time Frame примем AS-IS. Это означает, что рассматриваются существующие процессы. • на вкладке Purpose (Цель) внесем цель моделирования Purpose: "Моделировать текущие бизнес–процессы компании" и точку зрения, с которой строится модель Viewpoint: "Директор". • на вкладке Definition (Определение) задаем определение модели Definition: "Учебная модель, описывающая деятельность компании" и границы (рамки) модели Scope: "Общее управление бизнесом компании". • выделим функциональный блок на контекстной странице; • на панели инструментов щелкнем по кнопке с изображением черного треугольника, направленного вершиной вниз (декомпозиция) • в диалоговом окне укажем нотацию создаваемой диаграммы (IDEF0) и число функциональных блоков, которые она должна содержать (3 - по числу выделенных функций). 5. На диаграмме декомпозиции впишем названия выделенных функций в функциональные блоки. 6. Соединим с функциональными блоками интерфейсные дуги, которые мигрировали на созданную диаграмму декомпозиции с контекстной диаграммы. 7. Создадим внутренние дуги для связи функциональных блоков между собой. 8. Аналогично создадим диаграммы декомпозиции для функциональных блоков А1, А2. Достигнутый результат. В результате работы средствами редактора Process Modeler создана трехуровневая функциональная модель системы в нотации IDEF0. Задание Создайте средствами редактора Modeler трехуровневую функциональная модель в нотации IDEF0 предметной области вашего варианта. Для моделируемой системы в среде Process Modeler (BPwin) должна быть создана трехуровневая функциональная модель, содержащая кроме контекстной диаграммы, диаграммы двух уровней декомпозиции. 1. Создайте новую модель. 2. Разработайте контекстную страницу модели. 3. Обдумайте, на какие функции может быть разложена главная функция системы, обозначенная Вами в функциональном блоке на контекстной странице модели. Помните, что число этих функций должно быть от 3 до 6. 4. Создайте диаграмму декомпозиии первого уровня. При создании диаграммы выберите в диалоговом окне нотацию диаграммы (IDEF0) и укажите, сколько функциональных блоков вы планируете разместить на диаграмме. 5. На диаграмме декомпозиции впишите названия выделенных функций в функциональные блоки. Помните о том, что функциональные блоки на диагонали должны быть расположены в порядке убывания их значимости или в соответствии с последовательностью выполнения работ. 6. Соедините интефейсные дуги, которые мигрировали с диаграммы верхнего уровня на созданную диаграмму декомпозиции в виде стрелок, с функциональными блоками в соответствии с их назначением. 7. Если в этом есть необходимость, сделайте разветвления дуг. Помните о том, что Вы можете оставить единое название для всех веток. В этом случае название располагается до разветвления стрелки. В случае, если ветки обозначают разные объекты, подпишите каждую ветку. 8. Создайте внутренние дуги, связывающие функциональные блоки между собой. Помните, что каждый функциональный блок обязательно должен иметь дуги Управления и Выхода. Дуги Механизма и Входа могут отсутствовать. Именуйте каждую дугу. 9. По описанной выше технологии создайте диаграммы декомпозиции для тех функциональных блоков, прояснить содержание которых требуется по логике модели. Контрольные вопросы 1. Что такое бизнес-процесс? 2. Перечислите модели структурного подхода к моделированию. 3. Каковы основные компоненты функциональной модели? 4. Что представляют собой методологии функционального моделирования? 5. Укажите преимущества и недостатки объектно-ориентированной методологии моделирования по сравнению с функциональной. Содержание и оформление отчета Отчет должен содержать: титульный лист, название и цель работы; вариант задания; скриншоты результатов работы; выводы по работе; ответы на контрольные вопросы. Лабораторная работа № 2 Проведение системного анализа предметной области. Разработка логической и физической моделей БД. Цель работы: Закрепление и более глубокое усвоение знаний по проектированию информационных моделей. Методика выполнения работы: Структурное проектирование с использованием IDEF позволяет построить так называемую модель требований (логическую модель) системы, состоящую из множества взаимоувязанных диаграмм, текстов и словаря данных. Эта модель описывает что должна делать проектируемая система без ссылок на то, как это достигается. В процессе проектирования системы разрабатываются последовательно ER (сущность- связь), KB (ключевой уровень) и физическая модели. Эти модели обеспечивают: - разработку документации базы данных; - разработку ссылочной целостности БД; - разработку логической модели БД независимой от конкретного типа СУБД; - разработку документирования физического проектирования БД в соответствии с бизнес требованиями. Физическая модель позволяет: - обеспечить администратору БД достаточность информации, чтобы создать эффективную БД; - создать контекст для процессов определения и записи в словари данных; - ассистировать группам приложений в выборе физической структуры программы, которая будет запрашивать данные. При переходе от логической модели Erwin каждой ее опции ставит соответствующую опцию физической модели. 1 Пример описания проекта. Задание: разработать информационную модель реализации настольных компьютеров по заказам клиентов. Для описания объектов предметной области по реализации настольных компьютеров по заказам клиентов выделены следующие сущности: Тип компьютера, Компьютер, Клиент, Заказ, Продажа, Менеджер, Отдел (рис. 1) Рисунок 1. Сущности, выделенные для описания объектов предметной области по реализации настольных компьютеров по заказам клиентов Логическим соотношением между сущностями является связь. Каждому виду связи соответствует определенная кнопка, расположенная на палитре инструментов. Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы. Каждая связь должна именоваться глаголом или глагольной фразой. Например, связь между сущностями Компьютер, Продажа и Менеджер показывает (рис. 2), какой компьютер продан и какой менеджер оформил сделку продажи компьютера: − каждый Компьютер < продается > Продажа; − каждая Продажа < оформляет > Менеджер. Рисунок 2. Связь между сущностями Компьютер, Продажа и Менеджер В нотации IDEF1X различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями и показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи. При установлении идентифицирующей связи ERwin автоматически преобразует дочернюю сущность в зависимую сущность. Зависимая сущность на диаграмме изображается прямоугольником со скругленными углами, например, сущность Продажа (см. рис. 2). Экземпляр зависимой сущности определяется только через отношение к родительской сущности. Например, информация о продаже не может быть внесена и не имеет смысла без информации о проданном компьютере. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые (мигрированные) атрибуты помечаются как внешний ключ (FK). В случае идентифицирующей связи при генерации схемы базы данных атрибутам внешнего ключа присваивается признак NOT NULL, что означает невозможность внесения записи в таблицу, соответствующей дочерней сущности, без идентификационной информации из таблицы, соответствующей родительской сущности. Например, невозможность внесения записи в таблицу продаж без информации об идентификационном номере проданного компьютера, определенного в таблице описания имеющихся в наличии компьютеров. Неидентифицирующая связь показывается на диаграмме пунктирной линией с жирной точкой и служит для установления связи между независимыми сущностями. При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа мигрируют в состав неключевых атрибутов родительской сущности (рис. 3). Рисунок 3. Пример неидентифицирующей связи между независимыми сущностями Менеджер и Отдел Для создания новой связи необходимо: − установить курсор на кнопке, расположенной на палитре инструментов и соответствующей требуемому виду связи, и нажать левую кнопку мыши; − щелкнуть левой кнопкой мыши сначала по родительской, а затем по дочерней сущности. Изменить форму линии связи и ее местоположение между связанными сущностями можно путем захвата мышью выделенной линии связи и переноса ее с места на место, пока линия не примет необходимые местоположение и форму. Редактирование свойств связи осуществляется в диалоговом окне Relationship, которое открывается через пункт Relationship Properties контекстного меню, активизируемого посредством нажатия правой кнопки мыши на выделенной связи. Вкладка General диалогового окна Relationship позволяет задать мощность, имя и тип связи. Мощность связи(Cardinality) служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней сущности. Различают 4 типа мощности связи: − общий случай – не помечается каким-либо символом и соответствует ситуации, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности; − символом Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности, т.е. исключено нулевое значение; − символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности, т.е. исключены множественные значения; − цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности. Результат разработки логической модели данных системы "Реализация средств вычислительной техники", предназначенной для учета продаж настольных компьютеров по заказам клиентов приведен на рис. 4. Рисунок 4. Логическая модель данных системы «Реализация средств вычислительной техники» Созданная логическая модель данных системы является основанием для создания физической модели данных под выбранную СУБД. Физический уровень представления модели зависит от конкретной реализации СУБД, поэтому необходимо предварительно осуществить ее выбор. CA ERwin Data Modeler 7.3 поддерживает 17 наиболее распространенных СУБД. Выбор СУБД осуществляется в окне Target Database диалога Create Model. Для выбора СУБД необходимо открыть выпадающий список с перечнем поддерживаемых СУБД и щелкнуть по соответствующему имени. При этом в поле Version отобразится версия выбранной СУБД. В случае автоматического перехода к физической модели ERwin генерирует имена таблиц и колонок по умолчанию на основе имен соответствующих сущностей и атрибутов логической модели, учитывая максимальную длину имени и другие синтаксические ограничения, накладываемые выбранной СУБД. При этом правила ссылочной целостности, принятые на логическом уровне модели данных системы, также принимаются по умолчанию, т.е. сохраняются. Построение физической модели данных для системы "Реализация средств вычислительной техники" осуществлено путем автоматического перехода от логической модели к физической модели, так как при создании логической модели данных системы был выбран логико – физический тип модели. Физическая модель данных системы "Реализация средств вычислительной техники" приведена на рис. 5. Для генерации кода создания базы данных можно использовать пункт главного меню Tools/Forward Engineer. Рисунок 5. Физическая модель данных системы "Реализация средств вычислительной техники" Порядок выполнения работы. Настройка работы. 1 Запускается CASE - система Erwin. 2 Осуществляется настройка работы для работы с русским языком и конкретным СУБД. 3 Осуществляется настройка Ссылочной Целостности (Referential Integrity). Для этого из скролинг- меню (Identifying) выбираются опции для отношений IDENTIFYING (Ch.Del- Par.Upd) соответственно (N, Restr., Restr., Restr., None, Restr.). ( Здесь опции Сascad указывает, что все атрибуты, указанные в сущности родителя для удаления, одновременно удаляются и у наследуемых сущностей). Логическое проектирование. Задача1. Проектирование ER диаграммы. Цель: построение диаграммы уровня “сущность- связь” и глоссария к ней. Последовательность действий: • выделить сущности и присвоить им уникальные имена; • занести в глоссарий модели формальное определение имен сущностей. Требования к диаграмме и глоссарию: • сущности должны быть представлены на диаграмме только именами; • допускаются зависимые и независимые сущности; • глоссарий должен содержать краткие формальные определения сущностей. Порядок разработки ER диаграммы. 1 Выбирается из ErWin Toolbox тип сущности зависимая (если она потомок) или независимая (если она родитель). 2 Щелкнуть по месту расположения сущности на рабочем поле. 3 Выбрать в Toolbox стрелку Select. Дважды щелкнуть по полю сущности. В открывшимся редакторе Entity- Attribute Editor в окне Entity записать имя сущности. OK. Задача 2. Проектирование отношений. Цель: проектирование и осмысление характера взаимосвязей между сущностями. Последовательность действий: 1. определить тип отношения; 2. указать имя отношения. Требования к диаграмме: имена связей должны выбираться в глагольной форме, так, чтобы диаграмма читалась осмысленными фразами русского языка; при разработке допускаются определенные, неопределенные, связи типа “many- many” и категоризационные связи. Порядок проектирования диаграммы. 1 Устанавливаются в поле экрана сущности Родителя и Потомка. Щелкнуть по полю тип отношений ErWin Toolbox (определенное, неопределенное, неспецифическое). 2 Щелкнуть сначала по полю сущности Родителя, а затем по полю сущности Потомка. 3 Дважды щелкнуть по отношению. В открывшимся редакторе отношений в окне Verb Phrase вводят глагольную форму, связывающую обе сущности в смысловое предложение. Триггерами Кардинальности указывается мощность отношения (Р, Z или число). Обычно ставится максимальная. В дисплейном окне Rolename (можно изменить ролевое назначение ключа). В окне Foreign Key указывается (название ключа наследования). 4 Чтобы наблюдать на рабочем экране имя отношения необходимо выбрать в панели меню DISPLAY/ Verb Phrase. 5 В случае необходимости, чтобы добавить в схему отношение типа категории между Родителем и двумя Потомками необходимо: • выбрать тип категории (категория с одной линией показывает, что имеются другие сущности категории, которые не включены в схему, категория с двумя линиями указывает, что все категории учтены); • щелкнуть последовательно сначала по сущности Родителя, а затем по сущности одного из Потомков; • щелкнуть по месту установки знака отношения категории, а затем щелкнуть по оставшейся сущности. Задача 3. Проектирование КВ диаграммы. Цель: проектирование идентификаторов сущностей и уяснение логики взаимосвязей на уровне идентификаторов. Последовательность действий: • преобразовать все неспецифические отношения в специфические; • определить возможные ключи независимых сущностей и выделить первичные ключи; • ввести формальные определения имен ключевых атрибутов в глоссарий; • показать первичные и все возможные ключи на диаграмме; Требования к диаграмме: • на диаграмме допускаются только специфические и категоризационные связи; • глоссарий должен содержать формальные определения ключей. Физическое проектирование. Задача 4. Физическое проектирование. Цель: разработка структуры реляционной базы данных для выбраннной СУБД. Последовательность действий: 1. поставить в соответствие именам сущностей и атрибутов логической модели имена таблиц и полей БД (физические имена); 2. разработать сопроводительную документацию. Требования к диаграмме: 1. Проектируются типы данных в соответствующем СУБД. Для этого включается в верхней линейке пиктограмма PHYSICAL VIEW, 2. Выбирается указателем мышки проектируемая сущность, нажатой правой выбирают Вариант СУБД DATABASE, в редакторе выбирают тип данных, 3. размер записи, ОК. 4. Описываются свойства связей между таблицами, в частности, реакцию сервера на попытки нарушения ссылочной целостности со стороны клиентского приложения. Для этого выделив связь, щелкнуть правой кнопкой и выбрать в редакторе отношений опцию RELATIONSHIP INTEGRITY, при этом можно отредактировать ее VERB PHRASE, установить триггеры запрещения действий клиентскому приложению по удалению записей CHILD DELETE- NONE, PARENT DELETE- NONE, а все остальное - RESTRICT. После этого, можно создавать на сервере схему БД. Для этого отредактировать тип данных (войти в какую нибудь сущность и правой кнопкой щелкнуть, а затем выбрать Attribute Editors, ввести редактируемую сущность в окне Entity), введя типы для атрибутов и ключей. Ввести определения атрибутов и имена владельца данных. Вызвать Domain Editor (Column Propery Editor/ Domain). Ввести имена доменов и присвоить им типы (длина) и определения. Задание 1. Провести системный анализ предметной области согласно вашему варианту. 2. Разработать концептуальную модель данных. 3. Разработать в логическую модель данных. 4. Разработать физическую модель данных. При разработке можно использовать CASE-систему ErWin Data Modeler (или аналогичную). Полученный набор отношений должен находиться в третьей или выше нормальной форме и содержать не менее 5-ти сущностей. Контрольные вопросы 1. В чем разница между концептуальной, логической и физической моделями данных? 2. Объясните смысл терминов (реляционная модель данных, мощность отношения, тип отношения). 3. Дайте определения нормальных форм. 4. Объясните применение ограничительных условий, поддерживающих целостность данных. Содержание и оформление отчета Отчет должен содержать: титульный лист, название и цель работы; вариант задания; скриншоты результатов работы; выводы по работе. |